STM32f4 osThread Fließkommazahlen verwenden

[Rene W. (renesche)]

Hallo liebe Forummitglieder,
ich verwende aktuell ein STM32f407 und spiele mit Threads rum.

In meiner Threadroutine führe ich eine Funktion aus, in der wiederum 
eine Variable des Typs double initialisiert wird.

Nur bleibt der Thread in diesem Fall einfach stehen oder so.
Sobald die Variable ein Integer ist, geht das.

/*Beispiel:*/

osThreadId t1;
void unterfunktion(){
  double i = 9.0;
}

void threadroutine(void const *argument){
   while(1){
      unterfunktion();
      toggle_led();
   }
}
osThreadDef(threadroutine,osPriorityNormal,1,0);
int main(void){
  t1 = osThreadCreate(osThread(threadroutine),NULL);
  osDelay(osWaitForever);
}

Ich dachte es hat vielleicht mit der Stacksize zu tun, aber ich kann bei 
dem Threaddef nur bis 2 Byte angeben, sonst wird der Thread nicht mal 
erzeugt.

Direkt in der Threadroutine einen double erzeugen geht hingegen.

Hat jemand eine Idee was da los ist?

Wenn alle Stricke reisen lege ich die Variable direkt in der 
Threadroutine an und übergebe an die Funktion nen Pointer.

Lg

EDIT: mit nen Pointer gehts auch nicht!

[m.n. (Gast)]

Rene W. schrieb:
> Nur bleibt der Thread in diesem Fall einfach stehen oder so.

Einfach auf Stopp drücken und nachsehen, ob er stehen oder liegen 
bleibt.

[Rene W. (renesche)]

Ok, ich habe den Debugmodus mal gestartet.
(Bitte nicht lachen, aber das habe ich jetzt zum ersten mal gemacht) und 
er bleibt in der os_error(errorcode) drin stehen.
Da gibts Stackoverflow, fifooverflow und Mailbox_overflow.
Also wird dann wohl ein Stackoverflow schuld sein.

Aber wieso? Selbst wenn ich nen int64_t anlege passiert das nicht.
Stack vergrößern?

Wenn ja wie, weil beim ThreadDef kann ich nicht mehr wie 2Byte angeben, 
oder eben 0 für Default.

Oder könnte das mit der Keil-Studentenversion zusammenhängen?

Lg

[Rene W. (renesche)]

Also ich habe in der sartup_stm32f40_41xxx.s den Stack und Heap jeweils 
verdoppelt, und dennoch bekomme ich den Stackoverflow.

[Mehmet K. (mkmk)]

Also ich persönlich haette zuerst einmal damit angefangen, das 
verwendete RTOS beim Namen zu nennen und erst dann haette ich mein 
Problem angesprochen.

[Stefan K. (stefan64)]

Welcher Compiler?
bei gcc: ist floating-point im gcc eingeschaltet?

Gruß, Stefan

[W.S. (Gast)]

Stefan K. schrieb:
> Welcher Compiler?
> bei gcc: ist floating-point im gcc eingeschaltet?

Das ist nur die halbe Weisheit. Normalerweise muß man die FP-Einheit 
auch im µC dediziert einschalten. Etwa sowas:
  // und jetzt auch den Gleitkomma-Coprozessor freigeben
  SCB_CPACR = 3<<20;

Abgesehen davon sollte man sich auch noch darum kümmern, ob das 
betreffende RTOS einen M4F überhaupt unterstützt. Beim Taskwechsel 
müssen nämlich auch die verwendeten FP-Register berücksichtigt werden. 
Und bei Interupts wird die Sache noch ein Stückchen spannender, je 
nachdem, ob FP im Grundprogramm oder in der ISR oder in beiden verwendet 
wird und welche Register der FP-Einheit für wen reserviert sind und so 
weiter. Man lese dazu mal die betr. Notes von Arm.

W.S.

[Nop (Gast)]

W.S. schrieb:
> Das ist nur die halbe Weisheit. Normalerweise muß man die FP-Einheit
> auch im µC dediziert einschalten.

Und die dritte Hälfte der Wahrheit ist, daß das alles nur für float, 
nicht für double funktioniert.

> Und bei Interupts wird die Sache noch ein Stückchen spannender, je
> nachdem, ob FP im Grundprogramm oder in der ISR oder in beiden verwendet
> wird

FP in Interrupts.. brrrr. Dann doch lieber in der ISR ein RTOS-Semaphore 
oder sowas setzen, woraufhin das RTOS dann den Worker-Thread loslaufen 
lassen kann.

[W.S. (Gast)]

Nop schrieb:
> FP in Interrupts.. brrrr. Dann doch lieber in...

Du bist ein ziemlicher Witzbold. Was meinst du, wie bei preemptivem 
Taskverwalten der Scheduler erreicht wird? Per Interrupt natürlich, also 
per Hardware raus aus Usermode, rein in Supervisormode und ggf. dann 
wieder rein in Usermode, diesmal aber per Software. Und da ist die 
eventuelle FP Verwendung im nächsten Task erstmal garnicht ersichtlich - 
jedenfalls nicht aus Sicht des RTOS. Deswegen muß ein RTOS eben drauf 
ausgelegt sein, den M4F auch tatsächlich zu bedienen.

Es ist eben heikel - und ich frag mich, ob für eine µC-Verwendung in dem 
hier besprochenen Rahmen ein RTOS überhaupt sinnvoll ist. Der TO scheint 
damit jedenfalls seine Probleme, aber keine Erklärung und schon garnicht 
eine Lösung zu haben.

W.S.

[Nop (Gast)]

W.S. schrieb:
> Und da ist die
> eventuelle FP Verwendung im nächsten Task erstmal garnicht ersichtlich

Du hast natürlich Recht, was das Retten der Register betrifft, aber 
unter "verwendet" hatte ich "FließkommaBERECHNUNGEN mitten in der ISR" 
verstanden.

Wobei das natürlich nur dann ein Problem ist, wenn mehr als ein Task 
überhaupt was mit Fließkomma tut. Je nach Anwendung kann man das auch 
vermeiden.