USART atmega32 mit Interrupt

Zitat:

---

Zitat von Ceos

volatile sagt dem compiler, dass die variable direkt aus/in dem spiecher geladen werden muss nach/vor jedem bearbeiten

---

So in etwa.

Zitat:

---

Zitat von Ceos

aber in dem obigen fall sind es doch atomare zugriffe! eine vergleichsoperation und eine zuweisung, also defakto kein volatile nötig oder ?

---

Wieso würfelst du das jetzt schon wieder zusammen?

Was sieht der Compiler in Bezug auf die Variable empfang in main?

Code:

---

unsigned char empfang = 0;

int main(void){

  while(1){

    PORTC = ~empfang;

    if(empfang){
      PORTC = ~a;
      empfang = 0;
    }
  }
}

---

Die Variable ist zu Anfang 0 und ändert sich nie in der Endlosschleife, also muss sie in der Endlosschleife immer 0 sein. Aus "PORTC = ~empfang" macht der Compiler daher gleich ein "PORTC = 0xff" und der ganze if-Block wird komplett rausgeschmissen (kann ja nie true werden).

"volatile" sagt dem Compiler "Achtung, diese Variable kann sich unerwartet außerhalb des linearen Code-Ablaufs ändern!" (deine Erklärung oben ist nur die direkte Konsequenz daraus). Er kann jetzt nicht mehr davon ausgehen, dass sie in der Schleife ja immer nur 0 sein kann. Überall wo empfang steht, muss die Variable auch tatsächlich gelesen/geschrieben werden.

Mit "atomaren Zugriffen" oder dem Typ der Variable hat das nicht das Geringste zu tun.

O_o dass der beim optimieren SOOOO weit geht war mir nicht bewusst O_o

danke dass du mir die augen geöffnet hast, das würde auch erklären warum meine bisherigen versuche einen meiner eignen quellcodes zu optimieren so herb in die hose gegangen sind -.-

ich habe das immer so verstanden, dass der compiler die variable unter gewissen umständen länger in den registern behält und erst nach abschluss aller arbeiten an der variable in den speicher zurückschreibt und es genau DA eben um den atomaren zugriff auf die variable geht und das volatile eben genau das verhindern soll, indem nach und vor jeder aktion an der variable mit dem speicher abgeglichen wird

aber kann man denn nicht die variable denn nicht irgendwie anders deklarieren? ich habe in einen meiner eigenen codes ein winziges timingproblem, dass ich mit selbstgebauten criticalsections gesichert habe, aber daran scheitert, dass die zugriffe auf die variable scheinbar zu lange dauern!

um es genau zu sagen ist es eine abfolge von if-abfragen (die sich von der statemachine bedingt nicht weiter reduzieren lassen) und unmengen rechenzeit verbrauchen und dazu führen, dass ich das entscheidende event verpasse wenn ich den zeitrahmen zu knapp wähle!

wäre es ratsam einen nicht volatile temp variable zu nehmen (vll. sogar ne registervariable) in die ich den wert der variable lege und dann damit vergleiche anstelle ?

Zitat:

---

Zitat von Ceos

wäre es ratsam einen nicht volatile temp variable zu nehmen (vll. sogar ne registervariable) in die ich den wert der variable lege und dann damit vergleiche anstelle ?

---

Ja, so was ist gängige Praxis.

Code:

---

volatile uint8_t var;
...
  while (1) {

      uint8_t tmp_var = var;

      if (tmp_var== ....
      ...

---

So ist sichergestellt, dass 1 mal pro Schleifendurchlauf der aktuelle Wert von var aus dem Speicher gelesen wird, und die ganze "Arbeit" kann mit einer lokalen Kopie in einem Register gemacht werden.