Hallo, ich habe ein 3,25" Display an einem ATmega2560 in Betrieb. Auf dem Display gibt es mehrere Seiten zum Durchschalten. Jede Seite hat ein Hintergrundbild und darauf werden dann informationen dargestellt. Jetzt habe ich folgendes Problem: Sobald mein 'Program' Speicher über 30% voll ist werden nurnoch meine Grafiken fehlerfrei Dargestellt und die Schrift ist nurnoch Ameisenkrieg. Nehme ich ein Hintergrundbild heraus (auch wenns von einer Seite ist, die gerade nicht dargestellt wird, funktioniert wieder alles perfekt. Alle Bilder habe ich als Header Files eingebunden und als unsigned int bzw. char PROGMEM abgespeichert. Weis jemand rat? Ich bin am verzweifeln, muss noch zwei Seiten schreiben und ich kann keine Grafiken mehr einbinden :/ Vieeelen vieelen Dank vorab! AVR Memory Usage ---------------- Device: atmega2560 Program: 72578 bytes (27.7% Full) (.text + .data + .bootloader) Data: 646 bytes (7.9% Full) (.data + .bss + .noinit)
Eric schrieb: > Jetzt habe ich folgendes Problem: Sobald mein 'Program' Speicher über > 30% voll ist werden nurnoch meine Grafiken fehlerfrei Dargestellt und > die Schrift ist nurnoch Ameisenkrieg. Nehme ich ein Hintergrundbild > heraus (auch wenns von einer Seite ist, die gerade nicht dargestellt > wird, funktioniert wieder alles perfekt. Das hat bestimmt nix mit dem Program+Data-Speicher (also dem Flash auf dem AVR) zu tun. Ich tippe darauf, dass Dir das RAM ausgeht, vermutlich kopierst Du Dir ohne es zu merken einen Teil Deiner Nutzdaten (z.B. den Font - der geht ja anscheinend kaputt) ins RAM. Für alles weitere bräuchte man den Sourcecode. Viele Grüße, Simon
hey, danke für die schnelle Antwort. Ja, das ist gut möglich, aber meine Informationen werden alle dargestellt. Die kommen vom CANbus, werden umgerechnet und zum großen teil über dtostrf auf das Display geschrieben. Das funktioniert auch zuverlässig für alle seiten, erst wenn ich noch eine größere Datei (z.B. nen Bild) mit compiliere - egal ob ichs anzeigen lasse oder nicht - zerhauts mir den ganzen Text. den source code darf ich leider nicht einfach veröffentlichen :/
Ich denke auch, dass du irgendwo (unabsichtlich) eine Menge SRAM verbrauchst. zb die Bildanzeige. Kann es sein, dass du da zwischendurch ein großes Array im Speicher anlegst, das Bild als ganzes aus dem Flash dorthin kopierst und dann vor dort die eigentliche Ausgabe machst? Das würde (unnötigerweise) eine nicht geringe Menge SRAM verbrauchen, wodurch du dir den Stack zerschiesst. Auch wenn du dein ganzes Programm nicht heerzeigen kannst, dann müsste es doch möglich sein, zumindest die relevanten Ausschnitte zu zeigen. Ohne Code kann dir keiner suchen helfen. Da hättest du dir die Anfrage auch gleich sparen können.
also so wie ihr das schreibt und anhand dessen was ich übers googlen rausbekommen habe bin ich mir sicher, dass das mein Fehler ist. Ich haue sicher den SRAM voll, weis aber nicht wie ich das beheben könnte. Habe hier mal einen Teil des Programmcodes genommen, nur paar namen rausgenommen und relevante teile umbenannt. Müsste passen. Ist nur die erste Seite, aber die anderen sind ähnlich aufgebaut. Habe noch die beiden anderen Dateien angehangen, das eine ist ein Beispiel für ein Bild, in der anderen steht die funktion zum Bild drinen.
Die Funktion LCD_Bitmap_256high wie sieht die aus? Komm schon. Poste alles. Kein Mensch klaut dir das Programm, so gut ist das dann auch wieder nicht. Wir suchen Funktionen, in denen großere Mengen von lokalen Variablen benutzt werden. Irgendwelche große Arrays. Welche Funktionen dafür in Frage kommen, kann man bis jetzt nur raten: Alles wo größere Datenmengen bewegt werden. Bilder, Fonts sind erst mal heiße Kandidaten.
hm diese kann ich leider nicht einstellen, da die Funktionen vom Displayhersteller mit bereitgestellt wurden. ich schicke dir gern ne PM mit der Funktion, wenn du dich dem weiter annehmen würdest. Bin total begeistert um diese Uhrzeit noch Hilfe zu bekommen. Vielen Dank dafür. Das steht im Quelltextkopf:/ / You received an individual source code license for this display library. // You are allowed to use these routines in any project, even commerical ones // without paying any license fee s long as you never pass this source code to anybody else ! // You may pass your compiled program of course. // // This license includes the need for you to keep the following lines in your source. // This means, you are not allowed to delete the following 8 lines. These are needed to prevent // you of forgetting the fact that you are not allowed to pass this file to anybody in a readable form.
Sind (Hintergrundbild+Font) zufaellig groesser als 64kB? Wie greifst Du auf den Font zu? pgm_read_byte oder pgm_read_byte_far etc? PGM_P pointer gehen nur bis 64kB etc...
Eric schrieb: > wenn ich noch eine größere Datei (z.B. nen Bild) mit compiliere - egal > ob ichs anzeigen lasse oder nicht - zerhauts mir den ganzen Text. Dann schau doch mal in den Speicher im Debugger oder Simulator wo, bzw wann in welcher Funktion sich der Stackpointer, den Daten annähert. (Der Stackpointer kommt von oben) Ich würd es mit kleinen BMPs probieren, die im Speicher anhand von Bitfolgen schnell zu lakalisieren sind. Sind die Bmp eventuell komprimiert und müssen in der LDC_Bitmap() erst entpackt werden?
ähm Zugriff geschieht über pgm_read_byte
const unsigned char Byte = pgm_read_byte(&FD->FontInfo.Data[ByteIndex]);
...
//if (FD->FontInfo.PosTable == NULL) return; // bad font
unsigned int CharDataIndex = 4+pgm_read_word(&FD->FontInfo.Data[4
+ (Ch - BASE)*2]);
const unsigned char ColCount =
pgm_read_byte(&FD->FontInfo.Data[CharDataIndex]);
usw.
der font ist ~15kb und meine Bilder habe ich in mehrere kleine Dateien
aufteilen müssen, da die sonst nicht dargestellt werden. Jedes Bild
einzeln ist kleiner als 64kb, aber alle zusammen sind locker größer als
64kb, allein die Startseite hat auf meiner Festplatte von 56kb
@ Michael
#EDIT
ja, die bmps sind komprimiert, sollte ich mal ohne probieren ? dann
werden die Dateien aber locker 5-6x größer pro Stück. Wegen
'stackpointer' muss ich mal gucken, ich programmiere noch nicht lange,
sagt mir gerade noch nichts ^^
Mit den gepackten BMPs meine ich, dass die eventuell im Stück entpackt werden , und Dir den Stack vollknallen. Du hast nur 8kb für data und stack zusammen! ...sofern ohne externen Ram.
pgm_read_byte/word nehmen einen uint16_t als Adresse, das geht nur bis max 64kB Daten im Flash. Siehe http://www.nongnu.org/avr-libc/user-manual/pgmspace_8h.html. Wenn Daten jenseits der ersten 64kB im Flash liegen, geht nur pgm_read_xxxx_far. Ich vermute, durch mehr von Deinen Hintergrundbitmaps ist Dein Font jenseits der 64kB-Grenze gerutscht und jetzt liest Du Daten an (adresse modulo 65536) was natürlich nicht das gewünschte Ergebnis hat. Normalerweise sortiert der Linker so, dass die .data section so weit unten im Flash liegt wie moeglich.
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.