Hi, ich habe ein Problem. Ich habe eine Menüführung auf den klassischen
16x02 Displays HD44780. Soweit ist alles klar, läuft am Mega. Geht.
Jetzt habe ich es auf den Xmega umgebaut, da ich mehr power brauche bzw.
mehr Hardwareschnittstellen. Der gleiche Code angepasst entsprechend
läuft an sich, aber die Menüs no chance.
Das Array für die Menüs wird nur bis Einrag 5 angesprochen, dann springt
er zur nächsten Sprache. Wieder 5 weiter, nächste Sprache. Die letzten 2
Sprachen kann ich gar nicht erreichen, da ist er dann im Nirvana. Alles
was hinter Weiche RCN-213 ist, egal welche Sprache, ist ebenfalls nicht
erreichbar. Ausgeben mache ich wie folgt:
lcd_string_p(&displayMenus[language][index], 0, LINE2, FALSE);
Was könnte das sein? Wo ist der Denkfehler?! Warum geht es beim Mega?
Die <avr/pgmspace.h> hast du included?
Lasse dir mal im Debug-Watch-Fenster das Array anzeigen.
Meines wissens kann man auf die Progmem-Variable nicht wie auf normale
Variable im RAM zugreifen. Man muss zuerst mit strcpy_P() den
Flash-String in einen RAM-Buffer kopieren.
Außerdem muss man noch aufpassen, ob man nicht die Farpointer-Varianten
der Funktionen braucht.
Eventuell noch der Hinweis:
"For Xmega devices, make sure the NVM controller command register
(NVM.CMD or NVM_CMD) is set to 0x00 (NOP) before using any of these
functions."
Trennt man die Array-Dimensionen in der Initialisierung nicht mit ";"
und nur innerhalb mit Komma?
Aber ordne mal deine Menü-Definition klarer an, indem du Tabulatoren
verwendest und deine einzelnen Strings sauber ausrichtest.
Verwende gestaffelten Einzug für die Array-Dimensionen.
So erkennt man gleich optisch irgendwelche Fehler.
Hallo,
PROGMEM und avr/pgmspace habe ich natürlich.
Alexxx schrieb:> Die <avr/pgmspace.h> hast du included?>> Lasse dir mal im Debug-Watch-Fenster das Array anzeigen.> Meines wissens kann man auf die Progmem-Variable nicht wie auf normale> Variable im RAM zugreifen. Man muss zuerst mit strcpy_P() den> Flash-String in einen RAM-Buffer kopieren.> Außerdem muss man noch aufpassen, ob man nicht die Farpointer-Varianten> der Funktionen braucht.> Eventuell noch der Hinweis:> "For Xmega devices, make sure the NVM controller command register> (NVM.CMD or NVM_CMD) is set to 0x00 (NOP) before using any of these> functions.">> Trennt man die Array-Dimensionen in der Initialisierung nicht mit ";"> und nur innerhalb mit Komma?>> Aber ordne mal deine Menü-Definition klarer an, indem du Tabulatoren> verwendest und deine einzelnen Strings sauber ausrichtest.> Verwende gestaffelten Einzug für die Array-Dimensionen.> So erkennt man gleich optisch irgendwelche Fehler.
Das ist korrekt angelegt, der Versatz optisch liegt hier am Forum, da es
nicht so breit ist, bei mir im Quellcode sieht es geordnet aus.
Gusi schrieb:>> PROGMEM ist der Befehl dazu, __flash ist glaube eine Alternative oder> alt. Macht aber keinen Unterschied.
Doch, das macht bei der Dereferenzierung einen erheblichen Unterschied,
da man sich die Krücke mit den pgm_read_xxx() Funktionen erspart -- und
damit m.M. eine nicht unerhebliche Fehlerquelle. Aber natürlich darf
hier jeder nach seiner Facon glücklich werden...
Grüßle
Volker
Volker B. schrieb:> Gusi schrieb:>>>> PROGMEM ist der Befehl dazu, __flash ist glaube eine Alternative oder>> alt. Macht aber keinen Unterschied.>> Doch, das macht bei der Dereferenzierung einen erheblichen Unterschied,> da man sich die Krücke mit den pgm_read_xxx() Funktionen erspart -- und> damit m.M. eine nicht unerhebliche Fehlerquelle. Aber natürlich darf> hier jeder nach seiner Facon glücklich werden...>> Grüßle> Volker
Wenn ich das mit __flash mache, wie lese ich den String dann aus?
Gusi schrieb:> Wenn ich das mit __flash mache, wie lese ich den String dann aus?
So, wie Du es auch machen würdest, wenn das Array im RAM liegen würde:
uint8_t Ch = displayMenus[0][1][2];
Grüßle
Volker
Gusi schrieb:> Wenn ich das mit __flash mache, wie lese ich den String dann aus?
Muss man aufpassen.
Volker B. schrieb:> Doch, das macht bei der Dereferenzierung einen erheblichen Unterschied,> da man sich die Krücke mit den pgm_read_xxx() Funktionen erspart -- und> damit m.M. eine nicht unerhebliche Fehlerquelle.
Die pgm_read_xxx()-Krücke kann man sich nur sparen wenn der Compiler
neu genug ist. Mit dem alten Winavr geht das "Sparen" nicht.
Mitlesa schrieb:> Die pgm_read_xxx()-Krücke kann man sich nur sparen wenn der Compiler> neu genug ist. Mit dem alten Winavr geht das "Sparen" nicht.
Da der TO hier aber explizit keine gcc Version genannt hat, gehe ich von
der aktuellsten aus (denn leider klappt's bei mir mit dem Hellsehen nach
wie vor nicht so richtig :-) -- außerdem habe ich genau aus diesem Grund
auf das Tutorial verlinkt.
Grüßle
Volker
Gusi schrieb:> Was könnte das sein? Wo ist der Denkfehler?! Warum geht es beim Mega?
Es gibt einen großen Unterschied zwischen mega und xmega: Der xmega
nutzt für den Zugriff aufs Flash das NVM-Modul. Wenn Du zwischenzeitlich
mit diesem etwas anderes machst, z.B. Signatur- oder Calibration-Bytes
liest und anschließend das Command-Register nicht zurücksetzt, dann
schlägt der nächste Daten-Zugriff aufs Flash fehl.
Grüßle
Volker
Wilhelm M. schrieb:> Gusi schrieb:>> Habe ich doch so.>> Nein, hast Du nicht.
Wie gesagt: lies Dir die Doku nochmal genau durch, und Du wirst einen
Unterschied feststellen.
Volker B. schrieb:> Mitlesa schrieb:>> Die pgm_read_xxx()-Krücke kann man sich nur sparen wenn der Compiler>> neu genug ist. Mit dem alten Winavr geht das "Sparen" nicht.>> Da der TO hier aber explizit keine gcc Version genannt hat, gehe ich von> der aktuellsten aus (denn leider klappt's bei mir mit dem Hellsehen nach> wie vor nicht so richtig :-) -- außerdem habe ich genau aus diesem Grund> auf das Tutorial verlinkt.>> Grüßle> Volker
Korrekt, aktuellste Atmelstudio version
Gusi schrieb:> Wilhelm M. schrieb:>> Gusi schrieb:>>> Habe ich doch so.>>>> Nein, hast Du nicht.>> Doch! PROGMEM ist FLASH! Die Strings liegen im FLASH!
Dann zeigt mal die sections.
Ich habe "den Fehler" gefunden. Naja nicht richig. Mache ich den String
ein Zeichen kleiner (also 15 Zeichen max. statt 16 wie das Display).
Geht es.
Jetzt die Frage: Warum?!
Wilhelm M. schrieb:> Gusi schrieb:>> Wilhelm M. schrieb:>>> Gusi schrieb:>>>> Habe ich doch so.>>>>>> Nein, hast Du nicht.>>>> Doch! PROGMEM ist FLASH! Die Strings liegen im FLASH!>> Dann zeigt mal die sections.
Ich kann die hex hier hochladen, dann siehst du es, dass die da drin
liegen. Außerdem, mit/ohne PROGMEM steigt entweder der RAM verbrauch
(ohne PROGMEM) oder mit PROGMEM steigt der Flash verbrauch.
Ich mache das schon ewig so, das ist korrekt, wird auch bei dem Link so
angezeigt was hier gepostet wurde:
https://www.nongnu.org/avr-libc/user-manual/pgmspace.html
PROGMEM ist der Befehl für Flash
EEMEM ist der Befehl für EEPROM
Um da Sachen abzulegen. Sonst gehen die halt in den RAM.
Gusi schrieb:> Ich kann die hex hier hochladen, dann siehst du es, dass die da drin> liegen.
Würde ich an deiner Stelle auch so machen ;)
Gusi schrieb:> Ich habe "den Fehler" gefunden. Naja nicht richig. Mache ich den String> ein Zeichen kleiner (also 15 Zeichen max. statt 16 wie das Display).
Du weist, dass das String-Ende-Zeichen (\0) auch in deinem String
steckt? Also hat dein Wort 16 Zeichen muss der String 17 Zeichen lang
sein da das String-Ende-Zeichen mit rein passen muss. ;)
M. K. schrieb:> Gusi schrieb:>> Ich kann die hex hier hochladen, dann siehst du es, dass die da drin>> liegen.>> Würde ich an deiner Stelle auch so machen ;)>> Gusi schrieb:>> Ich habe "den Fehler" gefunden. Naja nicht richig. Mache ich den String>> ein Zeichen kleiner (also 15 Zeichen max. statt 16 wie das Display).>> Du weist, dass das String-Ende-Zeichen (\0) auch in deinem String> steckt? Also hat dein Wort 16 Zeichen muss der String 17 Zeichen lang> sein da das String-Ende-Zeichen mit rein passen muss. ;)
Klar, das weiß ich das habe ich gemacht. Ich habe das Problem gefunden.
Der Compiler hat die Defines nicht angenommen und irgendwas da
reingesetzt. Jetzt habe ich die Defines unter die Einbindung aller
Bibliothkene gemacht, statt drüber, jetzt geht es. Aber in keiner
Bibliothek gibt es Defines mit dem gleichen Namen die zum Redefine
hätten führen können.
Verstehe ich nicht so ganz ehrlich gesagt.
Gusi schrieb:> Der Compiler hat die Defines nicht angenommen und irgendwas da> reingesetzt.
Da hast Du ja bestimmt ne Warnung bekommen, wenn er ein Macro
redefiniert, oder? Oder ...
Wilhelm M. schrieb:> Gusi schrieb:>> Der Compiler hat die Defines nicht angenommen und irgendwas da>> reingesetzt.>> Da hast Du ja bestimmt ne Warnung bekommen, wenn er ein Macro> redefiniert, oder? Oder ...
Ja. Habe ich. Übersehen. Blöd. Warum er das macht weiß ich dennoch
nicht.
