Gast
#3552289
Ich habe diesen Code:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
Die Build-Ausgabe ist:
1 | |
2 | |
3 | |
Warum landet der EEPROM-Teil im RAM?
Gast
#3552299
soweit ich weiß ist das ein Fehler bei der Speicherberechnung. Landet aber trotzdem nichts davon im RAM
Gast
#3552331
chris schrieb: > Soweit ich weiß ist das ein Fehler bei der Speicherberechnung. Landet > aber trotzdem nichts davon im RAM Ok. Wie stelle ich den Fehler ab? Der oben dargestellte Code ist naürlich nur ein Beispiel, das Original bekomme ich nicht kompiliert, da die RAM-Nutzung über 100% ist.
Gast
#3552337
uint8_t t[1024] EEMEM ; Check mal das aus!
Gast
#3552338
Natürlich landet das im RAM. Es ist keine Konstante, also veränderbar. Wie willst du das Array im ROM ändern?
Gast
#3552351
Sitterbüss schrieb: > uint8_t t[1024] EEMEM ; > > Check mal das aus! Habe ich gemacht: RunOutputFileVerifyTask-Aufgabe Program Memory Usage : 192 bytes 0,3 % Full Data Memory Usage : 1024 bytes 25,0 % Full EEPROM Memory Usage : 1024 bytes 50,0 % Full Verflucht!
Gast
#3552357
Eprom schrieb: > Warum landet der EEPROM-Teil im RAM? Wenn du so fragst: da der Inhalt von EEMEM im ROM landet und beim Start vom versteckten init-code ins RAM kopiert wird. Ist die Optimierung nicht angeschaltet oder hat das Array einen vorgeladenen Wert, den du uns nicht zeigst? Den so muss er den Inhalt eigentl. nicht kopiert, sondern nur mit 0 initialisiert werden.
Gast
#3552358
TriHexagon schrieb: > Natürlich landet das im RAM. Es ist keine Konstante, also veränderbar. > Wie willst du das Array im ROM ändern? Ich möchte ein uint8_t Array[512] im EEPROM haben.
Gast
#3552359
Sehe erst jetzt, dass die Variable t heißt. Mit EEMEM erzwingst du natürlich das Verhalten.
Gast
#3552370
Müsste eigentlich so passen (gehört EEMEM nicht auf die rechte Seite vom Namen?). Kann natürlich ein Bug sein, wie chris schon ansprach. Welche Version hat den das AVR Studio oder die AVR Toochain?
Eprom schrieb: > Ok. > Wie stelle ich den Fehler ab? Der oben dargestellte Code ist naürlich > nur ein Beispiel, das Original bekomme ich nicht kompiliert, da die > RAM-Nutzung über 100% ist. Das kann ich mir eigentlich nicht vorstellen. Denn der Compiler weiß überhaupt nichts von irgendwelchem kompletten Speicherverbrauch. Das kann frühestens der Linker feststellen. Aber auch dem ist das egal. Der Dump kommt ja von einem eigenen Tool. Maximal kann dir das einen Fehler an make zurückgeben. Zu diesem Zeitpunkt ist aber bereits alles fertig und das Hex-File sollte eigentlich vorhanden sein.
Bei mir geht das. In ein beliebiges Projekt reingesetzt:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
Und den Compiler, Linker oder sonstwen interessiert es einen Sch... ob das da reinpasst.
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
mfg.
Wenn man im Linkerskript die Memory Sections ordentlich setzt, sollte der meckern wenn es ihm zu voll wird.
Gast
#3552822
Keine Ahnung, ob es jetzt am Studio 6.0, am WinAVR/GCC liegt, ich mache es jetzt so:
1 | |
Der Speicherverbrauch fürs EEPROM wird zwar jetzt nicht mehr angegeben, ist mir aber auch wurscht.
Gast
#3552828
Mist, geht auch nicht.
Eprom schrieb: > Mist, geht auch nicht. Nehm mal bitte eine neue Toolchain (z.B. von): http://matrixstorm.com/avr/tinyusbboard/#asmorc oder direkt von Atmel. MfG
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
Keine .data-Section dabei, also gar kein statischer RAM-Verbrauch.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.