Servus,
ich möchte mich von den 8Bit AVR verabschieden und in die Welt der ARM
einsteigen. Es gibt nur einen Grund da alle meine Anwendungen super
unter AVR zurecht kommen, meine Gier nach neuen Sachen.
Gibt es dazu gute Tutorials ohne Atmel Start oder ASF? Nach einfachem
Übersetzen in Atmel Studio 7 ohne von mir eingefügten Code sind 25% des
Flash und RAM belegt, ich möchte wissen warum. Also einfach alles.
Gruß
Alex
arm-none-eabi-objdump --print-size --size-sort <name der ELF-Datei>
zeigt dir das.
Atmel START ist leider manchmal etwas aufgeblasen.
Weiß nicht, was der SAMD09 so an Ressourcen hat, mehr oder weniger der
Standard bei diesen kleinen Atmel-ARMs (also das, was bei AVR der
ATmega328 ist) wäre dort der SAMD21. Die sind gar nicht mal so klein.
Habe jetzt gerade gesehen, für nur wenig mehr Geld bekommt man schon ein
SAME51 Curiosity Nano Board, das ist schon ein ziemlicher Bolide (1 MiB
Flash, 256 KiB RAM).
Jörg W. schrieb:> zeigt dir das.
Schlecht Ausgedrückt von mir.. Im .lss file sehe ich natürlich was
gemacht wird und was den Speicher belegt, hätte eher sagen sollen was
nützt das? Gibts da gute Erklärungen? Auch zum Programmieren selbst,
habe es noch nicht mal geschafft eine LED zum Blinken zu bringen.. Denke
das liegt an meiner Falschen Clock Einstellung..
Jörg W. schrieb:> Habe jetzt gerade gesehen, für nur wenig mehr Geld bekommt man schon ein> SAME51 Curiosity Nano Board, das ist schon ein ziemlicher Bolide (1 MiB> Flash, 256 KiB RAM).
Das ist jetzt eher weniger das Problem, aktuell reichen mir die 8kb zum
Testen. Hab mir einen Sockel gekauft, mit dem man das ganze schön auf
ein Breadboard bekommt um es dann mit einem Atmel-ICE zu Flashn, dass
funktioniert auch soweit. Sogar das debuggen (hier geht dann die LED
sogar an?).
1
intmain(void)
2
{
3
/* Initialize the SAM system */
4
SystemInit();
5
6
PM->APBBMASK.reg|=PM_APBBMASK_PORT;
7
PORT->Group[0].DIRSET.bit.DIRSET=PORT_PA05;
8
9
while(1)
10
{
11
PORT->Group[0].OUTSET.bit.OUTSET=PORT_PA05;
12
for(uint16_tx=0;x<0xFFFE;x++);
13
PORT->Group[0].OUTCLR.bit.OUTCLR=PORT_PA05;
14
for(uint16_tx=0;x<0xFFFE;x++);
15
}
16
}
Hab mal das .lss file angehängt, falls es jemanden einfach mal
Interessiert.
Ich mag diese Disassemblies nicht so, viel Blahblah, wobei die
eigentlichen Kernaussagen im Wortreichtum untergehen. Häng doch mal
bitte das ELF-File an. Dann kann ich da selbst mit objdump reinschauen.
8 KiB sind für einen ARM allerdings wirklich wenig. In der AVR-Welt wäre
das wohl in etwa, wenn man seine Experimente auf einen ATtiny10
beschränken würde.
Jörg W. schrieb:> 8 KiB sind für einen ARM allerdings wirklich wenig. In der AVR-Welt wäre> das wohl in etwa, wenn man seine Experimente auf einen ATtiny10> beschränken würde.
Das stimmt natürlich, mit Bootloader wird da vermutlich nicht viel ^^
Wie öffnest du .elf files? Atmel Studio bringt einen Fehler und
Notepad++ zeigt keinen Lesbaren Inhalt, habe gesehen man braucht einen
Extra Editor.
Alex Richard Moll schrieb:> Wie öffnest du .elf files?
Man "öffnet" sie nicht, sondern schaut sie sich mit verschiedenen Tools
an.
Korrektur zu obigem Kommando, nicht objdump sondern nm:
1
000001c0 00000010 T SystemInit
2
00000278 00000010 T atexit
3
20000438 00000018 b object.8672
4
00000260 00000018 t register_fini
5
00000288 00000034 T __libc_fini_array
6
00000218 00000048 T __libc_init_array
7
000001d0 00000048 T main
8
00000000 0000008c T exception_table
9
000000f0 000000d0 T Reset_Handler
10
000002c4 000000f4 T __register_exitproc
11
20000008 00000428 d impure_data
'd' (oder 'D') sind initialisierte Daten, belegt daher RAM (für die
Daten selbst) und Flash (für die Initialwerte).
'b' (oder 'B') sind bss-Daten, also solche, die mit 0 vorbelegt werden,
belegt nur RAM.
'T' ist Code ('text'), belegt Flash. Die 'exception_table' dabei enthält
die Interruptvektoren, 140 Bytes. Die größten Funktionen allein
(__register_exitproc und Reset_Handler) machen schon mal 500 Byte aus.
Im Reset_Handler ist dabei auch der Initialisierungscode für die Daten
enthälten (Kopieren aus dem Flash, Ausnullen von bss).
Wofür dieses 'impure_data' da ist, müsste ich auch erst nachschauen –
kannst du ja selbst mal danach gugeln. Das ist ja mit mehr als 1 KiB
schon ein ziemlicher Klopper, sowohl im RAM als auch Flash.
Jörg W. schrieb:> Korrektur zu obigem Kommando, nicht objdump sondern nm:
Dachte schon, objdump zeigt ja den Assembler Code.
Danke dir für die schöne Erklärung, mein Browser ist eh schon voll mit
"ARM" und "SAMD09" Suchbegriffen (:
Alex Richard Moll schrieb:> objdump zeigt ja den Assembler Code
Nicht ganz, es dumpt alle möglichen Inhalte aus dem ELF-File.
Disassembly ist nur eine der Optionen.
Alex Richard Moll schrieb:> Auf der Seite bin ich auch gerade :D>> Gut zu wissen. Wie viel Speicher belegt dann deine Initialisierung?
1
000000a6 0000007a T Reset_Handler
2
00002314 00000044 T __libc_init_array
Also so reichlich 128 Byte.
Keine Ahnung, was in deinem Code dafür verantwortlich sein könnte, dass
impure_data da reinkommt. Vielleicht der SystemInit()-Kram.
128Byte ist im Gegensatz auf jeden Fall nicht viel.
Mit den Optionen -nostartfiles, -nodefaultlibs, -nostdlib und ohne
Programmcode bis auf
1
__attribute__((section(".ctors")))voidboot(void)
2
{}
brauche ich 4 bytes aber trotzdem 1024byte RAM. Bringt mir natürlich so
nichts ohne Interrupt Tabelle usw. aber des Test hat mich einfach
Interessiert. Wenn ich es richtig sehe laut der nm.exe Ausgabe ist das
der Stack der hier berechnet wird obwohl nicht verwendet.
Ja, vermutlich ist das auch in dem anderen ELF-File der Platz, der für
den Stack reserviert ist.
Ich mag diese statisch allozierten Stacks gar nicht. Der Stackpointer
sollte einfach am oberen Ende des RAMs beginnen, der Stack wächst dann
von da nach unten. Damit hat man immer maximal Platz für den Stack –
wenn es nicht reicht, ist es sowieso vorbei, dann würde auch ein zur
Linkzeit vorbelegtes Stacksegment nicht helfen, maximal ändert sich die
Art des Crashs (Hardfault statt zerstörter anderer Daten).
Thread beobachten
Seitenaufteilung abschalten