mikrocontroller.net

Forum: Compiler & IDEs STM32 - keine ISR, wegoptimierte Variable


Autor: Reginald Leonczuk (Firma: HS Ulm) (reggie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Huhu!

Folgender Code, keinerlei ISR:
uint16_t SPI_I2S_ReceiveData(SPI_TypeDef* SPIx)
{
  /* Check the parameters */
  assert_param(IS_SPI_ALL_PERIPH_EXT(SPIx));
  
  /* Return the data in the DR register */
  return SPIx->DR;    // SPIx->DR ist ein Pointer auf ein Register, in der mein neuer Wert für jdid drinsteht.
}

void ExternFlash::ReadBytes(uint8_t * byte_arr, uint32_t amount)
{
  for (int i = 0; i < amount; i++)
  {
    while (SPI_I2S_GetFlagStatus(SPI2, SPI_I2S_FLAG_TXE) == RESET);
    SPI_I2S_SendData(SPI2, 0x00);
    while (SPI_I2S_GetFlagStatus(SPI2, SPI_I2S_FLAG_RXNE) == RESET);
    byte_arr[i] = SPI_I2S_ReceiveData(SPI2);
  }
}

bool ExternFlash::CheckID(uint8_t jedecid, uint32_t uniqueid)
{
  uint8_t jdid;
  uint32_t uid;

  // Check JEDEC ID
  SetCSLow();
  SendCommand(JEDECID);
  ReadBytes((uint8_t*)&jdid, 1);
  SetCSHigh();
  if (jdid != jedecid)
    return false;

  System::DELAY delay(1);

  // Check Unique ID
  SetCSLow();
  SendCommand(UNIQUEID);
  WaitForBytes(4);
  ReadBytes((uint8_t*)&uid, 4);
  SetCSHigh();

  if (uid != uniqueid)
    return false;

  return true;
}

jdid wird mit -o3 wegoptimiert, muss ich das wirklich auf volatile 
setzen?
uid wird komischerweise nicht wegoptimiert.

Danke und viele Grüße aus Ulm!
Reggie

: Bearbeitet durch User
Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Reginald L. schrieb:
> jdid wird mit -o3 wegoptimiert

Wird die damit verbundene Funktionalität entfernt? Oder wird bloss das 
Byte im Speicher wegoptimiert, aber das Programm tut was es soll?

Du hast Anspruch darauf, dass ein Programm sich wie beschrieben verhält. 
Nicht aber, dass ein auf aggressiv eingestellter Optimizer den Code 
Zeile für Zeile und Byte für Byte genau so umsetzt, wie der Quellcode 
suggeriert.

Erklärung: Da der Compiler bei
  ReadBytes((uint8_t*)&jdid, 1);
den Quellcode kennt und wohl inlined, merkt er in der Umsetzung des 
Codes der Funktion, dass es um genau 1 Byte geht und wird dieses Byte 
ohne Umweg über Speicher direkt im Register belassen.

Bei uid ist das jedoch nicht so einfach, weil 4 Bytes.

: Bearbeitet durch User
Autor: Reginald Leonczuk (Firma: HS Ulm) (reggie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Wird die damit verbundene Funktionalität entfernt? Oder wird bloss das
> Byte im Speicher wegoptimiert, aber das Programm tut was es soll?
Puh, schwer zu sagen, ich schaffe erst seit ein paar Tagen mit 
Compiler-Optimierungen. Breakpoints kann ich bspws. nur auf dem ersten 
und letzten return setzen. Der Breakpoint am return der uid wird 
automatisch gelöscht.

A. K. schrieb:
> Nicht aber, dass ein auf aggressiv eingestellter Optimizer den Code
> Zeile für Zeile und Byte für Byte genau so umsetzt, wie der Quellcode
> suggeriert.
Achso OK, ich verstehe. Also kann man debuggen eigentlich vergessen. 
Kann man dann überhaupt 100%-ig sicher sein, dass ein größeres Programm 
genau das tut, was man von ihm verlangt?

Autor: A. K. (prx)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Reginald L. schrieb:
> Achso OK, ich verstehe. Also kann man debuggen eigentlich vergessen.

Bei -O3 kann man im Debugger recht seltsame Erlebnisse haben, ja. Am 
besten funktioniert ein Debugger ohne Optimierung.

> Kann man dann überhaupt 100%-ig sicher sein, dass ein größeres Programm
> genau das tut, was man von ihm verlangt?

Nur wenn man es gemäss dem C Standard 100%-ig richtig formuliert hat.

Autor: Reginald Leonczuk (Firma: HS Ulm) (reggie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Aber ich glaube du hast schon recht gehabt, dass die Funktionalität des 
Programms gegeben ist. Es verhält sich genau so, wie vorher, nur dass 
Debuggen nicht mehr wirklich funktioniert.

A. K. schrieb:
> Nur wenn man es gemäss dem C Standard 100%-ig richtig formuliert hat.
Wer kann sowas bei größeren Programmen, Gott? :)

Vielen Dank für die Hilfestellung, ich weiß jetzt bescheid.

Autor: Hanswurst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Reginald L. schrieb:
> A. K. schrieb:
>> Wird die damit verbundene Funktionalität entfernt? Oder wird bloss das
>> Byte im Speicher wegoptimiert, aber das Programm tut was es soll?
> Puh, schwer zu sagen, ich schaffe erst seit ein paar Tagen mit
> Compiler-Optimierungen. Breakpoints kann ich bspws. nur auf dem ersten
> und letzten return setzen. Der Breakpoint am return der uid wird
> automatisch gelöscht.
>
> A. K. schrieb:
>> Nicht aber, dass ein auf aggressiv eingestellter Optimizer den Code
>> Zeile für Zeile und Byte für Byte genau so umsetzt, wie der Quellcode
>> suggeriert.
> Achso OK, ich verstehe. Also kann man debuggen eigentlich vergessen.
> Kann man dann überhaupt 100%-ig sicher sein, dass ein größeres Programm
> genau das tut, was man von ihm verlangt?

Du hast, denke ich, die Aussage nicht vollständig erfasst.

Die Optimierung wird dann Variablen wegfallen lassen, wenn sie die 
gleiche durch den Code beschrieben Funktionalität auch ohne sie erzeugen 
kann.

Der Effekt ist also nur, dass Du die Variable im Debugger nicht mehr 
siehst oder anzeigen lassen kannst. In einigen Fällen entfallen auch 
Codeteile, auf die Du dann keine Breakpoints mehr setzen kannst.

ABER: Die Funktionalität ist (in der Regel, also nur dann nicht, wenn 
ein Fehler im Compiler vorliegt - und das ist ausgesprochen selten) 
haargenau die selbe.

Daher: Testet und debuggt man einen Code erst einmal ohne Optimierung. 
Erst wenn das gelungen ist, schaltet man die Optimierung ein.

Wenn es dann Fehler gibt, dann liegt ein anderer Fall vor. Nämlich der, 
dass Du zwar syntaktisch korrekt eine interpretierbare Anweisung 
hingeschrieben hast, die aber nicht tatsächlich unter allen relevanten 
Umständen, dass machst, was Du tatsächlich beschreiben wolltest.

Du kannst also sicher sein, das getester und debuggter Code tut was er 
aussagt. Nur kannst Du nicht sicher sein, dass Du Dich hundertprozentig 
korrekt ausgedrückt hast.
Das ist ein Unterschied zu, der Compiler macht was er will ohne das Du 
darüber Kontrolle hast.

Obwohl ich selbst sehr gerne in C programmiere, muss ich einräumen, dass 
auch ich immer wieder mal über etwas abwegige Deutungen stolpere, die 
aber nichts desto trotz durch den Standard (mehr oder weniger klar) 
beschrieben sind. Das zeigt sich aber eben genau bei der Optimierung. 
Die Optimierung ist extrem "konservativ" und geht nach dem "Buchstaben 
des Gesetzes". Anders als wir Menschen. Das ist das Problem. Es sitzt 
vor dem Bildschirm.

Autor: Reginald Leonczuk (Firma: HS Ulm) (reggie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hanswurst schrieb:
> Du hast, denke ich, die Aussage nicht vollständig erfasst.
Ich habe mich undeutlich ausgedrückt, genauso wie du es beschreibst, 
habe ich es verstanden :)

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Reginald L. schrieb:
>> Nur wenn man es gemäss dem C Standard 100%-ig richtig formuliert hat.
> Wer kann sowas bei größeren Programmen, Gott? :)

Deshalb gibt es auch keine 100%-ig fehlerfreie grössere Programme. Auch 
Gott hat bekanntlich seinen ersten Ansatz (Paradies) völlig versemmelt 
und auch den zweiten nach längeren Tests in grossen Teilen wieder 
vernichtet (Noah).

Autor: Hanswurst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Reginald L. schrieb:
> Hanswurst schrieb:
>> Du hast, denke ich, die Aussage nicht vollständig erfasst.
> Ich habe mich undeutlich ausgedrückt, genauso wie du es beschreibst,
> habe ich es verstanden :)

Aha. Schön. Viel Erfolg, weiterhin.

Autor: Reginald Leonczuk (Firma: HS Ulm) (reggie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Auch
> Gott hat bekanntlich seinen ersten Ansatz (Paradies) völlig versemmelt
Mal davon abgesehen, dass ich ich absolut nicht bibeltreu bin:
Vielleicht war ja genau das der Plan ;)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.