fop schrieb:> Die Suchen & Ersetzen Funktion Deines Editors ? Suche "char", ersetze> durch ...
So meinte ich das nicht.
Ich möchte gerne die Variablen mit im Programmspeicher einbetten (sind
Konstante Pointer Strings), aktuell sind sie ja im SRAM.
1
AppStrings_tconstStringsPROGMEM;// das bewirkt nichts...
Georg G. schrieb:> Ein schneller Blick in die libc-Hilfe zeigt beim Thema pgmspace, dass es> z.B. den Typ PGM_p gibt.
Habe ich bereits gesehen. Das funktioniert aber nur mit char Array´s?!
Johann L. schrieb:>> const char * const PROGMEM PrjName;>> Das sollte einen Fehler geben.
Nö. Ich hatte das vorher getestet. Der avr-gcc nimmt das anstandslos.
> const __flash AppStrings_t mystrings = // mystrings im Flash> {
Die adäquate Version mit PROGMEM - falls eine ältere avr-gcc-Version
benutzt wird, die noch kein __flash versteht:
const AppStrings_t mystrings PROGMEM =
{
Eigentlich macht man ja eine Struct, damit man nicht für jedes Element
einen extra Pointer braucht, sondern nur einen Pointer auf die Struct,
um schnell und codesparend mit Displacement auf die einzelnen Elemente
zugreifen zu können.
Insbesondere die Pointer in den Flash zu legen, hieße ja, die Adressen
sind zur Compilezeit bekannt. Wozu also die Umstände mit Pointern?
Und bei der PROGMEM Variante aufpassen, dass man die PROGMEM C-Strings
bei der Ausgabe anders behandeln muss als "normale" Stringliterale oder
char-Arrays.
In C++ habe ich entsprechende Datentypen dafür und muss den Unterschied
nicht selbst beachten.
Peter D. schrieb:> Eigentlich macht man ja eine Struct, damit man nicht für jedes Element> einen extra Pointer braucht, sondern nur einen Pointer auf die Struct,> um schnell und codesparend mit Displacement auf die einzelnen Elemente> zugreifen zu können.>> Insbesondere die Pointer in den Flash zu legen, hieße ja, die Adressen> sind zur Compilezeit bekannt. Wozu also die Umstände mit Pointern?
Ich gebe dir Recht, aber wie baut man sich diese Struktur zusammen? Wenn
ich nicht die Pointer sondern die Texte direkt im struct ablegen will,
muss ich ja die Arraygrößen bzw die länder der Texten mitangeben:
Frank M. schrieb:> Johann L. schrieb:>>> const char * const PROGMEM PrjName;>>>> Das sollte einen Fehler geben.>> Nö. Ich hatte das vorher getestet. Der avr-gcc nimmt das anstandslos.
Sonderlich sinnvoll ist so ein Code aber nicht. Es ist ungefähr so
sinnvoll, wie unterschiedliche Komponenten eines Struct in
unterschiedliche Sections legen zu wollen.
Immerhin bekomme ich eine Warnung, dass progmem ignoriert wird --
vorausgesetzt, es steht nach dem "PrjName".
Ich benutze die pgmspace.h möglichst nicht und "verschwende" RAM mit der
C-konformen Schreibweise.
Meistens lohnt sich die Mühe auch nicht.
Beim ATMega1284 (16KB RAM) muß mit RAM nicht so geizen.
Peter D. schrieb:> Beim ATMega1284 (16KB RAM) muß mit RAM nicht so geizen.
Beim Arduino Uno und Consorten (alle kleineren AVRs) ist man
häufig sehr dankbar wenn man das RAM zu Lasten des Flash von
den vielen Nicht-Variablen befreien kann.
Rabe schrieb:> Was ist daran fehleranfällig?
Dass ich aufpassen muss, dass die Längenangaben und tatsächliche
Textlängen passen, und die Reihenfolge der Texte und deren Definitionen
die gleiche ist.
Ich hab auch festgestellt, daß die pgmspace.h leider nicht abwärts
kompatibel ist.
Wenn man ältere Projekte aus WINAVR 2010 mit neueren AVR-GCC compiliert,
gibt es Fehlermeldungen (und umgekehrt).
Daher fasse ich die nur noch mit der Kneifzange an.
Peter D. schrieb:> Ich hab auch festgestellt, daß die pgmspace.h leider nicht abwärts> kompatibel ist.> Wenn man ältere Projekte aus WINAVR 2010 mit neueren AVR-GCC compiliert,> gibt es Fehlermeldungen (und umgekehrt).
Es gibt Fehler, wenn man versucht, nicht-const Objekte ins Flash zu
legen. Das ist dann aber ein Problem des Project-Codes, nicht von
pgmspace.h.
Dass avr-gcc nicht-const Daten im Flash ablehnt, ist auch den Release
Notes entnehmbar; wenn man also asbach uralt Projekte übersetzten will,
sollte man auch eine asbach uralt Toolchain verwenden.
Und hast du ein Beispiel, dass Code, der mit einer aktuellen Toolchain
übersetzt, dass mit einem WinAVR-20100110 nicht mehr tut (abgesehen von
damals noch nicht unterstützten Devices, Optionen, Qualifiern, etc).
Johann L. schrieb:> Dass avr-gcc nicht-const Daten im Flash ablehnt, ist auch den Release> Notes entnehmbar; wenn man also asbach uralt Projekte übersetzten will,> sollte man auch eine asbach uralt Toolchain verwenden.
Braucht man nicht. Dann schreibt man const davor und schon läuft es mit
der alten und mit der neuen Toolchain.
Frank M. schrieb:> Johann L. schrieb:>> Dass avr-gcc nicht-const Daten im Flash ablehnt, ist auch den Release>> Notes entnehmbar; wenn man also asbach uralt Projekte übersetzten will,>> sollte man auch eine asbach uralt Toolchain verwenden.>> Braucht man nicht. Dann schreibt man const davor und schon läuft es mit> der alten und mit der neuen Toolchain.
Ja, ich weiß. Hilft aber zunächst nicht weiter, wenn jemand ein Projekt
mit einer neuen Toolchain generieren will und dann Fehler bekommt.
Beispiel ist USBasp
http://www.fischl.de/usbasp/
Da kannst dann erst mal auf die Suche gehen, wo das const hin muss...