#define im Bootloader Bereich

[Philipp S. (philipp09)]

Guten Tag,

zur Zeit schreibe ich einen Bootloader für einen ATMega128. Dieser soll 
später auch in verschiedenen Projekten eingesetzt werden können. Nun 
habe ich für den Bootloader die ".bootloader" section im Flash des 
ATMega ausgewiesen und allen im Bootloader verwendeten Funktionen diese 
als entsprechendes Attribut zugewiesen. Ein Beispiel hierzu:

 void btl_main(void) BOOTLOADER_SECTION;

wobei in der avr/boot.h die Definition zu finden ist:

 BOOTLOADER_SECTION __attribute__((section (".bootloader"))

Nun verwende ich im Bootloader einige #defines, z.B. eines das für einen 
Stringvergleich mit dem Ende eines HEX-Files benötigt wird:

 #define HEXFILE_ENDOFILE ":00000001FF"

 #define HEXFILE_SIZE_ENDOFILE 12

In einer Bootloader-Funktion möchte ich nun diese Definition verwenden 
und benutze hierzu folgende Zeile:

 char endOfFileString[HEXFILE_SIZE_ENDOFILE] = {HEXFILE_ENDOFILE};

Als Test habe ich dann den String HEXFILE_ENDOFILE geändert (z.B. in 
":12340001FE"). Nach einem Buildvorgang habe ich das ursprüngliche und 
das zu Testzwecken erstellte HEX-File miteinander verglichen und konnte 
feststellen, dass nicht etwa eine Änderung in der Boot-Section erfolgte, 
sondern in der Application-Section. Mir scheint, als sei dieser String 
als eine Konstante im Application-Flash abgelegt worden

Zum Hintergrund meines Tests:
Natürlich macht es für mich momentan keinen Sinn, das standartisierte 
Endzeichen eines HEX-Files anzupassen. Dennoch könnten ähnliche 
Änderungen im Bootloader irgendwann möglich sein. In der jetzigen 
Konfiguration würde der Bootloader beim Flashen ja einen Teil seines 
eigenen Speichers (der im Application-Flash steht) löschen.

Ich würde mich freuen, wenn ihr mir auf diesen Sachverhalt eine Antwort 
hättet.

P.S.: Im Anhang befindet sich ein Screenshot von den beiden HEX-Files. 
Links steht das ursprünlgiche HEX-File, rechts das vom Test. Der 
Bootloader Bereich startet bei Adresse E000 (WORD Adresse).

[Peter II (Gast)]

char endOfFileString[HEXFILE_SIZE_ENDOFILE] = {HEXFILE_ENDOFILE};

das HEXFILE_SIZE_ENDOFILE kannst du dir sparen.

Die konstate wird bei init ja gebraucht, dafür spielt es keine rolle wo 
die funktion steht. Die Konstate landen im init datenbereich.

Aber wozu überhaupt der aufwand, mache doch den bootloader als 
eigentständiges Projekt. Dann kannst ihn überall verwenden.

[Thomas E. (thomase)]

Philipp S. schrieb:
> Guten Tag,
>
> zur Zeit schreibe ich einen Bootloader für einen ATMega128. Dieser soll
> später auch in verschiedenen Projekten eingesetzt werden können. Nun
> habe ich für den Bootloader die ".bootloader" section im Flash des
> ATMega ausgewiesen und allen im Bootloader verwendeten Funktionen diese
> als entsprechendes Attribut zugewiesen. Ein Beispiel hierzu:
>
>

 void btl_main(void) BOOTLOADER_SECTION;

Lass das mit den Sections. Schreib das Bootloaderprogramm ganz normal 
und teil dem Linker mit, daß es in den Bootloader-Bereich verschoben 
werden soll.
Dazu gibt es 2 Möglichkeiten:

1. In den Memory Settings
     Memory Type Flash
     Name .text
     Address <Bootloaderadresse> als Word-Adresse

oder
2. in Custom Options/Linker Options
          -Ttext=<Bootloaderadresse> als Byte-Adresse

mfg.

[Thomas E. (thomase)]

Peter II schrieb:
> Aber wozu überhaupt der aufwand, mache doch den bootloader als
> eigentständiges Projekt. Dann kannst ihn überall verwenden.
Richtig. Ein Bootloader ist ein eigenständiges Programm, daß mit der 
Anwendung gar nichts zu tun hat. Weder die Anwendung weiss irgendwas von 
dem Bootloader noch umgekehrt. Wie ein ISP-Programmer. Den interessiert 
es ja auch nicht, was er auf den Controller schreibt.

mfg.

[c-hater (Gast)]

Thomas Eckmann schrieb:

> Richtig. Ein Bootloader ist ein eigenständiges Programm, daß mit der
> Anwendung gar nichts zu tun hat.

Oftmals ist es aber durchaus sinnvoll, wenn Bootloader und App 
voneinander wissen.

1)
Sehr häufig nützlich: Gemeinsam genutzte Gerätetreiber oder 
Protokollstacks. Die verbrauchen dann nämlich nur einmal Platz im Flash 
und es kommt oft vor, daß man über den normalen Kommunikationskanal der 
Anwendung auch flashen können möchte.

2)
Bootloaderaufruf (oder Aufruf von nur aus dem Bootloaderbereich 
arbeitsfähigen Routinen) aus der Applikation heraus. Z.B: für 
Datenlogging im internen Flash. Oder eben auch, um den Bootloader 
starten zu können, ohne physisch zum Aufenthaltsort der Platine latschen 
zu müssen, um den Resetknopf zu drücken.

Die Umsetzung solcher Möglichkeiten schließt übrigens nicht aus, dass 
Bootloader und App weitgehend unabhängig voneinander entwickelt werden 
können.

[Philipp S. (philipp09)]

Hallo,

ihr habt recht. Eine saubere Trennung macht einem das Leben hier wohl 
einfacher. Werde ich versuchen umzusetzen.

Vielen Dank für die Hilfe!

[Thomas E. (thomase)]

c-hater schrieb:
> Oftmals ist es aber durchaus sinnvoll, wenn Bootloader und App
> voneinander wissen.
Eher selten bis nie. Denn laut deiner Aussage von neulich, kriegt man 
das in C doch sowieso nicht hin.

mfg.

[c-hater (Gast)]

Thomas Eckmann schrieb:

> Eher selten bis nie.

Bist du zu blöd zum Lesen? Beispiele dafür, wo das sinnvoll ist, habe 
ich doch genannt.

> Denn laut deiner Aussage von neulich, kriegt man
> das in C doch sowieso nicht hin.

Wo genau soll ich das behauptet haben? Du bist ein Lügner!

[Rufus Τ. F. (rufus)]

Umgangsformen!

[Thomas E. (thomase)]

c-hater schrieb:
> Thomas Eckmann schrieb:
>
>> Das einzige, was ein Bootloader macht, ist auf Daten warten und diese
>> ins Flash zu schreiben. Das kann man auch pollen und spart sich das
>> Verbiegen der Interrupt-Vektoren sowie jede Menge Code.
>
> Ja, so etwa werden die völlig dumme C-Nasen argumentieren, für die alles
> jenseits von main() Teufelszeug ist, was sie niemals richtig begreifen.
>
> Intelligente Asm-Programmierer hingegen schreiben einen (natürlich
> interruptgesteuerten) Gerätetreiber nur einmal und benutzen ihn dann im
> Bootloader und von der Anwendung aus, wodurch er nur einmal Platz im
> Flash benötigt. Das gilt ganz allgemein, nicht nur für den speziellen
> Fall eines RS232-Bootloaders, sondern genauso für Ethernet, USB und was
> auch immer sonst.
>
> Nicht, daß das in C nicht auch ginge, nur sind halt die allermeisten
> C-Programmierer ganz offensichtlich zu blöd dafür, das in ihrer
> bevorzugten Sprache auch tatsächlich umzusetzen.
>
> Das sagt doch wohl eine ganze Menge über die Sprache und noch mehr über
> ihre Apologeten. Wobei hier wohl gilt: Die am lautesten pro-C krakeelen,
> haben am wenigsten Ahnung. Von C nicht und vom Rest der Sache noch
> weniger.

Auf die Knie Wicht, erbärmlicher.

mfg.

[c-hater (Gast)]

Thomas Eckmann schrieb:

> Auf die Knie Wicht, erbärmlicher.

Wieso? Wo schreibe ich da, daß es in C nicht ginge? Es steht sogar das 
genaue Gegenteil dort. Du kannst also wirklich nicht lesen.