STM32 Cube IDE kombiniert -specs=nosys.specs mit syscalls.c

[Sherlock 🕵🏽‍♂️ (Gast)]

Wenn ich ein leeres STM32 Projekt anlege (z.B für STM32F103 ohne HAL), 
dann kombiniert die IDE -specs=nosys.specs mit syscalls.c. Ist das nicht 
doppelt gemoppelt? Beide implementieren leere dummy syscalls.

Kennt jemand den Grund, warum die IDE beides gleichzeitig einsetzt?

[Sherlock 🕵🏽‍♂️ (rubbel-die-katz)]

Vielleicht kennt niemand den Grund. Ist denn meine Annahme richtig, dass 
das doppelt gemoppelt ist?

[Veit D. (devil-elec)]

Hallo,

was passiert wenn man paar Zeilen programmiert und kompiliert? Ist nur 
ein Gedanke. Kenne mich mit STM nicht aus.

[Niklas G. (erlkoenig)]

Sherlock 🕵🏽‍♂️ schrieb:
> Beide implementieren leere dummy syscalls.

Die syscalls.c Funktionen sind doch nicht komplett leer. Man muss nur 
die Ausgabe per UART oder SWO einfügen und dann funktioniert printf()

[Sherlock 🕵🏽‍♂️ (Gast)]

Niklas G. schrieb:
> Die syscalls.c Funktionen sind doch nicht komplett leer.

Stimmt, ganz leer sind sie nicht, aber sie tun alle praktisch "nichts".

Worauf ich hinaus will: Da die IDE diese Datei bereit stellt, ist der 
Parameter -specs=nosys.specs sinnlos, denn die dadurch verwendete 
Bibliothek implementiert ebenfalls minimale Syscalls, die allerdings 
alle durch syscalls.c überschrieben werden.

Man braucht nur eins von beiden.

[M. N. (bmbl2)]

Sherlock 🕵🏽‍♂️ schrieb:
> minimale Syscalls, die allerdings
> alle durch syscalls.c überschrieben werden.
>
> Man braucht nur eins von beiden.

Der eigentliche Trick ist, dass man so nur die implementieren müsste, 
die man auch braucht. Wenn sie in syscalls.c nun mehr machen, als sie 
müssten ist es in der Tat etwas doppelt gemoppelt.

Meistens braucht man nur sagen wie _sbrk für heap management und _write 
für den UART oder so. Den ganzen Rest wie _getpid, _kill, etc. braucht 
auf einem embedded System selten jemand. Dann ist das ein guter Weg sich 
die Implementierung toter Dummies zu sparen.