Locala variable wird weg optimiziert, Coocox + GCC

[Jan H. (jan_h565)]

In folgende Function wird mir "n" beim compilen weg optimiziert :

//--------------------------------------------------------------
// alle LEDs der aktiven WS2812-Kette auf eine Farbe setzen (RGB)
// rgb_col : Farbwert (in RGB)
// refresh : 0=ohne refresh, 1=mit refresh
//--------------------------------------------------------------

void UB_WS2812_All_Led_RGB(WS2812_RGB_t rgb_col, uint8_t refresh)
{
  uint32_t n;

  if(ws2812_channel==0) return;

  for(n=0;n<ws2812_maxanz;n++) {
    ws2812_ptr[n]=rgb_col;
  }
  if(refresh==1) UB_WS2812_Refresh();
}

Es passiert nur bei den STM32 F401RE (nucleo). Beim F407 (discovery) 
functioniert es. Es ist mir unklar warum die sich unterschiedlich 
verhalten. Diese function kommt aus die WS2812 lib von UB. Alles anderes 
functioniert. Ohne optimierung gehts auch.  Selbst wenn ich diese 
variable volatile (local) definiere, wird n noch immer wegoptimiert ?? 
Diese Function wird nur beim "Init" aufgerufen, so jetzt wird die nicht 
verwendet. Wie kann ich das verhinderen ?

[Georg G. (df2au)]

Wenn der Compiler meint, er könne die Variable in seinen Registern 
darstellen, ist es doch in Ordnung. Was stört es dich, wenn die Variable 
den Funktionsaufruf nicht überlebt? Falls du sie in jedem Fall "retten" 
willst, ist das Zauberwort "static".

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Jan H. schrieb:
> In folgende Function wird mir "n" beim compilen weg optimiziert
Und wie wirkt sich das aus? Funktioniert irgendwas nicht mehr?

> Es ist mir unklar warum die sich unterschiedlich verhalten.
Was ist der Unterschied? Was erwartest du und was passiert stattdessen?

[Jan H. (jan_h565)]

Das prgram bleibt hangen an diese Stelle. Beim Debuggen geht es von dort 
kein step mehr weiter. Wenn ich dan die Variable ancklick, sagt der 
debugger mich "weg optimized". Wenn ich dan eine externe volatile 
verwenden, gibt die variabele und geht die auch bis Inhalt 8, aber dan 
stopt er wieder. Ich versuch noch mal bei zuordnung "static".
Danke fur ihre Hinweis.

[Clemens L. (c_l)]

Das sieht eher so aus, als ob "ws2812_maxanz" einen falschen Wert hat.

[Volle (Gast)]

der compiler müsste ja bei dem Code schon einige Warnings ausgegeben 
haben

 und was ist
ws2812_channel
ws2812_ptr
?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Jan H. schrieb:
> Beim Debuggen geht es von dort kein step mehr weiter.
Ich würde sagen: du hast woanders ein Problem mit einem amoklaufenden 
Pointer. Denn die gepostete Funktion ist nicht die Fehlerursache.

[Uli (Gast)]

Wenns nur um die Variable geht ist das Zauberwort hier "volatile" nicht 
"static".
Letzteres hätte nämlich den Effekt, dass momentane Inhalt der Variablen 
das Ende der Funktion "überlebt" bis zum nächsten Aufruf...

Uli

[Jan H. (jan_h565)]

Hier ein bild von debugger. Auf diese Stelle geht er kein Schritt 
weiter. ISR wirden weiter bearbeitet, aber den normale Ablauf nicht.
De genannte Varibalen sind global declariert :

//--------------------------------------------------------------
// Globale interne Variabeln
//--------------------------------------------------------------
uint32_t ws2812_dma_status;
uint16_t WS2812_TIMER_BUF[WS2812_TIMER_BUF_LEN];
uint8_t  ws2812_channel;
WS2812_RGB_t *ws2812_ptr;
uint32_t ws2812_maxanz;

Warnings gibt den compiler nicht :
compile:
    [mkdir] Created dir: C:\Users\Jan\Google 
Drive\Coocox_projecten\NucleoF401-COIDE-GPS\nucleof401-gps\Debug\bin
    [mkdir] Created dir: C:\Users\Jan\Google 
Drive\Coocox_projecten\NucleoF401-COIDE-GPS\nucleof401-gps\Debug\obj
       [cc] 24 total files to be compiled.
       [cc] arm-none-eabi-gcc -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 
-mfloat-abi=hard -mthumb -Wall -ffunction-sections -g -O3 -std=c99 -c -
Program Size:
      text     data      bss      dec      hex  filename
     38520     1356     6196    46072     b3f8  NucleoF401-gps.elf

BUILD SUCCESSFUL
Total time: 6 seconds
MFG, RP6Conrad

[Frank M. (ukw) (Moderator)]

Jan H. schrieb:
> Diese function kommt aus die WS2812 lib von UB.

Ich kenne diese Funktion und auch die LIB von UB. Ich habe UB bereits 
vor über einem Jahr auf den Fehler in seiner WS2812-Lib hingewiesen.

Der Fehler ist nicht direkt in der Funktion UB_WS2812_All_Led_RGB() zu 
finden, sondern dort, wo sie aufgerufen wird.

Die Variable ws2812_dma_status muss volatile definiert werden, denn sie 
wird in einer ISR gesetzt. UB_WS2812_All_Led_RGB() wird aber abhängig 
von ws2812_dma_status aufgerufen. Das geht dann in die Hose.

Solche Fehler hat UB nicht nur dort, sondern auch in vielen anderen 
seiner Libs, nämlich überall, wo eine ISR zum Tragen kommt. Er schreibt 
daher selbst auf seiner Webseite, dass man seine Libs nur ohne 
Compileroptimierungen verwenden soll.

Das ist aber ein Trugschluss. Man muss nur die richtige Einstellungen 
für die Variablen treffen, welche in ISRs verändert werden. Dann klappts 
auch mit der Optimierung.

Schreibe also:

volatile uint32_t ws2812_dma_status;

statt:

uint32_t ws2812_dma_status;

EDIT:

Jan H. schrieb:
> -g -O3

Eben: Optimierten Code debuggen geht (meist) nicht. Deshalb zeigt Dir 
der Debugger auch die falsche Stelle an. Nimmst Du die Optimierung raus, 
wird der Fehler aber nicht mehr auftreten - so wie es UB auf seiner 
Webseite auch beschreibt.

Deshalb: Lass die Optimierung drin, definiere ws2812_dma_status als 
volatile und alles wird laufen.

[Jan H. (jan_h565)]

Das war die Lösung ! Fielen Dank für die Hilfe, das hatte ich selbst nie 
herausgefunden.
MFG, RP6corad.