Relocatierbarer Code

[Gazelli]

Hallo Pic Kollegen

Ich habe eine grundsätzliche Frage. Ich baue an einem sehr speziellen Controller und benötige dafür eine grosse Menge an Steuerbibliotheken . In diesem Zusammenhang stellt sich mir die Frage ob ich aus eine C-Programm Code "nach Bedarf" ähnlich einer DLL nachladen kann ?

Super wäre auch die Möglichkeit Routinen dynamisch an beliebige Stellen im Speicher nachzuladen und ggfs zu löschen wenn der Speicher benötigt wird . Geht sowas

Danke

Gazelli

[Edson]

Hallo,

Super wäre auch die Möglichkeit Routinen dynamisch an beliebige Stellen im Speicher nachzuladen und ggfs zu löschen wenn der Speicher benötigt wird . Geht sowas

du schreibst "dynamisch" und sprichst im gleichen Atemzug von Programm-Routinen. Wenn du also wirklich Routinen in den Flash-Speicher eines PIC nachladen willst, stellt sich die Frage in welchem Datenspeicher wiederum deine "Steuerbibliothek" liegen soll?

Innerhalb der 8-Bit Familien gibt es keinen PIC, der mit Programmcode im RAM etwas anfangen kann. Es sei denn, man programmiert ihm einen sogenannten Interpreter (für dein Vorhaben mit kompilierten Objekten eigentlich mehr ein Emulator) - das sorgt allerdings für erhöhten Ressourcen-Bedarf und prinzipbedingte Performance-Verluste.

Vielleicht wäre es besser wenn du nochmal genauer erklärst was du eigentlich vorhast, sonst ist es schwer einen brauchbaren Tip zu geben.
Du hast leider nicht erwähnt, welche PIC-Familie du anpeilst (8/16/32-Bit)?

Gruß,
Edson

[Gazelli]

Hallo Edson


Danke für die Antwort

Ich möchte einen 18F9760 128 KB benutzen da ich Ethernet brauche und den Aufwand gering halten möchte.

Ich brauche einen Bootloader + Interpreter der eine Pseudosprache interpretiert wobei Performance keine Rolle spielt.  Den Interpreter kann ich relativ klein halten ca 40 K. Ich möchte dem Benutzer ermöglichen eigenen interpretierbaren Code(Tokens)  im Rest des Flash Speichers zu laden und dann über eine Tabelle( ähnlich einer Linked List von Funktionspointer ) nachgeladen und intepretiert wird) . Um das zu erreichen muss ich z.B. im Programm das Ende des Interpreters kennen um den Restcode nachladen zu können . Daher meine Frage on man relocatierbaren Code schreiben kann der relative Sprünge enthält und eine Art von Basis Segment Adresse

Gazelli

[Edson]

Hallo Gazelli,

Ich brauche einen Bootloader + Interpreter der eine Pseudosprache interpretiert wobei Performance keine Rolle spielt.  Den Interpreter kann ich relativ klein halten ca 40 K.

sprichst du jetzt vom Bootloader als Programm im PIC oder meinst du die PC-Anwendung, die den Programm-Code zum PIC übertragen soll? (btw. 40k für den Interpreter kann wenig sein, für eine einfache Kommando-Struktur ist das aber ganz schön viel.)

Um das zu erreichen muss ich z.B. im Programm das Ende des Interpreters kennen um den Restcode nachladen zu können .

In welchem Programm? Den Speicherbedarf deiner Bootloader/Interpreter-Firmware kennst du doch. Oder du schreibst die Bootloader-Firmware so um, dass sie ein Kommando kennt mit dem du diese Informationen abfragen kannst.

Daher meine Frage on man relocatierbaren Code schreiben kann der relative Sprünge enthält und eine Art von Basis Segment Adresse

Wenn der Benutzer interpretierbare Tokens erstellt, muss er doch keinen relocatierbaren Code schreiben, oder? Du brauchst doch lediglich Schreib-/Lese-Funktionen um solchen Tokens zu erstellen bzw. zu interpretieren.
Aber, um die Frage zu beantworten: Ja, sicher. Die "Basis Segment Adressen" oder "Sections", wie Microchip es nennt, kannst du im Linkerscript anpassen

Vielleicht habe ich aber immer noch nicht verstanden was du vorhast und hoffe mal, du klärst mich auf.

Gruß,
Edson

[Gazelli]

Ich glaube ich muss das ganze mal etwas beschreiben.

1. Ich bin seit 25 Jahren in der PC + Unix Programmierung tätig...daher vermutlich meine PC Sicht

2. Ich möchte ein modularen System auf Basis eines Pics bauen. Die Grundstruktur soll eine Art passive Backplane sein die zunächst nur die Stromversorgung und das CPU Board enthält

Zusätzlich möchte ich aber weitere (teilweile noch garnicht entwickelte) IO Boards für Sensoren Aktoren der verschiedensten Art einbinden. Im einfachsten Falle sind es Temp Sensoren und Solid State Relais Outputs. Mir schwebt eine Art kleines OS vor das die wesentlichen Dinge wie IP IO von und zu den Boards sowie einen kleine Interpreter für eine kleine "Sprache" enthält . Ich dachte mir also ich können ein Grundgerüst ( Bootloader Interpreter ) bauen und eine Art Treiber für die IO Boards nachladen.

Der Code für Bootloader und OS sowie Treiber wären natürlich compilierter C Code , während der Benutzer Code Interpretiert werden soll. Da die CPU bis zu 2 MByte externes RAM zulässt könnte ich den zu intepretierenden Code auch aus dem RAm ausführen lassen

[Coltfisch]

Hallo Gazelli,

ich habe mich vor Jahren mit etwas Ähnlichem beschäftigt (http://base32.de/EMI1.html). Ein CPU-Board mit externem RAM + ein simples Betriebssystem (im einfachsten Fall ein Bootloader). Das OS konnte kompilierte Benutzerprogramme in den externen RAM laden und dort ganz normal ausführen.

Den Code nicht bereits beim Kompilieren, sondern dynamisch erst beim Kopieren in den RAM zu "relokieren" ist sicherlich möglich. Man müsste dazu aber bei dem Maschinencode im RAM die Sprungadressen anpassen. Möglich, aber ein riesen Aufwand.
Eine Möglichkeit, das kompilierte Programm direkt bei der Erstellung mit relativen Sprungadressen auszustatten, ist mir nicht bekannt (zumindest nicht beim C18).

Diese Sorgen wirst Du natürlich los, wenn Du Dein OS tatsächlich mit einem Interpreter ausstattest und dann nur interpretierbaren Code in den externen RAM ablegst. Vielleicht macht es sogar Sinn, einen fertigen BASIC-Interpreter einzubinden? Ich denke, so etwas wird sich bereits fertig und quelloffen im Internet finden lassen...

Gruß
Daniel

[Gazelli]

Danke für Deine Antwort. Ich werde das mal studieren

[Gazelli]

Hallo Daniel

Ich denke es wäre deutlich einfacher einen kompakten Kernel zu bauen ( mit bootloader) und dann interpretierten Code anzuführen (Wo auch immer). Was Deine Basic Vorschlag anbetrifft. Na ich bin  eher mit C/C++ unterwegs und mag die kompakte maschinennahe Arbeitsweise
Wäre es eigentlich möglich Code aus einer SD Card auszuführen ?

[Coltfisch]

Was Deine Basic Vorschlag anbetrifft. Na ich bin  eher mit C/C++ unterwegs und mag die kompakte maschinennahe Arbeitsweise

Kann ich gut nachvollziehen, aber Tatsache ist, dass sich nicht alle Programmiersprachen gleich gut mit einem Interpreter verarbeiten lassen 
War ja auch nur ein Vorschlag, um das Rad nicht neu erfinden zu müssen.

Wäre es eigentlich möglich Code aus einer SD Card auszuführen ?

Natürlich. Entweder direkt byteweise von der SD-Karte lesen oder indirekt, indem die Quelltextdatei zunächst in den RAM kopiert wird. Mit einem Interpreter an Bord stehen Dir alle Türen offen. Nur die Performance ist halt mies...

Gruß
Daniel

[Gazelli]

Wie gesagt ich brauche keine Superperformance Stabilität ist mir wichtiger. Ich habe erst vor einigen Monaten angefangen mich mit Pics zu befassen und lerne erst einmal .

Was die Sprache anbetrifft. Ich wollte keine C Interpreter schreiben sondern eher eine eigene Sprache die aber auch Konstrukte wie Pointer Array struct und vielleicht Classes wie in C++ usw unterstütz . An C gefällt mir die Einfachheit der Grundsprache . Der Rest sind dann Licraries die ich dann bereits in der Interpretersprache schreiben kann. Wenn ich byteweise von einer SD Card lesen und ausführen kann habe ich doch mehr als genug Speicher !
Ich denke ich werde alle hardwarenahen Sachen in C schreiben und den Rest per Interpreter


Danke Euch für die Hilfe

Gazelli

[Edson]

Hallo Gazelli,

Was die Sprache anbetrifft. Ich wollte keine C Interpreter schreiben sondern eher eine eigene Sprache die aber auch Konstrukte wie Pointer Array struct und vielleicht Classes wie in C++ usw unterstütz .

Wenn dir eine überschaubare "Untermenge" von C/C++ Datentypen reicht, könnte XML vielleicht eine Alternative zu einer komplett eigenen Sprache sein. Klassen und Felder lassen sich gut mit XML darstellen. Den hohen Platzbedarf kann man etwas eindämmen, indem man die Tags und Attribute in Steuerzeichen oder eine Art Escape-Sequenz umwandelt.
Parsen (statt Interpretieren) muss man dann allerdings zweimal, das erste mal wenn der User eine XML-Datei in dein System einspielt und das zweite mal bei der Verarbeitung der "eingebetteten" XML-Dateien.

Gruß,
Edson

[Gazelli]

Ich habe offengestanden keine Ahnung von XML. Ich weiss natürlich was es ist . Die klassische Variante ist mir immoment lieber

Ich weiss nicht mehr wie der Interpreter hiess aber aus alten CP/M Zeiten C-Interpreter der in 4 KB Platz hatte ... Das waren noch Zeiten (Z 80 Assembler)

[Edson]

Die klassische Variante ist mir immoment lieber

Wenn du da Erfahrungen hast, ist das nachvollziehbar. Ich weis ja nicht, wie groß der "Sprachumfang" für dein Vorhaben sein muss.

Ich weiss nicht mehr wie der Interpreter hiess aber aus alten CP/M Zeiten C-Interpreter der in 4 KB Platz hatte ... Das waren noch Zeiten (Z 80 Assembler)

Ja, die gute alte Zeit Die war leider schon fast vorbei als ich anfing mich für Mikroprozessoren zu interessieren. Den 6510 kenne ich noch, Z80 allerdings nur vom Namen her.

Trotzdem, wenn du den Interpreter wiederfindest würde ich mir den Code gerne mal anschauen.

Gruß,
Edson

[Gazelli]

Dann liess doch mal "Rodnay Zaks" Z 80 Programming ca. 1978

Der Godfather des Assembler

6510 ist ja schon modern

Ich werde alt ...

[Edson]

Dann liess doch mal "Rodnay Zaks" Z 80 Programming ca. 1978

Ja, das ist ein interessanter Schmöker. Ich meinte aber den C-Interpreter der in 4k passt.

Ich werde alt ...

Versuch es so zu sehen: Die, die es nicht werden haben auch nichts davon...

Gruß,
Edson