Hallo,
ich bin dabei, mir einen kleinen (Forth-ähnlichen) Kommando-Interpreter
für den Atmega328p in C zu programmieren.
Dabei tritt nun das Problem auf, dass die benutzerdefinierten
Secondaries remanent gespeichert werden müssen - die Secondaries als ein
Array aus Structs, die aus einem Token und einem Bytecode-Array
bestehen.
Hierbei bevorzuge ich den Flash gegenüber einem externen Speichermedium
wie einer SD-Card. Es gibt zwar eine App-Note für das Schreiben ins
Flash, doch die ist recht knapp gehalten und ohne Anwendungsbeispiel, so
dass ich nicht weiß, wie man die entsprechenden Funktionen für das
Schreiben einer Page oder eines einzelnen Bytes in ein C-Programm
integriert.
Kann mir jemand diesbezüglich Tipps geben, wie ich vorgehen müsste?
Viele Grüße
Glenn
> Kann mir jemand diesbezüglich Tipps geben, wie ich vorgehen müsste?
Doku lesen. Das war jetzt einfach. Aber warum müssen die unbedingt in
den Flash, der 328p hat doch massenweise eeprom?
Allenfalls ist der Anspruch des Projektes auch ueberzogen. Ein 328 ist
etwas auf der sportlichen Seite, den mageren Kenntnisstand des Posters
bedenkend. Bevor irgendwas laeuft wuerd ich mit einem Grosseren
beginnen, also zB einem 2560er. Nachher kann man's immer noch abspecken.
Sonst verballert man zuviel Zeit mit Optimierungen, welche sich nie mehr
auszahlen. Was ist der Mehrpreis eines 2560er zu einem 328er ? 5 Euro ?
Macht erst 500 Euro bei 100 Stueck. In wievielen Tausend Stueck
moechtest du den Mehraufwand wieder reinbringen, resp wie lange darfst
du fuer 500 Euro entwickeln?
Zwei Dinge:
1) Wie ufuf schon schrieb, das Beschreiben des Flash geht nur vom
Bootloader aus. Einige Bootloader (z.B. Optiboot) haben Routinen
(do_spm), die die Anwendung aufrufen kann, um das auch außerhalb des
Bootloaders zu ermöglichen.
2) Byteweise schreiben kann die Hardware nicht - Flash wird pageweise
(beim 328er heißt das 128-Byte-Blöcke) gelöscht und beschrieben.
Ein (ASM-)Beispiel ist im Datasheet des 328 (in meinem ab Seite 338).
Ansonsten schau, wie es andere machen (Optiboot, AmForth, ...) machen.
Gruss
Für ein Grundlegendes Forth System
würde ich externen Speicher, wie geschrieben die SD Karte, nicht
ausschliessen, z.B. auch serielles SRAM. Forth bietet die Möglichkeit zu
Interpretieren und zu Compilieren.
Der Ansatz das mit C zu realisieren, kann als Grundlagen Erarbeitung mit
indirekten Funktionsaufrufen einfach und interessant sein.
Nur in der Summe und den Überblick kann das sehr viel Arbeit werden.
Vor Jahren hatte ich mal, bei einigen Unzugänglichkeiten, ein eForth
übertragen.Das fand ich damals überschaubar.
Dirk St
Dirk S. schrieb:> Für ein Grundlegendes Forth System> würde ich externen Speicher, wie geschrieben die SD Karte, nicht> ausschliessen
Ja, du Tagträumer, aber nicht für
Glenn schrieb:> Speichermöglichkeiten im Atmega328p
Entweder du liest nur das was du lesen willst oder hast null
Ahnung von AVR Mikrocontrollern.
Denn wenn er die I/O-Programmierung für eine SD Karte im
Speicher hat ist schon mal grob ein Drittel bis die Hälfte
des Flash belegt. Ganz abgesehen vom RAM welches auch eine
sehr überschaubare Grösse hat.
Dirk S. schrieb:> Forth bietet die Möglichkeit zu> Interpretieren und zu Compilieren.
Und das alles in 2K RAM gepresst. Ja das wird grossartig.
Nachdem aber der TO auch entweder in die Kategorie Troll
fällt oder keine Ahnung hat ist das alles nicht so schlimm.
Wenn's nicht so wäre (Troll-Kategorie) würden sich vielleicht
mehr Leute um das Thema kümmern, und der Nicht-Troll würde
sich bald mal melden für Butter bei die Fische.
Gruss
Ok, früher war das halt mit wenig Speicher möglich. Warum nicht heute?
Modere Zeiten.
Und voller Standard. Es ging mir nur um die Grundlagen. Der 328p wurde
ja schon relativiert.
Und 2K gingen auch mit weiterem Speicher.
Die Speicher lassen sich auch linearisieren, wie die Tape Speicher
früher. Inclusive Terminal, halt mit Forth.
Agrep mit zwei Delimiter muss es aber jetzt nicht sein.
Dirk St
