128K: Unterschied zwischen den Versionen
(Die Seite wurde neu angelegt: „=Hinweise für Chips mit mehr als 64K Flash= Es gibt inzwischen einige Atmegas mit mehr als 64K Flash, z.B. den 1284p, der aufgrund der Pinkompatibilität mit de…“) |
(→Hinweise für Chips mit mehr als 64K Flash) |
||
| Zeile 9: | Zeile 9: | ||
- Der Compiler legt bei normalem Code alle PROGMEMs ''vor'' dem Programmcode ab, d.h. selbst wenn die Gesamtgröße des Images über 64K liegt, ist dies nur ein Problem, wenn insgesamt mehr als 64KB PROGMEM-Daten wie Strings, große Tabellen o.ä. angelegt werden | - Der Compiler legt bei normalem Code alle PROGMEMs ''vor'' dem Programmcode ab, d.h. selbst wenn die Gesamtgröße des Images über 64K liegt, ist dies nur ein Problem, wenn insgesamt mehr als 64KB PROGMEM-Daten wie Strings, große Tabellen o.ä. angelegt werden | ||
| − | - Der Bootloader-Code liegt grundsätzlich am oberen Ende des Flashes, daher funktionieren die PSTR-Makros dort nicht. Zugriff auf Daten dort muss dann grundsätzlich explizit mit pgm_XXX_far() erfolgen | + | - Der Bootloader-Code liegt grundsätzlich am oberen Ende des Flashes, daher funktionieren die PSTR-Makros dort nicht. Zugriff auf Daten dort muss dann grundsätzlich explizit mit pgm_XXX_far() erfolgen. |
Aktuelle Version vom 27. September 2011, 15:54 Uhr
Hinweise für Chips mit mehr als 64K Flash
Es gibt inzwischen einige Atmegas mit mehr als 64K Flash, z.B. den 1284p, der aufgrund der Pinkompatibilität mit dem Atmega 32 und 644 einfach in eine NET-IO-Platine eingesetzt werden kann.
Hier existiert ein Fallstrick dadurch, dass der Addressraum nun mehr als 16 Bit groß ist und nun zwischen NEAR (16 Bit) und FAR (>16 Bit) Pointern unterschieden wird.
Im Prinzip handhabt der gcc dies automatisch, es gibt aber eine Einschränkung: Die ganzen Standard-Funktionen, um auf das Flash als Datenspeicher zuzugreifen, arbeiten nur mit 16 Bit Pointern, d.h. sie funktionieren nur, wenn die Daten innerhalb der ersten 64K des Flashes liegen. Dies gilt insbesondere auch für das beliebte PSTR()-Makro, welches auch implizit in control6-Code verwendet wird. Dies ist normalerweise immer noch kein Problem, mit zwei Ausnahmen:
- Der Compiler legt bei normalem Code alle PROGMEMs vor dem Programmcode ab, d.h. selbst wenn die Gesamtgröße des Images über 64K liegt, ist dies nur ein Problem, wenn insgesamt mehr als 64KB PROGMEM-Daten wie Strings, große Tabellen o.ä. angelegt werden
- Der Bootloader-Code liegt grundsätzlich am oberen Ende des Flashes, daher funktionieren die PSTR-Makros dort nicht. Zugriff auf Daten dort muss dann grundsätzlich explizit mit pgm_XXX_far() erfolgen.
