GCC für STM32F10x

Ja, im STM32 ist ein ARM core. Du suchst wahrscheinlich nach 
arm-none-eabi-gcc.

HTH
Torsten

Programmierer schrieb:
> der GCC nicht für alle die entsprechenden Libraries, Startup-Codes &
> Linker-Scripte enthalten kann

Macht er beim AVR auch nicht, dafür gibt es die avr-libc (die aber
in enger Kooperation mit dem AVR-GCC lebt, bspw. bezüglich -mmcu).

Leider gibt es nichts Vergleichbares für ARM, obwohl es technisch
durchaus möglich wäre.  Da hätte sich wohl ARM den Hut aufsetzen
müssen dafür, so wird es jedem Hersteller überlassen, und jeder
kocht da sein eigenes Süppchen.  Da sich dann jeder nur noch auf seine
eigene IDE als Rundum-Sorglos-Lösung kümmert, werden Linkerscripte,
Startup-Code etc. entsprechend in diese reingepackt.  Jeder, der die
Tools „zu Fuß“ benutzen will (oder, gott bewahre, von der gepriesenen
Artenvielfalt profitieren möchte und gar ein herstellerübergreifendes
Projekt aufsetzen), muss entsprechend den gleichen Zirkus mit
Startup-Code und Linkerscripten dann manuell nachvollziehen.

Ist ein bisschen schade.  Wie gesagt, technisch machbar wäre es
durchaus auch bei ARM so, wie es bei AVR gemacht worden ist.

Jörg W. schrieb:
>
> Leider gibt es nichts Vergleichbares für ARM, obwohl es technisch
> durchaus möglich wäre.

es gibt CMSIS. Hersteller, die das unterstützen liefern in der Regel 
damit auch die für GCC nötigen startup files und linker Skripte.

> Ist ein bisschen schade.  Wie gesagt, technisch machbar wäre es
> durchaus auch bei ARM so, wie es bei AVR gemacht worden ist.

Ja CMSIS ist eine gute Idee, aber irgend wie nur halbherzig umgesetzt.

>so wird es jedem Hersteller überlassen

Etwas zu einfach dargestellt ist das bei AVR ja auch so. Nur gibt es da 
eben nur einen Hersteller.

schönes Wochenende
Hauspapa

Torsten R. schrieb:
> es gibt CMSIS. Hersteller, die das unterstützen liefern in der Regel
> damit auch die für GCC nötigen startup files und linker Skripte.

Es bleibt trotzdem Gebastel.  Bei einem AVR kannst du ein hello.c
schreiben und mit

1

avr-gcc -mmcu=atmega16 -Os -o hello.elf hello.c

zum finalen ELF-File compilieren.  Compiler und Library sind so
aufeinander abgestimmt, dass der Compiler einen passenden Startup-Code
und Linkerscript findet.

Bei den ARMs geht das nicht, da popelt sich das jeder selbst zurecht
(und jeder irgendwie anders, bis hin zu verbuggten Linkerscripts, die
durchs Netz tingeln und es vermasseln, .data mit Daten zu füllen –
alles schon gesehen).

S. K. schrieb:
>> so wird es jedem Hersteller überlassen
>
> Etwas zu einfach dargestellt ist das bei AVR ja auch so.

Atmel hat sich lange Zeit da gar nicht drum gekümmert.  Die
Infrastruktur in Compiler und Bibliothek ist da völlig ohne deren
Zutun entstanden.

Mittlerweile sind sie da tatsächlich involviert, hat aber recht lange
gedauert.

ARM ist auch erstmal nur ein Hersteller, sie hätten die
Infrastruktur dafür genauso aufbauen können, sodass die Hersteller
dann nur noch das IO-Headerfile für ihren Chip liefern müssen.  Ich
bin mir sicher, dass sich kein Hersteller geweigert hätte, ein solches
System zu benutzen und es dann in seine IDE zu integrieren … aber da
die Infrastuktur nicht da war, und ARM selbst es jedem einzelnen
Hersteller überlassen hat, sich da zu kümmern, hat sich von denen
natürlich nur jeder um sich selbst gekümmert (was man ihnen nicht
verdenken kann).  ARM selbst wären die Einzigen gewesen, die ein
hinreichendes Interesse an einer gemeinsam Lösung gehabt haben
könnten (weil sich damit dann alle ARMs besser vermarkten lassen).
Haben sie ja an anderen Stellen auch getan, indem sie beispielsweise
die GCC-Entwicklung für ARM vorangetrieben haben.

Programmierer schrieb:

> Ja, bloß wie gigantisch wäre dann der GCC/Library Download wenn er alle
> Header+Source Files aller Libraries enthalten würde?

Peanuts im Vergleich zu den Kolossen, die dir die Hersteller als
IDE aufdrängeln.

> Ja, nur für tausende Controller die zusammenzustellen hat halt keiner
> Lust...

ARM hätte sich nur um die Infrastruktur kümmern müssen: eine
passende Verzeichnishierarchie, und eine Option ähnlich -mmcu, die
dann Startup-Code und Linkerscript passend aus dieser Hierarchie
sucht, sowie eine Systembibliothek (die gar nicht so viel mehr
sein müsste also CMSIS, von mir aus mit optionaler Newlib-Integration),
die diese Scripte enthält.

Die konkreten Headerdateien hätten dann die Hersteller liefern
können.  Müssen sie ja so ohnehin schon tun.

> Aber bei den Peripherie-Treibern
> wirds hässlich...

Peripherie-Treiber hat eine avr-libc auch nicht.  Wenn dann Atmel
sowas als ASF und jemand anders das in anderer Weise ihren Kunden
in die Hand drücken will, können sie das davon unabhängig tun.

Es ging mir wirklich nur darum, dass man einen simplen LED-Blinker
compilieren kann mit

1

arm-none-eabi-gcc -mmcu=stm32f104 -Os -o hello.elf hello.c

Programmierer schrieb:
> Außerdem ist bei einigen von ST (bis heute in den Beispielprojekten
> enthalten) der Stack-Anfang falsch, sodass bestimmte Stack-Zugriffe, die
> alignment erfordern (zB. 64bit, wie bei double-Parametern)
> schiefgehen...

Au ja, auch das durfte ich schon mal debuggen.

Und das nur, weil irgendein übereifriger Heini der CPU-Beschreibung
offenbar nicht glauben will, dass man den Stack direkt hinter den
RAM setzen kann (wo er ordentlich 8-byte-aligned wäre), denn er wird
vor der Benutzung dekrementiert.  Also wurde er vier Bytes vor das
Ende gesetzt. :-(