C Kontrollstruktur will nicht AVR

[Peter M. (allforone)]

Hallo Freunde der Sonne,
ich habe ein Problem bei einem einfachen C-Programm. Es soll auf meinem 
MyAVR USB MK2 Board laufen. Das tut eigentlich nichts zur Sache, es ist 
ein Logikfehler, den es zu finden gilt.

#include <avr/io.h>
#include <avr/delay.h> 

 uint8_t Modus;

int main(void)
{
  DDRB |= (1<<DDB0); //PORTB0 Ausgang
  Modus = 1;
  PORTB |= (1<<PORTB0); 

  while(1==1)
  { 
    if (Modus == 1){ //!!!!!Hier
    
      for(int i = 0;i>30;i++){
        
        if (!(PORTB & (1<<PORTB0))){
          PORTB |= (1<<PORTB0);
          }
        else{
          PORTB &= ~(1<<PORTB0);
          }
        _delay_ms(90);
      }  
      Modus+=1;
    }
    
    if (Modus == 2){
    
      for(int i = 0;i>30;i++){
  
        if (!(PORTB & (1<<PORTB0))){
          PORTB |= (1<<PORTB0);
        }
        else{ 
          PORTB &= ~(1<<PORTB0);
        }
        _delay_ms(45);
      }            
      Modus += 1; //!!!!!Hier
    }

    if (Modus == 3){
      PORTB &= ~(1<<PORTB0);
        for(int i = 0;i>30;i++){
          _delay_ms(100);
        }
      Modus= 1; //!!!!!Hier
    }   
  };
  return 0;
}

Zwischen den gekenntzeichneten 3 Zeilen springt der Debugger hin und 
her.
Nur verstehe ich nicht wieso. Es soll in eine 1 auf PortB0 in 
verschiedenen Frequenzen ausgegeben werden. Durch die For-Schleife soll 
eine Frequenz dann eine kurze Zeit anhalten und dann zur nächsten 
Wechseln.
Am Ende will ich damit eine Tonleiter basteln.

Vielen Dank!

[Peter II (Gast)]

> for(int i = 0;i>30;i++){

schau mal genau was dort steht.

[holger (Gast)]

for(int i = 0;i>30;i++){

Wird nie ausgeführt.

[Martin (Gast)]

habe mal alles fehler korrigiert für dich!!

[Peter M. (allforone)]

Vielen Dank Peter,Holger und Martin. Vor lauter Bäumen habe ich den Wald 
nicht mehr gesehen.

[Name (Gast)]

Das Toggeln von PORTB0 lässt sich auch deutlich kürzer schreiben:

PORTB ^= (1<<PORTB0);

statt

if (!(PORTB & (1<<PORTB0))){
          PORTB |= (1<<PORTB0);
          }
        else{
          PORTB &= ~(1<<PORTB0);
          }

Grüße

[Peter II (Gast)]

Name schrieb:
> Das Toggeln von PORTB0 lässt sich auch deutlich kürzer
> schreiben:PORTB ^= (1<<PORTB0);

Vorsicht: das ist aber langsamer und nicht atomar.

Lass es lieber so wie es da steht.

[ich bin ein gast ob es dem server gefällt oder nic (Gast)]

Peter II schrieb:
> Vorsicht: das ist aber langsamer und nicht atomar.

Gab es bei den neueren AVRs nicht die Möglichkeit per Schreiben auf PINx 
einen oder mehrere Ausgänge zu toogeln? Das sollte doch schneller und 
wieder atomar sein?

[Peter II (Gast)]

ich bin ein gast ob es dem server gefällt oder nic schrieb im Beitrag 
#2789217:
> Gab es bei den neueren AVRs nicht die Möglichkeit per Schreiben auf PINx
> einen oder mehrere Ausgänge zu toogeln? Das sollte doch schneller und
> wieder atomar sein?

ja aber das wird anders gemacht.

[ich bin ein gast ob es dem server gefällt oder nic (Gast)]

Hab ich mich doch richtig erinnert.

Peter II schrieb:
> ja aber das wird anders gemacht.
Schon klar, das ist nicht das was da oben steht.

[Peter M. (allforone)]

Was heißt nicht atomar?

[Peter II (Gast)]

Jan R. schrieb:
> Was heißt nicht atomar?

das die anweisung von compiler ein 3 schritte zerlegt wird.

Port einlesen
verordern
Port ausgeben


Atomar ist alles was in einem Schritt erledigt werden kann. Wo also ein 
Interupt nichts durcheinander bringen kann.

[Johann L. (gjlayde)]

Siehe atomar

[./. (Gast)]

Peter II schrieb:
> Vorsicht: das ist aber langsamer und nicht atomar.

Ach, und das Original des TO ist atomar?! Da werden nicht nur sbi und 
cbi verwendet, sondern etwas Kontrollfluss wird auch noch benötigt.
Und langsamer ist das auch nicht. Das XOR braucht 4 Takte; das 
if-else-Konstrukt 8 bzw. 4 (je nach Verzweigung). Damit ist das 
if-else-Konstrukt im Falle der Gleichverteilung (Bit gesetzt/nicht 
gesetzt) sogar langsamer.

[Johann L. (gjlayde)]

./. schrieb:
> Peter II schrieb:
>> Vorsicht: das ist aber langsamer und nicht atomar.
>
> Ach, und das Original des TO ist atomar?!

Ja, ist es.

Lass zum Beispiel
 

#include <avr/io.h>

void foo (void)
{
    while (1)
    {
        if (!(PORTB & (1 << PORTB0)))
            PORTB |= (1 << PORTB0);
        else
            PORTB &= ~(1 << PORTB0);
    }
}

durch avr-gcc -O und du bekommst
 

foo:
.L5:
  sbic 0x18,0
  rjmp .L3
  sbi 0x18,0
  rjmp .L5
.L3:
  cbi 0x18,0
  rjmp .L5

Es ist nun kein Problem mehr, wemm asynchron zum Beispiel PB.1 verändert 
wird.

Kommt es auf die Reihenfolge von Änderungen an, etwa daß PB.1 nur nach 
einer bestimmten Aktion an PB.0 verändert werden darf, dann ist das ein 
Synchronisierungsproblem aber keines der Atomarität.

Code wie
 

PINB = 1 << PORTB0;

wie ihn neuere AVRs erlauben ist natürlich das beste, aber ein Compiler 
darf und wird nicht eine Sequenz wie
 

PORTB ^= 1 << PORTB0;

darin umwandeln.

[./. (Gast)]

Du hast natürlich Recht. Ich hatte mit -O2 getestet, aber mit -Os werden 
die rjmps noch schön auf beide Zweige aufgeteilt, so dass sie gleich 
"lang" sind.
Weißt du wie lange ein sbic braucht? Im Datenblatt steht "1  2  3" - 
da bin ich nicht recht schlau geworden und habe 2 angommen, was ggf. 
nicht korrekt ist.

[Coder (Gast)]

Wenn ich im Code Verzögerungen in ms sehe, würde ich mir über die 
Ausführungsgeschwindigkeit von Bits toggeln und ähnlichem keine Gedanken 
machen (wollen). Zum Anderen werden ja hier keine Interrupts verwendet, 
so dass man sich auf über "atomarität" und synchronisation ebenso keine 
Gedanken machen muss.

[spess53 (Gast)]

Hi

>Weißt du wie lange ein sbic braucht? Im Datenblatt steht "1  2  3" -
>da bin ich nicht recht schlau geworden und habe 2 angommen, was ggf.
>nicht korrekt ist.

1 Takt, wenn der nächste Befehl nicht übersprungen wird

2 Takte, wenn der nächste Befehl übersprungen wird und der übersprungen
  Befehl 1 Word lang ist

3 Takte, wenn der nächste Befehl übersprungen wird und der übersprungen
  Befehl 2 Words lang ist

MfG Spess

[spess53 (Gast)]

Hi

der übersprungen -> der übersprungene

MfG Spess

[./. (Gast)]

Vielen Dank für die Info.

[Axel S. (a-za-z0-9)]

Martin schrieb:
> habe mal alles fehler korrigiert für dich!!

Ich zweifle die Programm-Logik Logik immer noch an. Wenn man mal das 
Rauschen wegläßt, dann steht da:

modus=1;
for (;;) {
  if (modus==1) {
    modus=2;
  }
  if (modus==2) {
    modus=3;
  }
  if (modus==3) {
    modus=1;
  }
}

maW: die ganzen if()s sind vollkommen sinnlos, weil immer wahr. Die 
"modus" Variable erfüllt keinen Zweck und kann wegoptimiert werden.


XL

[dochgast (Gast)]

Wenn das ein Zustandsautomat sein soll würde ich mal elsif 
ausprobieren...

[EGS_TI (Gast)]

Ja, so wie es da steht springt er doch von einem if-Block in den 
nächsten....