AVR - zwischen Bootloader und Programm hin und her springen

[Heinz Rasmussen (Gast)]

Hallo,

ich bastle gerade an einem ultrakompakten Datenlogger, der seine Daten 
optimalerweise im Programm-Flash des AVRs speichern soll. Wie ich das 
Datenblatt verstehe, kann nur ein Programm im Bootloaderbereich den 
Flash beschreiben. Mein Programm ist aber für den Bootloaderbereich 
minimal zu groß. Hat schon mal jemand versucht, zwischen Bootloader und 
normalem Programmspeicher hin- und herzuspringen, also nur die 
Schreibroutine (und ggf. etwas Initialisierungscode) in den Bootloader 
auszulagern?

Grüße,
  Heinz

[Oops (Gast)]

Hallo Heinz,

>Hat schon mal jemand versucht, zwischen Bootloader und
>normalem Programmspeicher hin- und herzuspringen, also nur die
>Schreibroutine (und ggf. etwas Initialisierungscode) in den Bootloader
>auszulagern?

Ja das geht. Habe ich so ähnlich auch schon gemacht. Berechnungen für 
die Programmierung im normalen Coderaum. Das eigentliche Brennen dann im 
Bootlaoderbereich.

Du hast zwar darüber nichts gesagt, aber vielleicht hilft es Dir auch zu 
wissen, das es bei vielen Atmels jeweils verschieden grosse 
Bootloader-Bereiche gibt, die über Fuses einstellbar sind. Aber 
vielleicht weisst Du das auch schon.

Wiesgesagt, die oben beschriebene Idee geht auch.

Gruss
Oops

[Oops (Gast)]

Mir fällt noch ein, das es sich für Dich eventuell lohnen könnte,
die Abschnitte über NRWW-Sektionen im Datenblatt zu lesen.

Ausserdem habe ich gerade gedacht, das Du aufpassen musst, wenn Du in 
eine Page springst die Du gerade erst geflasht hast.

Gruss
Oops

[6639 (Gast)]

Ich wuerde eine externes Flash nehmen. zB ein Atmel Datenflash, 
AT45DB041, ein 512kByte flash im SO8 fuer 74 Cents.

[Peter D. (peda)]

Heinz Rasmussen wrote:

> Hat schon mal jemand versucht, zwischen Bootloader und
> normalem Programmspeicher hin- und herzuspringen, also nur die
> Schreibroutine (und ggf. etwas Initialisierungscode) in den Bootloader
> auszulagern?

Ja, das ist kein Problem.

Dazu richtet man nen API-Call ein, vorzugsweise an Flashend.
Diesem wird ein Zeiger auf ne Struktur im SRAM übergeben, in der die 
Flash-Zieladresse und die zu flashende Page steht.
Als erstes habe ich noch ne Funktionsnummer eingefügt, falls man noch 
mehr Funktionen implementieren will.

Der API-Call muß natürlich in Assembler geschrieben sein und alle 
benutzten Register sichern, damit es nicht zu Konflikten mit der 
Applikation kommt.


Peter

[Ulrich P. (uprinz)]

War es nicht so, dass es eine Atmel AppNote dazu gibt in der beschrieben 
wird, wie die Software im normalen Flash die Flash-Routinen des 
Bootloaders nutzen kann?
Im Grunde braucht man ja nur die Adressen der Routinen zu kennen und 
kann sie dann per extern mit einem adressvector zur Verfügung stellen.

Ich würde aber, gerade bei einem Datenlogger, ein externes 
Speichermedium bevorzugen. Wenn man 3.3V nutzt, kann man eine SD-Karte 
direkt an den AT klemmen oder man nimmt ein MRAM /FERAM dass per I2C 
oder SPI angesteuert wird. Die kosten kaum mehr als ein EEPROM, kennen 
aber keinen Delay für die Eigenprogrammierung und keinen Verschleiß wie 
FLASH oder EEPROM.

Gruß, Ulrich

[Heinz Rasmussen (Gast)]

Danke für die wertvollen Tipps. Es gibt tatsächlich eine Appnote 
(AVR105), die eigentlich alle Fragen beantwortet.
Die Kosten sind übrigens weniger das Problem als der Platz, der gegen 
einen externen Speicher spricht.

[Peter D. (peda)]

Wenn das im gleichen Programm ist, geht das natürlich viel einfacher, 
als eine Bootloaderfunktion in einem fremden Programm aufzurufen.

Du mußt nur die Funktionen, die SPM benutzen in den Bootbereich linken 
lassen.

Da es aber das gleiche Programm ist, gibt es keinerlei Probleme 
hinsichtlich Speicherbelegung und Parameterübergabe.


Peter

[Klaus (Gast)]

Oben schrieb doch ein gutmeinender Teilnehmer:
  "...ein 512kByte flash im SO8 fuer 74 Cents."

Darauf Deine Antwort...
> Die Kosten sind übrigens weniger das Problem als der Platz, der gegen
einen externen Speicher spricht.


Hmmm. Aha. Soso.