Switch-Case Anweisung kommt nicht zurück!

[Hans (Gast)]

Hallo,

kann man AVR Studio beibringen, dass es meckert, wenn man bei einer 
Switch Case Anweisung das Break vergisst? Werror habe ich eingeschaltet. 
Weiter interessier es mich, ob es einen Unterschied macht, den 
Programmteil in der Switch Anweisung einzuklammern oder nicht?:

Case xyz:
{
    ....
    break;
}

ich habe das dumme Problem, wenn ich in einer ISR die Switch-Case 
Anweisung ausführe, das dann das Programm die ISR nicht mehr verlässt 
und wdt greift (wdto60ms).

Mache ich den Programmausschnitt in der main-while(1) Schleife geht 
alles. Jedoch muss die Ausführung der Switch Anweisung unmittelbar nach 
dem adc-Complete Interrupt erfolgen, da es sehr zeitkritisch ist.

Ich habe den Inhalt der Switch-Anweisung in geschweiften Klammern, wie 
oben.
Ich kann's leider im Moment nicht selber testen, bin unterwegs. Bin für 
jeden Tipp dankbar.

MfG Hansi

[Klaus W. (mfgkw)]

Hans schrieb:
> Programmteil in der Switch Anweisung einzuklammern oder nicht?:
>
> Case xyz:
> {
>     ....
>     break;
> }

Das macht dann einen Unterschied, wenn man noch eine lokale Variable 
darin definiert (oder ähnliches), sonst nicht.

[(prx) A. K. (prx)]

Hans schrieb:

> kann man AVR Studio beibringen, dass es meckert, wenn man bei einer
> Switch Case Anweisung das Break vergisst?

Meines Wissens nicht.

> Weiter interessier es mich, ob es einen Unterschied macht, den
> Programmteil in der Switch Anweisung einzuklammern oder nicht?:

Nein. Es sei denn im Block sind lokale Variablen definiert.

[Klaus W. (mfgkw)]

Hans schrieb:
> ich habe das dumme Problem, wenn ich in einer ISR die Switch-Case
> Anweisung ausführe, das dann das Programm die ISR nicht mehr verlässt
> und wdt greift (wdto60ms).

Da würde ich eher tippen, daß du noch etwas anderes falsch machst.

[Ralf S. (spacedog)]

Hans schrieb:
> kann man AVR Studio beibringen, dass es meckert, wenn man bei einer
> Switch Case Anweisung das Break vergisst?

Vermutlich nicht, denn wenn man die break-Anweisung weglässt, ist das in 
keiner Weise ein Fehler, sondern wird sogar oft und mit Absicht so 
gemacht.

[Hans (Gast)]

Ich ändere in der Anweisung globale variablen, die aber als volatile 
deklariert sind.

[max (Gast)]

Und Zugriffe außerhalb der ISR darauf sind atomar?

Debugger steht dir nicht zur Verfügung um nachzuschauen, wo genau sich 
der AVR in seiner Ausführung befindet?

[Oliver (Gast)]

Hans schrieb:
> Ich kann's leider im Moment nicht selber testen, bin unterwegs. Bin für
> jeden Tipp dankbar.

Nach Hause kommen, Code hier posten. Bis dahin ist das nur raten auf 
Raten.

Oliver

[asdf (Gast)]

A. K. schrieb:
> Hans schrieb:
>
>> kann man AVR Studio beibringen, dass es meckert, wenn man bei einer
>> Switch Case Anweisung das Break vergisst?
>
> Meines Wissens nicht.

Nope, sieht nicht so aus, zumindest nicht für gcc:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652

Eventuell können einige statische Code-Checker hier aber Warnungen 
werfen (z.B. "splint" o.ä.), hab ich nicht geprüft.

[Uwe (Gast)]

> Nope, sieht nicht so aus, zumindest nicht für gcc
Ist ja auch ein GEWOLLTES Feature.

[Thomas E. (thomase)]

Hans schrieb:
> Programmteil in der Switch Anweisung einzuklammern oder nicht?:
Aber sicher.

> Case xyz:
> {   ....
>     break;
> }

Das break gehört jetzt nicht mehr zum switch, sondern zu der Anweisung, 
die unter dem case läuft. Die wird dann mit einem break abgebrochen. Er 
springt also aus dem geklammerten Teil raus und landet dann im 
geklammerten Teil des switch. Da muß dann auch wieder ein break stehen.

Also:
switch(a)
{
  case 0:
     //Mach' was
  break;

  case 1:
    {
     int b;
     //Mach' was
    }
  break;
}

Hans schrieb:
> kann man AVR Studio beibringen, dass es meckert, wenn man bei einer
> Switch Case Anweisung das Break vergisst?
Nein. Das hat mit AVR-Studio nichts zu tun, sondern mit C. Und da ist es 
erlaubt.

mfg.

[(prx) A. K. (prx)]

Thomas Eckmann schrieb:

> Das break gehört jetzt nicht mehr zum switch, sondern zu der Anweisung,
> die unter dem case läuft. Die wird dann mit einem break abgebrochen. Er
> springt also aus dem geklammerten Teil raus und landet dann im
> geklammerten Teil des switch. Da muß dann auch wieder ein break stehen.

Ein break gehört zum nächsten umgebenden for/while/do/switch Konstrukt, 
egal wieviele {} Klammern zwischendrin stehen. Ob man den zu einem case 
gehörenden Code umklammert oder nicht ändert nichts an der Zugehörigkeit 
vom break.

Die 3 Varianten hier sind also in dieser Hinsicht gleich:

case 1:
    ...;
    break;
case 2:
  {
    ...;
    break;
  }
case 3:
  {
    ...;
  }
  break;

[Hans (Gast)]

Soo, bin grad rein.

Hier die Funtkion, aus der ISR:

ISR(ADC_fertig)

...
set_brake(brake_state,ON);

dann in der Funktionen.c

/* set brake mode */
void set_brake (unsigned char brake_mode, unsigned char state)
{
  switch (brake_mode)
  {
    case RESISTIVE_BRAKE:
    {
      if(state==ON)
      {
        PORTA |= (1<<TRIGGER_RB);
      }
      else
      {
        PORTA &= ~(1<<TRIGGER_RB);
      }
    break;
    }
    
    case SHORTCIRQUIT_BRAKE:
    {
      /* inverted!!!  */
      if(state==OFF)
      {
        PORTA |= (1<<TRIGGER_SC);
      }
      else
      {
        PORTA &= ~(1<<TRIGGER_SC);
      }
    break;
    }
    default: break;
}

und aus dieser scheint es kein zurück mehr zu geben, da der AVR sich mit 
der im WDT eingestellten Zeit resettet. Wenn ich die Funktion in der 
main ausführen geht es, weil hier keine ISRs gesperrt sind und somit der 
WDT im Timerintterupt (alles 7,nochwas ms) zurückgesetzt wird.

Werds Montag gleich mal an der Hardware ausprobieren, aber daran könnte 
liegen (mit den geschweiften Klammern)?

Hansi

[Hans (Gast)]

Da fehlt noch ne Klammer, die is aber im Programm vorhanden ;-)

[Josef D. (jogedua)]

Hans schrieb:
> kann man AVR Studio beibringen, dass es meckert, wenn man bei einer
> Switch Case Anweisung das Break vergisst?

In Eclipse (Indigo) geht das.

[Hans (Gast)]

A. K. schrieb:
> Ein break gehört zum nächsten umgebenden for/while/do/switch Konstrukt,
> egal wieviele {} Klammern zwischendrin stehen. Ob man den zu einem case
> gehörenden Code umklammert oder nicht ändert nichts an der Zugehörigkeit
> vom break.

Thomas Eckmann schrieb:
> as break gehört jetzt nicht mehr zum switch, sondern zu der Anweisung,
> die unter dem case läuft. Die wird dann mit einem break abgebrochen. Er
> springt also aus dem geklammerten Teil raus und landet dann im
> geklammerten Teil des switch. Da muß dann auch wieder ein break stehen.

Wer hat denn nun Recht?

[Thomas E. (thomase)]

A. K. schrieb:
> Die 3 Varianten hier sind also in dieser Hinsicht gleich:
Hast recht.

Hans schrieb:
> Wer hat denn nun Recht?
A.K.

mfg.

[Hans (Gast)]

Gibt es sonst etwas "Auffälliges" an meiner Switch-Case?

[Dummschwaezer (Gast)]

ich stimme für A.K

[Oliver (Gast)]

Hans schrieb:
> und aus dieser scheint es kein zurück mehr zu geben

Du weisst aber nicht wirklich, ob die Funktion zurückkehrt, oder?

An der Funktion set_brake() kann es nicht liegen. Was passiert denn noch 
so in der ISR?

Oliver

[Thomas E. (thomase)]

Hans schrieb:
> void set_brake (unsigned char brake_mode, unsigned char state)

Füg' hier mal ein Watchdog-Reset ein. Vielleicht dödelt er die 8ms ja 
schon vorher ab.

> {
>   switch (brake_mode)

Nachdem wir das jetzt mit den Klammern und dem break geklärt haben, muss 
es ja irgendwo anders liegen.

[Hans (Gast)]

ISR(ADC_vect)
{
  u_gen = ADC * 1;
  
  /* Watchdog reset */
  wdt_reset();
    
  /* trigger resistive brake */
    /* set brake time counter */
    /* lock this function against re trigger */
      if
    (
      /* overvoltage or emergency stop */
      (
        (u_gen > u_switch_resistive_brake)||
        (PINA& (1<<EMERGENCY_STOP))
      )
      &&
      /* triggered yet */
      (brake_state == NO_BRAKE)
    )
    {
      /* set brake time */
      timer=RESITIVE_BRAKETIME_MAX;
      /* lock function against re trigger */
      brake_state=RESISTIVE_BRAKE;
      /* enable resistive brake */
      set_brake(brake_state,ON);
    }
}

Die Auswertung ist Moment noch mit direkten unskalierten ADC werten, 
nicht wundern.

Wenn ich einmal die if-Passage betrete, verriegelt sich diese 
anschließend durch verändern von brake_state selbst. Gleichzeitig wird 
eine variable (timer) auf einen wert gesetzt und in im 
Timeroverflow-Vektor decrementiert (Zeitfenster). Hier wird auch die 
nächste Messung angestoßen und der wdt zurück gesetzt. Aber das passiert 
alles schon garnicht mehr, da der wdt-reset dazwischen kommt. Ich sehe 
noch wie der Pin PORTA |= (1<<TRIGGER_RB) auf H geht und noch 60ms der 
WDT das Spiel beendet.

[rfv (Gast)]

Wird das ISR-Flag am Ende restet (von Dir)?

Wenn nicht dann wird deine ISR nur einmal aufgerufen, da ja kein neues 
Setzen des Flags möglich ist.

[Hans (Gast)]

rfv schrieb:
> Wird das ISR-Flag am Ende restet (von Dir)?
??? Das Flag löscht sich bei Verlassen der ISR selbst... ???!
Wie gesagt, wenn ich den teil unter

u_gen = ADC+1;

in die main packe, geht es einwandfrei, nur halt die Reaktion auf einen 
zu hohen ADC-Wert dauert mir zu lange, da die Kiste auch "nur" auf 32kHz 
Uhrenquarz läuft.

[Thomas E. (thomase)]

Hans schrieb:
> da die Kiste auch "nur" auf 32kHz
> Uhrenquarz läuft.
Dann verlängere mal deinen Watchdog. Das kann doch gar nicht gehen.
Was soll das überhaupt?

mfg.

[Vlad T. (vlad_tepesch)]

Hans schrieb:
> in die main packe, geht es einwandfrei, nur halt die Reaktion auf einen
> zu hohen ADC-Wert dauert mir zu lange, da die Kiste auch "nur" auf 32kHz
> Uhrenquarz läuft.

wenn ich mich recht erinnere braucht der ADC doch eine Frequenz zwischen 
50kHz und 200kHz.
Was du da also mit deinem ADC misst ist Mist.

Ich denke aber auch, dass das Problem an dem WDT liegt.
weiß ja nicht, was du für einen ADC-Prescaler hast und auf was für eine 
Sample-Dauer du am Ende kommst. Eventuell beißt der Hund vorher in die 
Resetleitung.

[Oliver (Gast)]

Die ISR wird ja erst aufgerufen, wenn der ADC fertig meldet. Und dann 
bleiben 1920 Zyklen, bis der wdt wieder zuschlägt. Das sollte für die 
paar Anweisungen ausreichen.

Wenn möglich, schalte doch mal LEDs beim ein- und Austritt in die ISR. 
Vielleicht ist der wdt ja auch falsch parametriert, und schlägt viel 
schneller zu.

Oliver

[Thomas E. (thomase)]

Mit dem Watchdog ist das wie mit dem Sleep. Das wird zuletzt eingebaut. 
Wenn alles andere läuft.
Dann findet man auch schneller den Fehler, wenn es irgendwo mit dem 
Timing doch nicht so passt, wie erwartet.

mfg.

[Johann L. (gjlayde)]

Vermutlich liegt das Problem hier:

Hans schrieb:

> ...

[Hans (Gast)]

Das Problem tritt nicht auf, wenn ich es mit 1MHz laufen lasse. Folglich 
fange ich mir das Timeout wegen zu langsam ein. Mit 120ms geht's auch 
nicht. Merkwürdig...

[Werner (Gast)]

Hans schrieb:
> Merkwürdig...

Dann ist es jetzt vielleicht doch mal an der Zeit, den Simulator 
anzuschmeißen, mit den passenden Stimuli zu füttern und zu gucken, womit 
der µC sich denn so die Zeit vertreibt, bis ihn der Hund erwischt.

[Hansi (Gast)]

Aus dem Datenblatt:
By default, the successive approximation circuitry requires an input 
clock frequency between 50kHz and 200kHz to get maximum resolution.

Und nun??? Internen WDT Oszillator mit 125kHz als Taktquelle nehmen?
Ich will sol wenig Strom wie möglich verbrauchen...

Aber sieht irgendjemand wo er sich ein Timout einfangen könnte?
Hier die Timer ISR:

/* System tick with 7,8ms */
ISR (TIMER0_COMPA_vect)
{
  /* Watchdog reset */
  wdt_reset();
  
  /*start new conversation */
  ADCSRA |= (1<<ADSC);

  /* decrement timer */
  if(timer)
  {
    timer--;
  }
}

Watchdog resetten, neue Messung starten, wenn Wandlung fertig watchdog 
resetten, ergebnis auswerten und von vorn.

was dauert da länger als 60ms (1966 Clocks)?


Hansi

[Karl H. (kbuchegg)]

Schmeiss endlich den Simulator an und miss es aus!

Dein im Nebel stochern bringt doch nix. Du verplemperst nur deine Zeit.

[Vlad T. (vlad_tepesch)]

Oliver schrieb:
> Die ISR wird ja erst aufgerufen, wenn der ADC fertig meldet.
ebend.
wird der Wdt zwischendurch resetted?
> Und dann
> bleiben 1920 Zyklen, bis der wdt wieder zuschlägt. Das sollte für die
> paar Anweisungen ausreichen.

Hansi schrieb:
> Und nun??? Internen WDT Oszillator mit 125kHz als Taktquelle nehmen?
> Ich will sol wenig Strom wie möglich verbrauchen...

dann laufe mit 1Mhz und lege dich in den Power Down und lass dich von 
dem WDT wecken.
Ob du jetzt 10s mit 32kHz ackerst oder .3s mit 1Mhz -da  wird 
stromspartechnisch wahrscheinlich letzteres effektiver sein.

[Thomas E. (thomase)]

Vlad Tepesch schrieb:
> Ob du jetzt 10s mit 32kHz ackerst oder .3s mit 1Mhz -da  wird
> stromspartechnisch wahrscheinlich letzteres effektiver sein.
Sehe ich auch so. Was für ein Controller ist das überhaupt?

mfg.

[Hansi (Gast)]

Karl Heinz Buchegger schrieb:
> Dein im Nebel stochern bringt doch nix. Du verplemperst nur deine Zeit.
Richtig, der Simulator zeigte Klarheit. Ich habe mit dem nur noch nie 
gearbeitet, aber ist ja relativ intuitiv...

Ich habe den Timer, der mit /* System tick with 7,8ms */
läuft falsch initialisiert, sodass der Timer0 im 16Bit Modus gelaufen 
ist und merkwürdigerweise trotzdem irgendwie funktioniert hat. Das es 
mir 1MHz lief, lag daran, dass das Programm eigentlich schon komplett 
ausgeführt worden war, bis der Timeout entstand...

*Schande über mein Haupt, dass is n dummer Anfängerfehler*

Ich benutze einen Tiny861. Nun läuft es im Simulator und auch 
hoffentlich in der Praxis am Montag. Besten Dank für alle Hilfen.



Hansi

[Karl H. (kbuchegg)]

Und wieder mal zeigt sich.
Der Fehler war ganz woanders als vermutet.