ARM Einstieg - Fragethread

[F. (Gast)]

Ich bin gerade dabei in die ARM einzusteigen, genauer gesagt 
ATSAMD20E14,  und würde in dem Thread hier gerne die eine oder andere 
anfallende Frage stellen.

Und zwar:
Beim Kompilieren eines leeren Projektes in ATMEL Studio bekomme ich 
folgendes:

Program Memory Usage   :  1984 bytes   12,1 % Full
Data Memory Usage     :  1624 bytes   79,3 % Full

Etwas deprimierend wenn der Speicher gleich zu Beginn schon voll ist :). 
Was füllt den da außer dem Startup Code den Speicher?

F.

[(prx) A. K. (prx)]

Das Mapfile könnte weiterhelfen. Vielleicht wird der Stack fest 
alloziert.

[Lothar (Gast)]

F. schrieb:
> Was füllt den da außer dem Startup Code den Speicher?

Das ASF mit den ursprünglich mal für größere ARM (SAM4) gedachten 
structs. Atmel hält es scheinbar nicht für nötig für die M0 ein ASF lite 
bereitzustellen. Oder man will die AVR vorher noch abverkaufen :-)

Also SAMD20 entweder direkt mit Registerzugriff programmieren ohne ASF.

Oder z.B. zu NXP wechseln, hier gibt es eine Standard-CMSIS für M3, M4 
und für M0 eine Version die sogar mit 1k RAM läuft.

[F. (Gast)]

Lothar schrieb:
> Das ASF mit den ursprünglich mal für größere ARM (SAM4) gedachten
> structs.

 /* -------- TC_CTRLA : (TC Offset: 0x00) (R/W 16) Control A -------- */
#if !(defined(__ASSEMBLY__) || defined(__IAR_SYSTEMS_ASM__))
typedef union {
  struct {
    uint16_t SWRST:1;          /*!< bit:      0  Software Reset                     */
    uint16_t ENABLE:1;         /*!< bit:      1  Enable                             */
    uint16_t MODE:2;           /*!< bit:  2.. 3  TC Mode                            */
    uint16_t :1;               /*!< bit:      4  Reserved                           */
    uint16_t WAVEGEN:2;        /*!< bit:  5.. 6  Waveform Generation Operation      */
    uint16_t :1;               /*!< bit:      7  Reserved                           */
    uint16_t PRESCALER:3;      /*!< bit:  8..10  Prescaler                          */
    uint16_t RUNSTDBY:1;       /*!< bit:     11  Run in Standby                     */
    uint16_t PRESCSYNC:2;      /*!< bit: 12..13  Prescaler and Counter Synchronization */
    uint16_t :2;               /*!< bit: 14..15  Reserved                           */
  } bit;                       /*!< Structure used for bit  access                  */
  uint16_t reg;                /*!< Type      used for register access              */
} TC_CTRLA_Type;
#endif /* !(defined(__ASSEMBLY__) || defined(__IAR_SYSTEMS_ASM__)) */

Meinst du die in den header-files(hier mal vom Timer)? Solange ich 
nichts z.B. vom Typ TC_CTRLA_Type anlege sollten die ja nichts belegen 
und wenn ich z.B. "__ASSEMBLY__" definiere ändert sich auch nichts
F.

[Lothar (Gast)]

F. schrieb:
> Solange ich nichts ... anlege sollten die ja nichts belegen

system_init() legt aber schon reichlich an:

Beitrag "Erste Schritte mit ARM SAMD20"

Moby schrieb im Beitrag #3847549:
> Ach diese Träumereien immer.

Das war ein Scherz! Trotzdem kann man sich fragen, warum Atmel überhaupt 
kleine ARM rausbringt, wenn die SW-Unterstützung so aussieht, und 
Beispiele zur direkten Programmierung gibt es ja auch nicht, kann man 
sich selber im Manual zusammen suchen.

[Stefan (Gast)]

Zeig doch einfach das Mapfile wenn du es selbst schon nicht lesen magst. 
Alles andere ist doch nur wildes raten.

Die Ursache für den hohen RAM Bedarf kann der Stack sein (erste 
Antwort), die libc einer älteren Toolchain oder ein Heap für malloc() 
und Co.

Fast 2kB für Startup klingt eher nach abgeschalteter Optimierung. So 
viel Speicher ist selbst für die ST Lib ungewöhnlich. Bei einem "leeren" 
Projekt versteht sich. Ansonsten schlägt die schon ordentlich zu.

[F. (Gast)]

Ok im Anhang die Mapfile

[Dennis S. (eltio)]

F. schrieb:
> Ok im Anhang die Mapfile

Ich mag mich irren aber: *MAP*file != *MAKE*file.

[F. (Gast)]

oops, das muss natürlich Makefile heißen ;)

[F. (Gast)]

aiaiai wohl noch etwas früh...

[Dennis S. (eltio)]

Ich gehe aber davon aus, dass die Vorredner wirklich das MAPfile haben 
wollten.

Edit: Zeitüberschneidung... ;-)

[F. (Gast)]

Ich habe jetzt die Compiler/Linker Flags gemäß dieses Artikels 
http://www.mikrocontroller.net/articles/ARM_GCC#Code-Gr.C3.B6.C3.9Fe_optimieren 
hier gesetzt, was jedoch kaum Änderung bringt.

Wenn ich im Linker Menü die newlib-nano wähle, sinkt der Speicherbedarf 
auf

Program Memory Usage   :  600 bytes   3,7 % Full
Data Memory Usage     :  544 bytes   26,6 % Full

 was schon mal nicht schlecht ist. Ohne den Startup Code brauchen .bss 
und .text Segment jedoch immer noch je ca.500byte. Außerdem soll die 
newlib-nano angeblich noch zu buggy sein.

[Random .. (thorstendb)]

Wie wärs, wenn du den ganzen Lib Kram weglässt, und nur startup uns 
system hernimmst, in einem neuen, frischen Projekt?
Ohne die DriverLibs sollte im Chip dann noch Platz für dein Programm 
sein :-)

[Random .. (thorstendb)]

F. schrieb:
> Wenn ich im Linker Menü die newlib-nano wähle, sinkt der Speicherbedarf
> auf

Program Memory Usage   :  600 bytes   3,7 % Full
> Data Memory Usage     :  544 bytes   26,6 % Full

ATSAMD20E14: 16k Flash, 2k RAM

gerad mal schnell getestet:
- armcc Lib, 0x100 Bytes Stack:
  Program Size: Code=348 RO-data=192 RW-data=4 ZI-data=356

- armcc MicroLib, 0x100 Bytes Stack:
  Program Size: Code=144 RO-data=192 RW-data=4 ZI-data=260

[(prx) A. K. (prx)]

F. schrieb:
> Wenn ich im Linker Menü die newlib-nano wähle,

... vergesse ich schon wieder das Mapfile. ;-)

[F. (Gast)]

A. K. schrieb:
> Vielleicht wird der Stack fest
> alloziert.

Hmmm. Also mit -nodefaultlibs -nostdlib bleiben 516byte im bss was genau 
der größe des Stacks entspricht - also wird der Stack in der Tat fest 
alloziert?

F.

[F. (Gast)]

Anscheinend löst das Linkerflag

–nostartfiles
(Do not use the standard system startup files when linking. The standard 
system libraries are used normally, unless -nostdlib or -nodefaultlibs 
is used.)

alle Probleme. Diese "standard system startup files" nutzen laut mapfile 
die libc was zu hohem Speicherbedarf führt. Allerdings funktioniert die

 __libc_init_array();

in der startup_samd20.c damit auch nicht mehr.

Anhang:
1. Mapfile: ohne flag -> Speicherbedarf hoch
2. Mapfile: -nostartfiles -> Speicherbedarf wie er sein soll :)

Nun die Frage ob diese standard system startup files bzw. die 
__libc_init_array(); relevant sind?

F.

[Stefan (Gast)]

Das wird für C++ gebraucht damit die Konstruktoren korrekt funktionieren 
bzw. überhaupt erst aufgerufen werden.
D.h. je nachdem wie das bei der Toolchain implementiert ist, werden 
Konstruktoren gar nicht aufgerufen oder evtl. vorhandene 
Initialisierungslisten werden ignoriert. Sofern sich das Programm 
überhaupt linken läßt.