Hallo Leute, ich stehe vor folgendem Problem. Ich habe den AT90CAN128. Mit diesem µC lese ich CAN Botschaften, werte diese aus und stelle bestimmte Informationen auf einem Display dar. Ich möchte unter anderem Verkehrszeichen darstellen. Das Verkehrszeichen wird mit Hilfe eines Koverters in eine Header Datei umgewandelt. (siehe Anhang - als Beispiel ist das Bild und der dazugehörige Code angehangen). Diese .h-Datei wird nun per #include in die Software eingebunden. Die Software und die Ausgabe etc. funktioniert super. Nun gibt es aber ein Problem. Ab einer bestimmten Anzahl von Schildern die ich so einbinde, funktioniert das Programm bzw. die Darstellung nicht mehr. Das Display zeigt dann nur noch verzerrte "Bilder" oder einfach nur noch rauschen. Sobald ich dann die bestimmte Anzahl wieder unterschreite, funktioniert wieder alles super. Nun hat man mir gesagt, dass es wohl am Speicher liegen wird. Was ja auch irgendwie erstmal logisch klingt. Allerdings, wenn ich die Software im AVR Studio kompiliere, kommt folgendes Ergebnis: Build started 13.9.2012 at 18:14:07 AVR Memory Usage ---------------- Device: at90can128 Program: 81612 bytes (62.3% Full) (.text + .data + .bootloader) Data: 687 bytes (16.8% Full) (.data + .bss + .noinit) Build succeeded with 0 Warnings... Demnach ist der Speicher ja nicht voll. Was kann das Problem sein? Ich habe keine Erklärung dafür. Vielleicht hatte jemand von euch ein ähnliches Problem oder eine Erklärung dafür. Vielen Dank und viele Grüße, Christoph
Angehängte Dateien:
-
Sign_10.png
951 Bytes
Bei mehr als 64k Flash funktioniert LPM (Load from Program Space) nicht mehr, Du musst ELPM nehmen und RAMPZ passend setzen. Wenn Du diese Befehle nicht selber benutzt, sondern den Compiler entsprechenden Code erzeugen lässt, ist dieser möglicherweise nicht korrekt. Dann mach es per Hand. Und denk dran: Deine Adressen im flash sind hier 17 Bit breit. unsigned int oder unsigned short reichen also nicht mehr. Beim Mega 2560/2561 sind es 18 Bit. fchk
Hallo Frank, vielen Dank für deine schnelle Antwort. Leider weiß ich nicht genau was du meinst, bzw. wie ich das manuell umstellen kann. Kannst du mir da vllt. helfen oder sagen wo ich das finden kann? Vielen Dank!
>Bei mehr als 64k Flash funktioniert LPM (Load from Program Space) nicht >mehr, Du musst ELPM nehmen und RAMPZ passend setzen. pgm_read_byte_far()?
holger schrieb: > pgm_read_byte_far()? Hallo Holger, was kann ich mit dem Befehl machen? Also ich verstehe den Zusammenhang gerade nicht. In den Speichersachen stecke ich nicht so tief drin.
Die Daten der Bilder in den einzelnen Header Dateien sind wie ich jetzt mitbekommen habe im Flahspeicher abgelegt PROGMEM. Ich habe jetzt überall PROGMEM durch EEMEM ersetzt. Beim kompilieren gab es keine Probleme, beim flashen des µCs aber. Folgende Fehlermeldung kam: Getting isp parameter.. SD=0x01 .. OK Validating ELF input file.. OK! Reading FLASH input..OK! Reading EEPROM input..OK!ELF eeprom input does not fit in device Setting mode and device parameters.. OK! Entering programming mode.. OK! Erasing device.. OK! Programming FLASH .. OK! Reading FLASH .. OK! FLASH contents is equal to file.. OK Programming EEPROM .. OK! Reading EEPROM .. OK! WARNING: EEPROM address 0x0000 is 0xFF (should be 0x00).. FAILED! Leaving programming mode.. OK!
lies dir dochmal die doku zum avr-gcc durch: http://www.nongnu.org/avr-libc/user-manual/group__avr__pgmspace.html
Ja also nachdem ich die Header Dateien ja umgeändert habe, werden die Daten ja im EEPROM abgelegt. Meine ganzen Funktionen, die ich für das Display habe, lesen die Daten aber aus dem Flashspeicher. Daher wahrscheinlich die Probleme beim flashen oder? Ach ich bin verwirrt.
Andi D. schrieb: > lies dir dochmal die doku zum avr-gcc durch: > http://www.nongnu.org/avr-libc/user-manual/group__... Hallo Andi, vielen Dank für den Link. So langsam setzt sich das Puzzle zusammen. Ich werde erstmal versuchen das nachzuvollziehen. VG
Christoph A. schrieb: > Ja also nachdem ich die Header Dateien ja umgeändert habe, werden die > Daten ja im EEPROM abgelegt. > > Meine ganzen Funktionen, die ich für das Display habe, lesen die Daten > aber aus dem Flashspeicher. Daher wahrscheinlich die Probleme beim > flashen oder? > > Ach ich bin verwirrt. schau dir dochmal bitte das datenblatt zum controller an !!! wieviel eeprom hat der wohl ? genau zu wenig..deine daten passen da nicht rein und deswegen funktioniert das flashen nicht! dem compiler/linker ist es ziemlich egal wie groß die sachen sind solange es erzeugt werden kann. progmem ist schon der richtige weg aber du musst dir jetzt einmal den link anschauen den ich gepostet habe und die posts hier lesen... nach der 64kbyte programmgrenze musst du anderst mit progmem daten arbeiten! d.h. deine funktion zum auslesen der daten muss geändert werden!
Ok, also PROGMEM lass ich so wie es war, aber die Funktionen zum auslesen muss ich anpassen. Und die Anpassungen finde ich in dem Link, den du mir geschickt hast. Also die ganzen Variablen und Funktionen benutzen pgm_read_byte. Beispiel: PixelColorIndex = pgm_read_byte(&Pbmp[Pos++]); Und diese ganzen Sachen müsste ich ersetzen?
Christoph A. schrieb: > Beispiel: > PixelColorIndex = pgm_read_byte(&Pbmp[Pos++]); > > Und diese ganzen Sachen müsste ich ersetzen? prinzipiell ja..wenn du allerdings string funktionen o.ä. mit _p am ende verwendest funktionieren die nicht (siehe link)
Ok, noch zum allgemeinen 'Verständnis. Der Flashspeicher ist größer als der EEPROM? Wenn ich jetzt die Funktionen ändere, was genau ändere ich da? Also steckt dahinter? Das habe ich noch nicht ganz verstanden? Kann ich jetzt überall ein _far dranhängen, wie holger bereits geschrieben hat?
1. datenblatt lesen (sry da kommst du echt nicht drum herum..) http://www.atmel.com/Images/doc7679.pdf da steht sowas drinnen wie: * 32K/64K/128K Bytes of In-System Reprogrammable Flash (AT90CAN32/64/128) * 1K/2K/4K Bytes EEPROM (Endurance: 100,000 Write/Erase Cycles) (AT90CAN32/64/128) jetzt kannst du mal raten wieso es mitm eeprom nicht geht ;) 2. dein programm braucht über 64kbyte speicher -> wenn deine grafiken oberhalb von 64k liegen (wert 2^16) können die einfachen pgm funktionen diesen nciht mehr adressieren und drauf zugreifen.. deswegen musst du die _far funktionen mit 32bit adressen nehmen... versuch es ob es mit stumpfen ändern ohne nachdenken geht..wenn nicht musst du ein wenig zeit + grundlagen investieren um es zum laufen zu bekommen..
Christoph A. schrieb: > Ok, noch zum allgemeinen 'Verständnis. Der Flashspeicher ist größer als > der EEPROM? Ja. 128k vs. 4k > Wenn ich jetzt die Funktionen ändere, was genau ändere ich > da? Also steckt dahinter? Das habe ich noch nicht ganz verstanden? pgm_read_byte erwartet eine 16 Bit Adresse. Du brauchst aber 17 Bit, um die ganzen 128k des Flashes zu adressieren. Momentan fehlt Dir die, d.h. wenn Du auf Adresse 0x13344 zugreifen möchtest, greifst Du in Wahrheit auf Adresse 0x03344 zu, und da steht nicht das drin, was Du erwartest. pgm_read_byte_far erwartet eine 32 Bit Adresse, und damit kannst Du den ganzen Speicher adressieren. > Kann ich jetzt überall ein _far dranhängen, wie holger bereits > geschrieben hat? Das ist der erste Schritt. Im zweiten musst Du sicherstellen, dass alle Variablen, die Flash-Adressen enthalten, 32 Bit statt 16 Bit groß sind. Falls Du also Pointer in int oder short umgewandelt hast, musst Du daraus longs machen. fchk
Ich würde die Bitmaps in einen seriellen Flash auslagern. Die 8Pinner gibts bis 8MB, da hast Du reichlich Platz. Allerdings laufen die nur bis max 3,3V. Peter
Vielen Dank für eure super Antworten. Ich werde mal schauen wie ich das löse. Ein _far dranhängen, wäre nicht das Problem, aber die ganzen Variablen ändern, ist ein riesiger Aufwand. Da das Programm nicht ganz trivial und kurz ist. Aber ich werde mal sehen was sich machen lässt. Trotz alledem habe ich wieder eine Menge dazugelernt. Dieses Forum ist einfach super toll, besser als jede Vorlesung. VG Christoph
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.