Gibt es für die STM32F10x-Familie eine GCC-Toolchain ähnlich einfach wie WinAVR?
ARM GCC STM32: Programmierung Ist nicht ganz so einfach wie AVR GCC zu bedienen, da angesichts der riesigen Anzahl an ARM Cortex Prozessoren der GCC nicht für alle die entsprechenden Libraries, Startup-Codes & Linker-Scripte enthalten kann; somit muss man diese manuell einbinden.
Danke für eure Antworten. Werde erst einmal hier ein wenig stöbern: https://launchpad.net/gcc-arm-embedded
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
Jörg W. schrieb: > Ist ein bisschen schade. Wie gesagt, technisch machbar wäre es > durchaus auch bei ARM so, wie es bei AVR gemacht worden ist. Ja, bloß wie gigantisch wäre dann der GCC/Library Download wenn er alle Header+Source Files aller Libraries enthalten würde? Wäre schon etwas unpraktisch. 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. Ja, nur für tausende Controller die zusammenzustellen hat halt keiner Lust... Gäbe es maschinenlesbare Tabellen mit Flash/Ram Größen und Interrupts für alle Cortex-M, könnte man Startupcode+Linkerscript weitgehend automatisch generieren. Aber bei den Peripherie-Treibern wirds hässlich...
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 |
Jörg W. schrieb: > (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). Gibt noch bessere: Die Linkerscripte von ST setzen teilweise ein Symbol falsch, sodass .data mit falschen Daten initialisiert wird. 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... Jörg W. schrieb: > aber da > die Infrastuktur nicht da war, ARM hat ja sogar das CMSIS-Zeug erfunden, aber dann haben sie es verpasst ein zentrales "sortiertes" Repository mit den CMSIS-Sourcecodes/Headern + Linkerscripte/Startupcodes aufzubauen mit dem man den GCC ähnlich komfortabel hätte machen können.
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. :-(
Jörg W. schrieb: > 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. :-( Oh, das ist ja noch eine Variante. Ich bin auf
1 | _estack = 0x2001FFFF; /* end of RAM */ |
gestoßen, d.h. der Stack ist nichtmal mehr 4byte aligned. Richtig wäre natürlich 0x20020000 gewesen. Traurig wenn man nicht weiß wie sein eigenes Produkt funktioniert. 2/4 Byte Zugriffe auf den Stack funktionieren mit so einem Linkerscript nur, weil der Prozessor (wenn nicht explizit abgeschaltet) die unaligned kann (aber langsam).
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.