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.)
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.
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
:
Bearbeitet durch User
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.
:
Bearbeitet durch Moderator
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 ;-).
:
Bearbeitet durch Moderator
~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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.