EEPROM als FLASH

Welcher Mikrocontroller?

... ... schrieb:
> ATMEGA8
>
> PS: das hier habe ich gelesen Beitrag "Atmega8 Programm in Hex, aus EEPROM ausführen"
>
> hex will ich nicht, wenn dann schon fertig binäres... klar

Dann hast du sicher auch das hier gelesen:

Michael U. schrieb:
> einfache Antwort: geht nicht. Die AVR können Programmcode nur aus dem
> Flash ausführen.

> das kann schon irgendwie, lass dir da nichts einreden.

[...]

> ich bin nicht so sehr in die architektur der avrs vertraut

Eben. Also mach ihm auch keine Hoffnung.

> möglicherweise kannst du den code aus dem eeprom in den ram kopieren und
> direkt aus dem ram ausführen.

Nein, das geht nicht, da beim AVR Datenspeicher und Programmspeicher 
(Flash) über getrennte Busse angesteuert werden und damit auch getrennte 
Adressbereiche haben. Es ist schlicht nicht möglich, in das SRAM zu 
springen und dort Code auszuführen.

Siehe auch:
http://de.wikipedia.org/wiki/Harvard-Architektur

> oder per sd karte - es gibt genug bootloader im netz. diese können auch
> den internen flash beschreiben und danach ausführen.
> was du also machen kannst ist einen dieser bootloader zu modifizieren,
> je nach state können also andere .bin dateien in den internen flash
> geladen und ausgeführt werden.

Das ist theoretisch möglich, auch wenn nicht alle AVRs den 
Schreibzugriff auf das Flash vom Programm aus erlauben. Aber was 
"nomatrix" machen möchte und was ein Bootloader tut, sind zwei völlig 
verschiedene Paar Schuhe.

Den Flash zu löschen und neu zu schreiben dauert vergleichsweise sehr 
lange. Die Schreibzyklen sind begrenzt, das heißt das Flash verschleißt 
beim Schreiben und erzeugt irgendwann Bitfehler. Die Prozedur ist zudem 
recht kompliziert, bitte lies den entsprechenden Abschnitt im 
Datenblatt.

Bei Firmware-Updates, die sehr selten mal vorkommen, sind diese 
Nachteile akzeptabel. Zur Laufzeit des Programms allerdings ständig 
benötigte Code-Teile zwischen Flash und einem externen Speicher hin- und 
herzukopieren, ist Schwachsinn und führt zu einer langsamen 
Programmausführung und dem baldigen Ableben des Flashs.

Wenn dein Flash zu klein ist, schreib effizienteren Code, oder wechsele 
zum nächsthöheren Modell mit mehr Flash.

Das EEPROM als dritte Art von Speicher ist übrigens nicht ohne Grund in 
die meisten AVRs eingebaut: Atmel hat durchaus die Notwendigkeit 
erkannt, einige wenige Variablen nicht-flüchtig zu speichern, zum 
Beispiel die Konfiguration eines Gerätes, und hält den Flash-Speicher 
dafür anscheinend selbst nicht geeignet.

Für dein Problem (was ist das genau?) gibt es mit Sicherheit eine 
bessere Lösung.

Was man extern speichern kann, sind Konstanten und Tabellen mit 
Zeichensätzen oder Grafiken. Da man diese dann nicht im internen Flash 
ablegen muss, hat man mehr Platz für das Programm. Ansonsten würde ich 
diesen Tipp beherzigen:

Oliver Döring schrieb:
> Wenn dein Flash zu klein ist, schreib effizienteren Code, oder wechsele
> zum nächsthöheren Modell mit mehr Flash.

Dazu kommt, dass dieser Mechanismus einigen Einschränkungen unterliegt. 
Du kannst den Flash nur aus dem Bootsektorbereich heraus beschreiben.

Und ich gebe auch noch zu bedenken: So ein Mechanismus mit dynamischen 
Nachladen ist nicht trivial. Auch der benötigt Code. Und aus dem Bauch 
heraus würde ich mal sagen: Der Mechanismus alleine braucht mindestens 
so viel Code, wie du für LCD Routinen, UART Routinen und noch 2 bis 3 
typische AVR-Module  zusammen verbrutzeln wirst. Du treibst also den 
Teufel mit dem Belzebub aus.

Es geht doch, allerdings braucht man dazu eine Art 'Interpreter' ,der 
logischerweise im Flash residiert. Habs neulich mal auf AVRFreaks 
gelesen und als Spässchen abgetan, denn im Prinzip isses ja Quatsch bei 
dem im Vergleich zum Flash winzigen Speicherplatz. Aber wers braucht :P 
Bin bloss zu faul, den Thread rauszusuchen.

... ... schrieb:

> Nicht von externem Speicher ausfühen können ist echt Mist.

Dann hast Du schlichtweg die falsche Prozessorarchitektur gewählt. Dein 
Fehler! ARM und MIPS (PIC32 z.B.) können das.

fchk