Hallo zusammen,
ich habe gerade angefangen, ein 2 Jahre liegengelassenes Projekt mit
einem ATmega32 wiederaufzunehmen. Um eine Übersicht über den
Speicherbereich zu machen habe ich eine kleine SRAM-Dump-Funktion
geschrieben, die mir den Inhalt des SRAMs direkt auf dem angeschlossenen
Grafik-LCD ausgibt.
Da das Grafik-LCD nur 128x64 Pixel hat, muß ich das Ganze natürlich auf
zwei "Bildschirmseiten" aufteilen. Um deuten zu können welche Bereiche
vom Programm überhaupt angetastet wurden, wird der SRAM vorher, soweit
möglich, mit 0xAAs geflutet, gemäß dem Artikel:
http://www.rn-wissen.de/index.php/Speicherverbrauch_bestimmen_mit_avr-gcc
Auf den Fotos oben sieht man die angezeigte Belegung auf dem GLCD.
Konkret wundert mich der Anfang der zweiten Hälte: Ist das realistisch,
wenn ja: Woher mag diese Belegung kommen, oder müssen das Artefakte
aufgrund der Anzeige sein?
Nochfolgend der Quelltext der Anzeigefunktion. Ich denke, die
Funktionsnamen sind selbsterklärend, ansonsten die Erklärung danach.
Viele Grüße
Nicolas
-----
1 | /* Menuehilfsfunktionen: Darstellung des SRAM-Inhalts als Pixelmuster */
|
2 | // Kompletten SRAM, so weit erlaubt, mit 0xAA fuellen, um den vom Programm angetasteten
|
3 | // Bereich sichtbar zu machen (komplett aus Artikel uebernommen)
|
4 | #define MASK 0xaa
|
5 | void __attribute__ ((naked, used, section(".init3"))) init_mem (void);
|
6 | void init_mem (void)
|
7 | {
|
8 | __asm volatile (
|
9 | "ldi r30, lo8 (__heap_start)" "\n\t"
|
10 | "ldi r31, hi8 (__heap_start)" "\n\t"
|
11 | "ldi r24, %0" "\n\t"
|
12 | "ldi r25, hi8 (%1)" "\n"
|
13 | "0:" "\n\t"
|
14 | "st Z+, r24" "\n\t"
|
15 | "cpi r30, lo8 (%1)" "\n\t"
|
16 | "cpc r31, r25" "\n\t"
|
17 | "brlo 0b"
|
18 | :
|
19 | : "i" (MASK), "i" (RAMEND+1)
|
20 | );
|
21 | }
|
22 |
|
23 |
|
24 | /* Darstellung der Speicherbelegung (SRAM) des ATmega32 als Pixelmuster auf dem GLCD
|
25 | * Da da Display nur 1k darstellen kann, warten auf Tastendruck und Darstellung der
|
26 | * zweiten Haelfte */
|
27 | extern unsigned char __heap_start; // From linker script
|
28 |
|
29 | void menu_memdump(){
|
30 | unsigned char *p = &__heap_start;
|
31 |
|
32 | glcd_clear();
|
33 | glcd_abspos(0);
|
34 | for (uint8_t *i = (int *) 0;i < (int *) 1024;i++) {
|
35 | glcd_putdat(*i);
|
36 | }
|
37 |
|
38 | while(!getkeystroke());
|
39 |
|
40 | glcd_clear();
|
41 | glcd_abspos(0);
|
42 | for (uint8_t *i = (int *) 1024;i < RAMEND;i++) {
|
43 | glcd_putdat(*i);
|
44 | }
|
45 |
|
46 | while(!getkeystroke());
|
47 | }
|
----
glcd_clear leert das Display,
glcd_abspos setzt den Cursor auf die erwartete Stelle (0 bis 1024), die
Displayfunktionen sind so geschrieben, daß die Position linear ist und
automatisch auf dem richtigen KS0108 an der richtigen Stelle landet.
glcd_putdat fügt das Bitmuster auf das Display (linear zeilenweise über
das ganze Display)
getkeystroke liefert 1 zurück, wenn ein Taster gedrückt wurde, ansonsten
0.
----
P.S.: Nicht über den schlechten Kontrast wundern. Das Display hat noch
die Schutzfolie.
P.P.S: Hab's gerade gefunden. Ist ein Artefakt. RAMEND ist groesser als
2048. Ich lasse es aber trotzdem mal stehen, falls nochmal jemand auf
das gleiche Problem stößt.