Code wird nicht Richtig ausgeführt

[Lukas W. (lukas_we)]

Hallo,

wie dem Betreff schon zu entnehmen ist habe ich ein Problem beim 
ausführen meines Programmcodes aber hier erstmal ein paar Daten worum es 
sich handelt.

Mikrocontroller: Atmega328PB
Programmieradapter: AVR-Dragon
Programmierumgebung: Atmel Studio 7

Beim Programmcode handelt sich es um eine Statemachine die durch ein 
Flag welches in der Mainloop geprüft wird ob es gesetzt ist aufgerufen 
wird. Das Flag wird in einem Timerinterrupt alle 50ms gesetzt. 
Angestoßen wird das ganze dadurch das die Variable "State" auf 
"Ausfahren" gesetzt wird. Nachdem alles im case Ausfahren abgearbeitet 
ist sollte es beim nächsten mal wenn die Statemachine aufgerufen wird in 
den Ausgefahren case springen was aber nicht passiert. Um der ganzen 
Sache auf den Grund zu gehen habe ich angefangen das ganze zu Debuggen. 
Beim Debuggen habe ich festgestellt dass wenn ich einen Breakpoint im 
Ausfahren case erstelle das Programm beim nächsten mal aufrufen der 
Statemachine in den Ausgefahren case springt. Ohne Breakpoint wird der 
Programmcode dann wieder nicht richtig ausgeführt egal ob im Debugmodus 
oder normal Programmiert. Woran könnte das liegen ?

Mit freundlichen Grüßen.
Lukas W.

switch(State)
{
  case Warten:
  break;
        
  case Ausfahren:
    motor_up();
    State = Ausgefahren;
  break;
        
  case Ausgefahren:
    if(getHall_up())
    {
      motor_stop();
      State = Warten;
    }
  break;
}

[jo mei (Gast)]

Lukas W. schrieb:
> Ohne Breakpoint wird der
> Programmcode dann wieder nicht richtig ausgeführt egal ob im Debugmodus
> oder normal Programmiert. Woran könnte das liegen ?

"Wilde Sprünge" deuten erst mal auf einen vom Compiler optimierten
Code hin den man grundsätzlich nicht richtig debuggen kann.

YMMV

Auch in der Make-Version "Debug" kann der Compiler zum Optimieren
aufgerufen worden sein. Prüfe daher erst ob dein Build ohne
Compiler-Optimierung eingestellt wurde.

[leo (Gast)]

Lukas W. schrieb:
> ... Das Flag wird in einem Timerinterrupt alle 50ms gesetzt.

Beim Flag fehlt "volatile"?

>   case Warten:
>   break;

Das kannst du streichen.

leo

[MaWin (Gast)]

leo schrieb:
> Das kannst du streichen.

Nö, das ist zum Verständnis genau so richtig. Der Compiler optmiert das 
schon.

[Lukas W. (lukas_we)]

Danke schon mal für die Antworten das ausschalten der Codeoptimierung 
hat leider nichts gebracht (Projekteinstellungen->Toolchain->AVR/GNU C 
Compiler->Optimization und Optimization Level auf None(-Q0)). Die 
Variable "State" hatte ich schon als Volatile deklariert.

[Max D. (max_d)]

Wo setzt du denn den State auf Ausfahren ?
Eventuell setzt diese Routine ja wiederholt deine Variable...

[Einer K. (Gast)]

Lukas W. schrieb:
> oder normal Programmiert. Woran könnte das liegen ?

Mir fehlt der Kontext um das sehen/testen zu können.

[Veit D. (devil-elec)]

Hallo,

stell dir bitte einmal die Frage was jemand Fremdes mit dem switch-case 
Code alleine anfangen kann? Kürze das Programm soweit zusammen wie es 
möglich ist und zeige es uns. Dann erst kann das Forum helfen.

[Dirk B. (dirkb2)]

Lukas W. schrieb:
> Das Flag wird in einem Timerinterrupt alle 50ms gesetzt.

Schafft es denn der Motor in 50 ms auszufahren (d.h. den Zustand Warten 
zu erreichen)?

[Stefan F. (Gast)]

Zum Debuggen musst du die Optimierungsstufe -O0 oder -Og benutzen.

[Wolfgang (Gast)]

Lukas W. schrieb:
> Die Variable "State" hatte ich schon als Volatile deklariert.

Und hast du sie auch passend initialisiert?

[Egon D. (Gast)]

Lukas W. schrieb:

> Ohne Breakpoint wird der Programmcode dann wieder
> nicht richtig ausgeführt egal ob im Debugmodus
> oder normal Programmiert. Woran könnte das liegen ?

Daran, dass Dein (Denk-)Modell nicht stimmt.

Die Zustände der Mechanik und die Zustände des steuernden
Automaten sind erstmal nicht identisch: Wenn die Mechanik
betriebsmäßig ZWEI Zustände kennt, z.B. "Eingefahren" und
"Ausgefahren", muss der steuernde Automat VIER Zustände
kennen: "Eingefahren", "Ausfahren", "Ausgefahren" und
"Einfahren". Das liegt einfach daran, dass der steuernde
Automat wesentlich schneller ist als die gesteuerte
Mechanik, so dass "Übergänge" der Mechanik in "Zustände"
des steuernden Automaten abgebildet werden müssen.


Die nächste Falle lauert schon: Mit vier Endlagenschaltern
können zwar vier verschiedene Zustände codiert werden --
von diesen sind aber nur drei betriebsmäßig zulässig:
- "00" = "Aktor in Bewegung",
- "10" = "vordere Endlage",
- "01" = "hintere Endlage",
- "11" = unzulässig (--> Fehler).

Man braucht also zur korrekten Behandlung erstens einen
Timeout und muss zweitens die Vorgeschichte berücksichtigen,
um softwaremäßig "Einfahren" und "Ausfahren" unterscheiden
zu können.

Ungefähr darauf wollte Dirk wohl mit seiner kurzen Frage
hinweisen, nehme ich an.

[M.K. B. (mkbit)]

Zeig bitte ein minimales Beispiel. Ich vermute du hast ein Problem mit 
parallel laufenden Prozessen (main, interrupt).

[Dirk B. (dirkb2)]

Egon D. schrieb:
> Ungefähr darauf wollte Dirk wohl mit seiner kurzen Frage
> hinweisen, nehme ich an.

Ich wollte darauf hinaus, dass da sowas wie

[c]
if (Taste_gedrueckt())
    State = Ausfahren;
else
    State = Warten;
[\c]

in der ISR steht

[Carl D. (jcw2)]

Dirk B. schrieb:
> Egon D. schrieb:
>> Ungefähr darauf wollte Dirk wohl mit seiner kurzen Frage
>> hinweisen, nehme ich an.
>
> Ich wollte darauf hinaus, dass da sowas wie
>

 if (Taste_gedrueckt())
     State = Ausfahren;
 else
     State = Warten;

>
> in der ISR steht

Als "non-Windows" geht es besser ;-)

Sprich [/c] statt [\c] am Ende

[Dirk B. (dirkb2)]

Carl D. schrieb:
> Als "non-Windows" geht es besser ;-)
>
> Sprich [/c] statt [\c] am Ende

?‍♂️ Auf der Tablet-Tastatur ist der \ direkt neben [

[Carl D. (jcw2)]

Dirk B. schrieb:
> Carl D. schrieb:
>> Als "non-Windows" geht es besser ;-)
>>
>> Sprich [/c] statt [\c] am Ende
>
> ?‍♂️ Auf der Tablet-Tastatur ist der \ direkt neben [

Auf meiner auch, dann drücke ich vorher auf die Taste "123" und schon 
paßt's ;-)

[Dirk B. (dirkb2)]

Carl D. schrieb:
> Dirk B. schrieb:
>> Carl D. schrieb:
>>> Als "non-Windows" geht es besser ;-)
>>>
>>> Sprich [/c] statt [\c] am Ende
>>
>> ?‍♂️ Auf der Tablet-Tastatur ist der \ direkt neben [
>
> Auf meiner auch, dann drücke ich vorher auf die Taste "123" und schon
> paßt's ;-)

Ja, ich demnächst auch.

[Lukas W. (lukas_we)]

Danke für die Antworten. Die Statemachine war schonmal weiter ausgebaut 
ich wollte die Statemachine zum finden des Fehlers nur so klein wie 
möglich halten damit das ganze übersichtlicher ist und es selbst so 
schon nicht funktioniert. Der Motor braucht länger als 50ms zum 
Ausfahren bzw bis er den Hallsensor erreicht, was kein Problem 
darstellen sollte da die Statemachine solange immer wieder in den 
Ausgefahren case springen sollte und prüfen sollte ob der Motor am 
Hallsensor angekommen ist. Der Motor ist auch nicht schnell genug um dem 
Hallsensor in 50ms überfahren zu können. Hier nochmal etwas mehr code 
ich hoffe das macht das ganze verständlicher. resetSerCommand() am ende 
setzt das Serielle Komando zurück was verhindert das befehle doppelt 
ausgeführt werden.

enum States
{
  Warten = 0,
  Ausfahren,
  Ausgefahren,
  Einfahren,
  Eingefahren,
};

volatile int State = 0;

int main(void)
{
  init_all();
  FILE str_uart = FDEV_SETUP_STREAM(uart_putchar, NULL, _FDEV_SETUP_WRITE);
  stdout = &str_uart;
    while (1) 
    {
    if(getTimeSliceFlag() == 1)
    {
      resetTimeSliceFlag();
      switch(getSerCommand())
      {
        case 1:        //ausfahren
          State = Ausfahren;
        break;
        
        case 2:        //einfahren
          motor_down();
        break;
        
        case 3:        //Motor halt
          motor_stop();
        break;
        
        case 4:        //Hallschalter auslesen
          if(getHall_up() == 1)
          {
            printf("oberer Hallschalter\r\n");
          }
          
          if(getHall_down() == 1)
          {
            printf("unterer Hallschalter\r\n");
          }
        break;
        
      }
      
      switch(State)
      {
        case Ausfahren:
          motor_up();
          State = Ausgefahren;
        break;
        
        case Ausgefahren:
          if(getHall_up())
          {
            motor_stop();
            State = Warten;
          }
        break;
      }
      resetSerCommand();
    }
    }
}

[Christian H. (netzwanze)]

Da fehlt noch einiges vom Code.
Der angegebene alleine, kann nicht compiliert werde.

[Dirk B. (dirkb2)]

Die ISR spielt doch auch an State rum.
Die solltest du also auch zeigen.

[Teo D. (teoderix)]

Lukas W. schrieb:
> if(getTimeSliceFlag() == 1)

Sicher dass das Flag auch dort wieder gelöscht wird?!

Lukas W. schrieb:
> resetSerCommand() am ende
> setzt das Serielle Komando zurück was verhindert das befehle doppelt
> ausgeführt werden.

Das ist Mist (die wahrscheinliche Fehlerquelle). Bau das in die 
Statemachine ein! (Setzt das doch sicher eh nur auf "case 4:"!?


So wie ich das sehe, sollte das zweite Switch außerhalb der If Bedingung 
liegen. Also ständig ausgeführt werden....
Bzw. ich würde die Main, also die Switch Blöcke ungebremst laufen lassen 
und nur die Sensor/etc.-Abfrage, in den 50ms Task-Slot (IF-Block 
außerhalb der Switches) legen.

[Lukas W. (lukas_we)]

Dirk B. schrieb:
> Die ISR spielt doch auch an State rum.
> Die solltest du also auch zeigen.

void resetTimeSliceFlag(void)
{
  TimeSliceFlag = 0;
}

int getTimeSliceFlag(void)
{
  return TimeSliceFlag;
}

ISR(TIMER0_COMPA_vect)
{
  static int counter = 0;
  if(counter == 50)
  {
    TimeSliceFlag = 1;
    counter = 0;
  }
  else
  {
    counter++;
  }
}

[Lukas W. (lukas_we)]

Teo D. schrieb:
> Lukas W. schrieb:
>> if(getTimeSliceFlag() == 1)
>
> Sicher dass das Flag auch dort wieder gelöscht wird?!

Zwei zeilen darunter wird es gelöscht. Das Timing habe ich mit einem 
Oszi gemessen indem ich einen Ausgang toggeln lassen habe.

> Das ist Mist (die wahrscheinliche Fehlerquelle). Bau das in die
> Statemachine ein! (Setzt das doch sicher eh nur auf "case 4:"!?
Was soll case 4: mit meinem Problem zutun haben case 4: wird nur 
aufgerufen wenn ich befehl 4 per seriellen Komando ausführen will

[leo (Gast)]

Lukas W. schrieb:
> TimeSliceFlag = 0;

ob das "volatile" ist, zeigst du nicht. So wird das nix.

leo

[Teo D. (teoderix)]

Lukas W. schrieb:
>> Das ist Mist (die wahrscheinliche Fehlerquelle). Bau das in die
>> Statemachine ein! (Setzt das doch sicher eh nur auf "case 4:"!?
> Was soll case 4: mit meinem Problem zutun haben case 4: wird nur
> aufgerufen wenn ich befehl 4 per seriellen Komando ausführen will

Lukas W. schrieb:
> resetSerCommand() am ende
> setzt das Serielle Komando zurück was verhindert das befehle doppelt
> ausgeführt werden.

Wie funst das den dann, bzw. was wird den anstelle ausgefürt?

[Lukas W. (lukas_we)]

Ich schicke den Befehl 3 (case 3: des ersten Switch) per serielle 
Schnittstelle was soweit funktionert. In dem case 3 des ersten Switch 
wird der State der Statemachine gleich Ausfahren gesetzt was den Motor 
Startet und den State auf Ausgefahren setzt. Der Motor dreht sich aber 
die Statemachine kommt beim nächsten mal ausführen der Statemachine 
nicht in den  Ausgefahren State wo es den Motor stoppen sollte wenn er 
den Hallschalter erreicht sondern springt in den Warten state was 
eigentlich nicht passieren darf solange der Motor nicht am Hallsensor 
angekommen ist.

[leo (Gast)]

Lukas W. schrieb:
> Ich schicke den Befehl 3

Zu viel Blabla, zu wenig Code. Mach ein minimales und vollstaendiges 
Beispiel, das den Fehler wiedergibt.

leo

[Lukas W. (lukas_we)]

Also nach Stundenlangen Kopfzerbrechen habe ich den Fehler jetzt 
gefunden. Der Fehler lag nicht in der Software sondern in der Hardware. 
Das Labornetzteil das ich verwende konnte den hohen Anlaufstrom des 
Motors nicht bewältigen was zur folge hatte das die Versorgungsspannung 
etwas auf der Mikrocontroller Seite zusammengebrochen ist und dieser das 
Programm dann anscheinend von neuem gestartet hat oder irgend einen 
anderen mist gemacht hat. Vielen dank an alle die versucht haben mir bei 
meinem Problem zu helfen.

Mit freundlichen Grüßen.
Lukas W.

[Stefan F. (Gast)]

Lukas W. schrieb:
> Das Labornetzteil das ich verwende konnte den hohen Anlaufstrom des
> Motors nicht bewältigen

Hat es das nicht deutlich angezeigt?

[c-hater (Gast)]

Lukas W. schrieb:

> Also nach Stundenlangen Kopfzerbrechen habe ich den Fehler jetzt
> gefunden. Der Fehler lag nicht in der Software sondern in der Hardware.
> Das Labornetzteil das ich verwende konnte den hohen Anlaufstrom des
> Motors nicht bewältigen was zur folge hatte das die Versorgungsspannung
> etwas auf der Mikrocontroller Seite zusammengebrochen ist und dieser das
> Programm dann anscheinend von neuem gestartet hat

Selbst wenn das wirklich so gewesen wäre, hätte ein gutes Programm 
auch dann (also nach einem unerwarteten Reset mit kompletten 
Informationsverlust) noch keinen völligen Mist gemacht...

Für sowas sieht man natürlich einen initialen "Unknown"-Status vor, wenn 
es keine beschaffbare Information über eine bestehende Aktivität des 
Aktors gibt. Den braucht man sowieso, denn mindestens beim allerersten 
Start des Programms kann diese Situation eintreten, wenn der Aktor 
(warum auch immer) schon was tut.
Der Status endet, wenn entweder einer der Endlagensensoren was meldet 
oder eine Maximalzeit vergangen ist (die für den vollen Weg nötige + 
etliche % Sicherheit). Dann wechselt man entweder nach in einen der 
beiden Endlagen-Stati (wenn halt der entsprechende Sensor sich gemeldet 
hat) oder nach "kaputt". Denn das kann nur bedeuten, dass der Aktor 
einen erteilten Befehl nicht bis zum Ende ausführen konnte oder halt en 
Sensor defekt ist. In jedem Fall: kaputt.

Sprich: die hast noch viel zu lernen...