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
Alex Richard Moll schrieb: > ich möchte wissen warum.
1 | 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).
:
Bearbeitet durch Moderator
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 | int main(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_t x = 0; x < 0xFFFE; x++); |
13 | PORT->Group[0].OUTCLR.bit.OUTCLR = PORT_PA05; |
14 | for(uint16_t x = 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 (:
https://community.platformio.org/t/why-impure-data-appears-on-custom-build-and-eats-1k-memory-need-fix/11353 Hilft jetzt nicht direkt, aber zeigt zumindest Hinweise auf die Linker-Kommandozeile. Keine Ahnung, wie man das in Atmel Studio ändert und/oder warum der Kram da überhaupt rein kommt. In meinen eigenen SAMD-Projekten habe ich sowas nicht, aber ich nehme auch kein Studio, und ich nehme keine newlib_nano.
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.
Auf der Seite bin ich auch gerade :D Gut zu wissen. Wie viel Speicher belegt dann deine Initialisierung?
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"))) void boot(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).
Jörg W. schrieb: > Ja, vermutlich ist das auch in dem anderen ELF-File der Platz, der für > den Stack reserviert ist. Ja:
1 | Sections: |
2 | Idx Name Size VMA LMA File off Algn |
3 | 0 .text 000003e0 00000000 00000000 00010000 2**2 |
4 | CONTENTS, ALLOC, LOAD, READONLY, CODE |
5 | 1 .relocate 00000434 20000000 000003e0 00020000 2**3 |
6 | CONTENTS, ALLOC, LOAD, DATA |
7 | 2 .bss 00000040 20000434 00000814 00020434 2**2 |
8 | ALLOC |
9 | 3 .stack 00000404 20000474 00000854 00020434 2**0 |
10 | ALLOC |
(Warum auch immer es 1028 Bytes sind und nicht 1024.) Die Größe dieses für den Stack reservierten Bereichs wirst du irgendwo auswählen können.
:
Bearbeitet durch Moderator
Alex Richard Moll schrieb: > Gibt es dazu gute Tutorials ohne Atmel Start oder ASF? Sogar ziemlich reichlich unter bare-metal ARM programming ... Hierzu gibt es auch für den SAMD09 Futter zum direkt loslegen. https://github.com/ataradov/mcu-starter-projects
:
Bearbeitet durch User
Alex Taradov, sagt mir noch was. War mal ein (etwas entfernter) Kollege von mir.
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.