STM32F4 mit gcc-arm-none-eabi

Man findet passende Files auch in der CubeFW:
z.B.:
STM32Cube_FW_F4_V1.9.0\Drivers\CMSIS\Device\ST\STM32F4xx\Source\Template 
s

Schau Dir mal das Projekt mcHF vom Sulinger Amateurfunk Club an:

https://github.com/df8oe/mchf-github/tree/master/mchf-eclipse

Details sind auch in folgenden Thred zu finden.

Beitrag "mcHF-SDR Selbstbau-Projekt"

Das Projekt im Github läuft auf einem 405/407 und dort sind die
Makefiles und Linkerfiles zum abkupfern vorhanden.

Vielleicht hilft Dir das.

Markus
DL8MBY

Hallo Zusammen,

besten Dank für die Antworten. Ich kann jetzt erfolgreicht compilieren, 
und Debuggen!
Das der Cortex M4F kein keine NEON SIMD Engine hat, ist absolut richtig. 
Diese ist nur in den Cortex A Typen vorhanden. Das hätte ich dann 
spätestens beim Debuggen der ersten NEON instruction am SIGILL gemerkt. 
Dann wäre der AHA Effekt sicher noch größer gewesen.

Folgendes hat zum Erfolg geführt:
Ich habe in CubeMx in den "Project Settings" unter Toolchain / IDE auf 
"SW4STM32" gestellt. Ich vermute, es geht auch mit anderen 
Einstellungen.
Das daraus entstehende Linkerscript "STM32F407ZGTx_FLASH.ld" im 
Rootverzeichnis der von CubeMx erstellten Verzeichnisstruktur passt 
offensichtlich zum "startup_stm32f407xx.s" welches sich ebenfalls in 
dieser Struktur unter 
/Drivers/CMSIS/Device/ST/STM32F4xx/Source/Templates/gcc/ befindet (Danke 
an Steffen Rose).
Die CFLAGS habe ich aus dem Artikel ARM GCC hier im Forum 
(https://www.mikrocontroller.net/articles/ARM_GCC) aus dem Kapitel 
Compiler & Linker Flags --> "Ohne Optimierungen, mit 
Debug-Informationen:" Zeile "C-Compiler (gcc) " Spalte Cortex-M4F 
entnommen:
-mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mfloat-abi=hard -mthumb 
-ffunction-sections -fdata-sections -g
(Danke an Dr. Sommer)
Ich habe allerdings noch ergänzt: --specs=nosys.specs
Ohne das erhalte ich folgende Fehlermeldung:
/opt/gcc-arm-none-eabi-4_9-2015q4/bin/../lib/gcc/arm-none-eabi/4.9.3/../ 
../../../arm-none-eabi/lib/armv7e-m/fpu/libc.a(lib_a-exit.o):  In 
function `exit':
exit.c:(.text.exit+0x16): undefined reference to `_exit'
/opt/gcc-arm-none-eabi-4_9-2015q4/bin/../lib/gcc/arm-none-eabi/4.9.3/../ 
../../../arm-none-eabi/lib/armv7e-m/fpu/libc.a(lib_a-sbrkr.o):  In 
function `_sbrk_r':
sbrkr.c:(.text._sbrk_r+0xc): undefined reference to `_sbrk'
collect2: error: ld returned 1 exit status
Was bewirkt diese Option, und die auch häufig angegebene 
--specs=nano.specs?

So, der Anfang wäre also gemacht. :-) Besten Dank an alle, die 
geantwortet haben. Aus jedem der Beiträge habe ich etwas entnommen, was 
mich weiter gebracht hat. Kann jemand etwas dazu sagen, was im 
startup-file und im Linkerscript geschieht?

Viele Grüße
Kruwakre

B. S. schrieb:
> Ich habe allerdings noch ergänzt: --specs=nosys.specs
> Was bewirkt diese Option, und die auch häufig angegebene
> --specs=nano.specs?

Die Option --specs=nosys.specs liefert wohl Definitionen für die 
Funktionen wie _exit und _sbrk. Das kann man aber auch selbst machen. 
_exit wird einfach eine Endlosschleife. _sbrk ist etwas schwieriger, da 
dies die Funkion ist wo malloc seinen Speicher her kriegt. Je nach 
Wunsch kann man hier Speicher vom internen RAM oder eventuell 
vorhandenem externen RAM liefern.

Die Option --specs=nano.specs wählt eine größenoptimierte Version der 
Standardlibrary aus. Dort fehlt dann z.B. Unterstützung für einige 
printf Formate, speziell für floating Point Werte.