Finde Ursache für STM32 Linker Wanung nicht!

Dirk schrieb:
> Ich finde nur nirgends wchar_t.  Wo ist das?

Ist für dein Problem eigentlich egal

Dirk schrieb:
> warum

https://stackoverflow.com/questions/19489354/how-to-set-2-byte-wchar-t-output/23896853

Frag den, der die lib gebaut hat.

Oliver

Dirk schrieb:
> Ich finde nur nirgends wchar_t.  Wo ist das?

Kommt auf die Sprache an. In C ist das in stddef.h definiert, in C++ ist 
es im Sprachkern eingebaut.

> Und wieso ist das mal als 2 und mal als 4 Byte angegeben, wie kommt man
> drauf das auf 2 zu ändern?
> Oder warum ist das bei mir auf 4?

Wie groß wchar_t ist, ist compilerspezifisch.

Ich glaube, bei FreeRTOS muß bei einer echten FPU bei einem Taskwechsel 
mehr auf dem Stack gerettet werden (eben die ganzen FPU-Register).

Deshalb wirst du (wenn du eh keine FPU nutzt) besser mit Soft-FPU 
fahren.

Bin aber ehrlich gesagt nicht sicher, ob es wirklich einen Unterschied 
macht.

Vergiß meinen Text wieder.
Wenn die Lib intern die FPU nutzt, kann sie darin ja unterbrochen 
werden, es muß also ohnehin das volle Sortiment bei einem Kontextwechsel 
gerettet werden.
Daß nur die eine Task die FPU nutzt, kannst du meines Wissens nirgends 
sagen - es wird trotzdem so ablaufen, als ob jede Task es könnte.

softfp heißt ja, daß erstens die FPU genutzt werden kann, und zweitens 
aber Funktionsaufrufe nicht über FPU-Register gehen, sondern wie ohne 
FPU.

Wenn du deinen Code kompilierst mit softfpu, kann es trotzdem passieren, 
daß FPU-Code generiert wird (z.B. um Register zu nutzen und die 
nicht-FPU-Register zu sparen).
Falls du das vermeiden möchtest (wozu ich keinen Grund sehe), könntest 
du auch mit -mfloat-abi=soft kompilieren. Das sollte zu der Lib passen.
Ohne RTOS wäre vermutlich softfp schneller als soft, zumindest nicht 
langsamer.
Mit RTOS mag es anders sein. Müsste man testen.

Wie im Prinzip schon gesagt wurde möchte der Linker dir sagen das du 
bitte für die Library und deine Applikation die gleiche Calling 
Convention benutzen sollst.
Es funktioniert halt nicht wenn z.B. deine Applikation meint ein wchar_t 
wäre 4 Bytes groß und ruft eine Library Funktion auf, die aber einen 2 
Byte wchar_t Parameter erwartet.

Beim GCC gibt es für die FPU folgende Settings:
https://wiki.segger.com/GCC_floating-point_options

Auch da müssen Library und Applikation die gleichen Settings benutzen 
damit z.B. Parameter über die richtigen Register übergeben werden (FPU 
Register bei hard und CPU Register bei soft und softfp). soft und softfp 
können gemixt werden.

Dirk schrieb:
> Beim Task Wechsel sollte schon drin sein das die FPU gesichert wird,
> wenn nicht sollte das kein Problem sein das einzuschalten.
> Ich denke da wird es Beispiele geben, wenn es noch nicht im code drin
> ist.
Die meisten RTOS sollten heutzutage das Arm Cortex-M4F Lazy Stacking 
Feature benutzen (embOS macht das so und FreeRTOS wahrscheinlich auch). 
Damit werden FPU Register beim Context Switch automatisch 
gesichert/restauriert und als Anwender brauche ich mir keine Gedanken 
darum machen. Evtl. muss man bei FreeRTOS ein Define setzen, um das 
einzuschalten. Sag Bescheid, falls du da Hilfe brauchst.

Dirk schrieb:
> Vielleicht kannt ja jemand für den Liker noch so einen Trick damit die
> GCC LIBs mit 2 Byte arbeiten und ich die Warnungen los werde.

Steht doch alles im o.a. stackoverflow-Beitrag. Von Warnung einfach 
unterdrücken bis gcc-toolchain neu bauen. Was du davon brauchst, musst 
du selber wissen.

Eine zusätzliche Möglichkeit wäre, die fragwürdige lib nach /dev/null zu 
schieben, und einfach eine selber zu programmieren, bzw. eine andere zu 
suchen.

Oliver