mikrocontroller.net

Forum: Compiler & IDEs Interpreter Design - in C oder Assembler?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Glenn62 (Gast)


Bewertung
-3 lesenswert
nicht lesenswert
Hallo,
ich habe YAFFA-Forth auf meinen Arduino geladen, und es läuft gut.
Allerdings lässt sich dieses Forth nicht erweitern, das heißt, der 
Programmspeicher lässt sich vom Forth aus nicht beschreiben - das 
Directory nimmt keine neuen Worte auf.
Liegt das nun an der speziellen Implementation dieses Forths in einer 
Arduino-Umgebung oder aber grundsätzlich daran, dass es in einer High 
Level Language -C- verfasst ist? Letzteres könnte ich mir schon 
vorstellen, denn mit kleinen Bausteinen (den Maschineninstruktionen) 
lassen sich feinere (Programm)Strukturen aufbauen als mit größeren 
Klötzen (den Konstrukten einer Hochsprache).
Wenn letzteres der Fall ist, kommt man um eine Implementation von 
Interpretern im jeweiligen Assembler nicht herum.
Viele Grüße
Glenn

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Glenn62 schrieb:
> dass es in einer High Level Language -C- verfasst ist?

Sicher nicht.

Allerdings wundert mich das, denn letztlich erweitert man bei FORTH doch 
den Speicher grundsätzlich mit jeder Aktion. (Dass das Resultat nicht 
persistent ist, also nur im RAM existiert, ist was anderes.)

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
https://github.com/sdwood68/YAFFA/wiki/YAFFA---Yet-Another-Forth-For-Arduino

Klingt nicht so, als könnte man keine neuen Wort erfinden (und damit das 
Dictionary erweitern). Allerdings, wie befürchtet, sie sind nur im RAM. 
Gründe sind dort dokumentiert.

von Pleger (Gast)


Bewertung
1 lesenswert
nicht lesenswert
YAFFA-Forth -> löschen

AmForth -> installieren

Nähere Download & Infos: http://amforth.sourceforge.net/

Ein besseres Forth wirst du so schnell nicht finden.

von Oliver S. (oliverso)


Bewertung
-1 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Gründe sind dort dokumentiert.

und nicht zutreffend. Wenn man neue Worte ins EEprom schreiben könnte 
(was da als mögliche Zukunftsvariante vorgschlagen wird), dann kann man 
auch neue Worte ins Flash schreiben, sowohl im Assembler, als auch in C, 
vielleicht sogar in Forth selber. Voraussetzung ist natürlich, daß im 
Flash noch Platz ist ;)
Eventuell muß man sich dazu aus der Arduino-Umklammerung lösen, aber das 
sollte kein großes Problem sein.

Oliver

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
1 lesenswert
nicht lesenswert
Oliver S. schrieb:
> dann kann man auch neue Worte ins Flash schreiben, sowohl im Assembler,
> als auch in C

Das geht nur aus dem (per Fuse definierten) Bootloader-Bereich heraus, 
hardwaremäßig im AVR so festgezurrt.

Klar, wenn man den Arduino-Bootloader aufgibt und seinen eigenen Code 
dahin schreibt, kann man das machen. Aber einfach „nicht zutreffend“ zu 
deklarieren, passt so nicht.

von c-hater (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Jörg W. schrieb:

> Oliver S. schrieb:
>> dann kann man auch neue Worte ins Flash schreiben, sowohl im Assembler,
>> als auch in C
>
> Das geht nur aus dem (per Fuse definierten) Bootloader-Bereich heraus,
> hardwaremäßig im AVR so festgezurrt.

Das ist korrekt. Allerdings umfasst dieser Bootloaderbereich bei den 
kleineren Teilen (Attinys) den gesamten Flash.

> Klar, wenn man den Arduino-Bootloader aufgibt und seinen eigenen Code
> dahin schreibt, kann man das machen.

Könnte man auch machen, ohne auf den Arduino-Bootloader verzichten zu 
müssen. Der muss bloß ein paar (mindestens 4) Byte kleiner sein als der 
Bootloaderbereich, dann geht das. Dann kann man dort das positionieren, 
was wirklich im Bootloaderbereich stehen muss. Im Minimum sind das nur 
zwei Instruktionen:

spm
ret

Das genügt. Das kann man dann von überall aus dem Flash aufrufen. Der 
Rest der Logik zum "self programming" muss dann natürlich andernorts 
implementiert sein. Aber das ist Wurscht, wirklich im Bootladerbereich 
stehen muß nur die spm-Instruktion.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:

> Das ist korrekt. Allerdings umfasst dieser Bootloaderbereich bei den
> kleineren Teilen (Attinys) den gesamten Flash.

Wir reden hier aber über einen ATmega328.

>> Klar, wenn man den Arduino-Bootloader aufgibt und seinen eigenen Code
>> dahin schreibt, kann man das machen.
>
> Könnte man auch machen, ohne auf den Arduino-Bootloader verzichten zu
> müssen. Der muss bloß ein paar (mindestens 4) Byte kleiner sein als der
> Bootloaderbereich, dann geht das.

Das wird man aber nicht mithilfe des Bootloaders dahin bekommen – 
zumindest würde ich mich als Bootloader weigern, in meinen eigenen 
Bereich reinzuschreiben.

Wenn man auf den originalen Bootloader verzichtet, geht das natürlich, 
aber man braucht einen externen Programmer.

ps:

> Im Minimum sind das nur zwei Instruktionen:
>
> spm
> ret

Das könnte mit den timing constraints eng werden. Zwischen dem Setzen 
der Bits zum Schreiben des Flashs und dem Ausführen des SPM dürfen 
maximal 4 Takte vergehen, aber der JMP braucht bereits 3. Käme auf den 
Versuch an.

Besser wäre es auf jeden Fall, die komplette Routine zum Schreiben einer 
Flash-Page gleich dort unterzubringen, zumal bei Ausführung aus dem 
oberen Speicherbereich die CPU nicht angehalten wird.

: Bearbeitet durch Moderator
von BLCdesigner (Gast)


Angehängte Dateien:

Bewertung
-2 lesenswert
nicht lesenswert
Glenn62 schrieb:
> YAFFA

Kree!

von c-hater (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Jörg W. schrieb:

> Das wird man aber nicht mithilfe des Bootloaders dahin bekommen

Kommt auf den Bootloader an. Keine Ahnung, ob der Arduino-Bootlader 
sowas kann. Vermutlich hast du aber Recht und er kann es nicht.


> Das könnte mit den timing constraints eng werden. Zwischen dem Setzen
> der Bits zum Schreiben des Flashs und dem Ausführen des SPM dürfen
> maximal 4 Takte vergehen, aber der JMP braucht bereits 3. Käme auf den
> Versuch an.

Also ich würd's eher mit call/rcall aufrufen ;o)

Ja, das wird eng werden. Ich meine mich erinnern zu können, dass ich das 
bei einem Mega8 (also mit rcall) schonmal gemacht habe, bin mir aber 
nicht ganz sicher. Zu lange her.

Nunja, sind's halt nicht 4, sondern 6 Byte, die man "da oben" braucht. 
Nur ein gradueller Unterschied, kein prinzipieller bezüglich der 
Machbarkeit.

von ~Mercedes~ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Hab ich das richtig verstanden?
Wollt Ihr die Harvard - Architektur austrixen?
Kann man den Flash nicht nur in größeren Blöcken
beschreiben / löschen?

Da müßte man ja sowas wie ne Speicherverwaltung
proggen, damit die Flash - Zellen gleichmäßig
abgenutzt werden, nicht wahr?


mfg

von Theor (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich kann, denke ich, schon nachvollziehen warum manche FORTHs entweder 
ganz auf die Erweiterbarkeit zur Laufzeit verzichten oder verschiedene 
Kompromisse eingehen. Letztlich bedingt der Flash-Programmspeicher das.


Ich habe mein eigenes an fig-FORTH angelehntes FORTH für den AVR 
geschrieben.
Das Dictionary ist im Flash-Speicher erweiterbar. Interrupts können in 
High- und low-Level geschrieben werden. Ein Assembler ist optional 
enthalten. Rekursion ist möglich. Das Speicherlayout ist variabel und 
zur Laufzeit konfigurierbar (nach einem Kaltstart wirksam). Läuft bis 
hinauf zu den 256KiB AVRs. Im der Minimalversion braucht es allerdings 
mindesten 16KiB. Ein absolutes Minimal-FORTH wäre deutlich kleiner, aber 
nur noch für Erfahrene wirklich nutzbar (die dann häufig doch noch 
einiges an Standard-Worten hinzufügen müssten).

Ein im Flash-Speicher erweiterbares Dictionary, und dann noch mit 
entsprechenden VOCABULARY-Worten, ist m.M.n. tatsächlich irgendwie 
"unangenehm". :-) Aber sicher wünschenswert.

Ein Problem entsteht (selbst ohne VOCABULARY), wenn man erreichen will, 
das  Flash so selten wie möglich zu beschreiben.
Da gibt es verschiedene Benutzungs-Fälle. Bei den einen macht das 
entweder so gut wie gar nichts aus, weil man eine Anwendung für einen 
speziellen Fall entwickelt, die dann einfach läuft, ohne das man sie 
wieder anfässt. Oder man muss so alle halbe Jahre mal einen AVR 
wegschmeissen, weil man darauf immer wieder Neues entwickelt.
Tja. Irgendeine Kröte muss man immer schlucken. :-)

Insbesondere die Rekursion hat mich dazu geführt, die neuen Worte im RAM 
zusammenzubauen. BUILDS-DOES und Low-Level-Worte erfordern, dass man mit 
COLON (CREATE) angefangene Worte ohnehin nachträglich ändern muss. Wenn 
aber Rekursion auf eben gerade geflashte Worte stattfinden soll, braucht 
man einige der Dictionary-Worte sozusagen doppelt - einmal im RAM und 
einmal im FLASH.
Dictionary mit ausführbaren Worten im RAM und im FLASH erfordern den 
analogen Aufwand.

Es gibt natürlich Varianten davon, die sich anders verhalten. Aber: "Wie 
man es auch macht, ist es falsch" ;.) Oder bringt eben nicht nur 
Vorteile sondern immer auch Nachteile in Bezug auf einen anderen Aspekt.

Ich habe z.B. lange überlegt ob und wie ich die VOCABULARY-Worte 
implementiere. Die traditionelle Variante erfordert, dass die letzten 
Zellen des Flash-Speichers mindestens zweimal geschrieben werden, sobald 
ein neues Wort angefügt wird. Nicht schön und wer gerne mit dem 
Schicksal hadert, hat hier viel Betätigungsmöglichkeiten. :-)

von c-hater (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
~Mercedes~ schrieb:

> Kann man den Flash nicht nur in größeren Blöcken
> beschreiben / löschen?

Ja, aber man kann den Blockinhalt lesen und den Teil, den man davon 
behalten will in den Schreibpuffer der Flash-Mimik schreiben, bevor man 
den Block löscht. Dann schreibt man den neuen Teil des Inhalts in den 
Puffer und dann den ganzen (nunmehr also modifizierten) Blockinhalt in 
den Flash.

> Da müßte man ja sowas wie ne Speicherverwaltung
> proggen, damit die Flash - Zellen gleichmäßig
> abgenutzt werden, nicht wahr?

Wäre zumindest besser. Ob es wirklich nötig ist, kommt auf die Anwendung 
an. Ich denke mal für die, um die es hier geht (neue Worte für ein 
Forth-System dauerhaft abzulegen) würde man die Mühe wohl sparen können. 
Da passiert ja letztlich nichts anderes, als bei dem ganz normalen 
Entwicklungszyklus für ein AVR-Programm, d.h.: die Schreibvorgänge auf 
den Flash dürften ähnlich häufig sein.

von Oliver S. (oliverso)


Bewertung
0 lesenswert
nicht lesenswert
~Mercedes~ schrieb:
> Kann man den Flash nicht nur in größeren Blöcken
> beschreiben / löschen?

Kann man.

~Mercedes~ schrieb:
> Da müßte man ja sowas wie ne Speicherverwaltung
> proggen, damit die Flash - Zellen gleichmäßig
> abgenutzt werden, nicht wahr?

Wenn sich die Daten andauernd ändern, sind sie im RAM besser aufgehoben.

Oliver

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
~Mercedes~ schrieb:

> Kann man den Flash nicht nur in größeren Blöcken
> beschreiben / löschen?

Kommt noch hinzu. Entweder muss man jedes FORTH-Wort in eine eigene 
Flash-Page schreiben, oder man muss das vorher auslesen, was schon drin 
steht.

> Da müßte man ja sowas wie ne Speicherverwaltung
> proggen, damit die Flash - Zellen gleichmäßig
> abgenutzt werden, nicht wahr?

Das wäre der nächste Schritt.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:
> a, aber man kann den Blockinhalt lesen und den Teil, den man davon
> behalten will in den Schreibpuffer der Flash-Mimik schreiben, bevor man
> den Block löscht.

Muss man ja nicht einmal. Man kann den Puffer mit 0xFFFF vorbelegen und 
dann nur das füllen, was man schreiben will, ohne die Page zu löschen. 
Löschen ist ultimativ mehr Stress für die Zellen als Schreiben.

Aber für den Anfang würde es sicher genügen, pro Wort eine Page zu 
benutzen (oder mehrere, falls die Implementierung des Worts länger ist).

von c-hater (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Jörg W. schrieb:

> Muss man ja nicht einmal. Man kann den Puffer mit 0xFFFF vorbelegen und
> dann nur das füllen, was man schreiben will, ohne die Page zu löschen.

Vorsicht. Das funktioniert natürlich dann nicht, wenn der zu ändernde 
Bereich nicht leer war. Also immer dann, wenn es nicht nur darum geht, 
etwas anzuhängen, sondern wenn tatsächlich beliebige Änderungen des 
Inhalts möglich sein sollen.

> Löschen ist ultimativ mehr Stress für die Zellen als Schreiben.

Eine wirklich belastbare Veröffentlichung dazu habe ich nicht finden 
können. Bei dem, was ich zum Thema gefunden habe, war im allgemeinen der 
Tenor: Löschen und Schreiben bedeutet gleichermaßen Streß für den Flash.

von ~Mercedes~ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich kenn forth nicht so...

Aber könnte man es nicht den Programmierer
überlassen, wenn er genug neue Worte kreiert hat (im RAM)
durch LERNE! (achnee, das Ausrufezeichen ist ja schon ein forth - Wort)
die selbst ins Flash laden kann, dann wäre die Belastung nicht so hoch.

mfg

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
c-hater schrieb:
>> Löschen ist ultimativ mehr Stress für die Zellen als Schreiben.
>
> Eine wirklich belastbare Veröffentlichung dazu habe ich nicht finden
> können.

War die Aussage meiner früheren Kollegen zum Thema (bei einem größeren 
Halbleiterhersteller ;-).

: Bearbeitet durch Moderator
von Theor (Gast)


Bewertung
0 lesenswert
nicht lesenswert
~Mercedes~ schrieb:
> Ich kenn forth nicht so...
>
> Aber könnte man es nicht den Programmierer
> überlassen, wenn er genug neue Worte kreiert hat (im RAM)
> durch LERNE! (achnee, das Ausrufezeichen ist ja schon ein forth - Wort)
> die selbst ins Flash laden kann, dann wäre die Belastung nicht so hoch.
>
> mfg

Ja. Das geht. Das ist tatsächlich die Variante, die ich im Moment 
benutze.

PS. Das ein Zeichen oder auch eine Kette von Zeichen in einem neuen Wort 
vorkommt, ist zulässig und bewirkt keinen Fehler. Tatsächlich kann man 
sogar Worte neu definieren ohne die alte Definition zu löschen. Es wird 
immer die jüngste Definition verwendent, weil das Dictionary von 
"hinten", d.h. von der jüngsten zur ältesten Definition durchsucht wird.

von Theor (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> c-hater schrieb:
>>> Löschen ist ultimativ mehr Stress für die Zellen als Schreiben.
>>
>> Eine wirklich belastbare Veröffentlichung dazu habe ich nicht finden
>> können.
>
> War die Aussage meiner früheren Kollegen zum Thema (bei einem größeren
> Halbleiterhersteller ;-).

Das Thema hatten wir hier auch schon mal vor ein paar Jahren. Ich glaube 
sogar, Du, Jörg, hattest da was geschrieben.

von ~Mercedes~ (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Achja, ich würde um das Design in c bitten, damit
ich nem Lehrer helfen kann bei einem Projekt,
das durch das ganze Hin und Her mit mir schon
ein Jahr hängt... ;-O


mfg

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.