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
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.)
YAFFA-Forth -> löschen
AmForth -> installieren
Nähere Download & Infos: http://amforth.sourceforge.net/
Ein besseres Forth wirst du so schnell nicht finden.
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
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.
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.
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.
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.
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
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. :-)
~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.
~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
~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.
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).
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.
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
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 ;-).
~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.
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.
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
