Prozessor bleibt bei case switching hängen

Laurin schrieb:
> ... dann bleibt er jeweils plötzlich in einem case hängen.

Und das wäre welcher?

Kein bestimmter. Ist immer mal wieder ein anderer case.

Laurin schrieb:
> Kein bestimmter. Ist immer mal wieder ein anderer case

Da wirkt manchmal ein "default:" im Switch-Case Wunder :-) (mit dem man 
z. B. die Motore abschaltet)

Oh ok. Wie müsste denn ein case aussehen mit einem default? Die Lösung 
für mein Problem scheint ja sehr simpel zu sein. Sorry ich bin ein 
Neuling in Sachen Programmieren ;)

Die delay steht noch dort, weil ich mit verschiedenen delay-zeiten 
experimentiert habe. Mir ist klar, dass delay(0) nix bewirkt

Ja mit dem Xode, den ich gepostet habe.

Am Verhalten der Motoren. Sie verhalten sich in punkto Geschwindigkeit 
und Drehrichtung jeweils entsprechend einem case, zb. schnell vorwärts 
oder schnell rückwärts

Ok. Der Original-Code stammt nicht von mir sondern von instructables.com

Was würdet Ihr nun vorschlagen. Den ganzen Code neu und ohne switch 
case?

Es gibt noch mehr Möglichkeiten
a)
bluetooth.available() liefert beständig 0 zurück.

b)
bluetooth.read() kehrt nicht zurück.

Laurin schrieb:
> Was würdet Ihr nun vorschlagen.

Mehr prints einbauen um herauszufinden wo das Programm genau "hängt".
z.B. einen, wenn bluetooth.available() 0 liefert, und je einen vor und 
nach bluetooth.read()

Danke vielmals für deinen Input Joachim!

Hallo Joachim

Habe erst folgendes, wie von Dir vorgeschlagen, nach den letzten Case 
eingebaut:

default:
cmd=0;
break;

Resultat: Die Motoren laufen nach dem power up, ohne dass ich Befehle 
gebe.

Dann:
if(isprint(cmd)) vor dem switch start

Resultat: Die Motoren bleiben nicht mehr hängen, drehen aber immer bei 
voller Geschwindigkeit, auch wenn ich ein slow speed Befehl gebe.

Der Code sieht jetzt so aus (siehe attachment)

Stimmt leider nicht, sorry. Musste nach erneutem Aufstarten feststellen, 
dass die Motoren laufen gemäss den Befehlen. Leider bleiben sie immer 
noch hängen..

Hier der Sketch mit beiden Änderungsvorschlägen von Joachim.

Helmut H. schrieb:
> default ist auch üblicherweise die letzte Anweisung im switch, guckstdu
> https://www.arduino.cc/en/Reference/SwitchCase

Nicht unbedingt - man muss "default:" schon angeben - von alleine wird 
das die letzte Anweisung im switch case nicht :-) (O.K. - böse ...).

Man muss sich das halt vor Augen führen. Der Compiler/Prozessor ist 
doof. Der Programmierer sagt: Wenn 1 dann A, Wenn 2 dann B, Wenn 3 dann 
C. Fertig.

Wenn 4, 5, 6, ... Sonstwas oder Unendlich kommt weiß der 
Compiler/Prozessor nicht was zu tun ist. Und was tut man im Normalfall: 
Nichts, man wartet auf den nächsten Befeht - und so lange macht man das, 
was zuletzt "befohlen" wurde ...
Man kann natürlich nach jeder Befehlsausührung den Befehl auf einen 
bestimmten "Default"-Wert setzen - aber das kann man sich halt durch die 
"default:"-Anweisung auch ersparen.

Aber die Suchbegriffe "Arduino" und "switch case" in Google helfen da 
ungemein - wenn man das da lesen mag. K. A., ob es entsprechende 
YouTube-Videos dazu gibt - das ist nicht so recht meine Generation.

Übrigens helfen C-Bücher (so etwas gab es mal / hat sich, glaube ich, in 
einigen Nischen auch noch gehalten) in dieser Beziehung auch weiter. Es 
gibt auch Kurse an der Volkshochschule etc. welche Grundlagen vermitteln 
- durchaus nicht zu verachten.

Helmut H. schrieb:
> ar sehr missverständlich von mir, gemeint war, dass es als letzte
> Selektion angegeben werden sollte

Schon klar :-) - deswegen ja auch "böse" :-)

Joachim B. schrieb:
> Helmut H. schrieb:
>> Dieter F. schrieb:
>>>   default:
>>    md.setM1Speed(0); // stopped
>>    md.setM2Speed(0); // stopped
>>    break;
>> >
>> Das cmd=0 bringt hier nichts.

Nein, das habe ich nicht geschrieben (obwohl so korrekt) - schau bitte 
nochmal nach.

Das war Helmut:
Beitrag "Re: Prozessor bleibt bei case switching hängen"

Also, habe genau das eingebaut nach dem letzten case:

default:
md.setM1Speed(0); // stopped
md.setM2Speed(0); // stopped
break;

Leider hängt das blöde Ding immer noch nach wenigen Sekunden. Ich 
schmeiss das Teil jetzt dann ausm Fenster ;(

Laurin schrieb:
> Leider hängt das blöde Ding immer noch nach wenigen Sekunden.

Dann hast Du wohl noch ein Verbindungsproblem. Probiere doch mal einen 
anderen Kanal oder eine geringere Baudrate. Hast Du Antennen dran?

Hallo Marc

Du meinst so, oder?

void loop() {

  if (bluetooth.available()) {
    cmd = bluetooth.read();
    Serial.write(cmd);
    Serial.print("CMD:"); Serial.println(cmd);
    switch (cmd)
    {
      case 'C':
        Serial.print("M1:"); Serial.println(0);
        Serial.print("M2:"); Serial.println(0);
        // md.setM1Speed(0); // stopped
        // md.setM2Speed(0); // stopped
        break;

Ok, das Ding läuft jetzt seit ner Stunde, ohne Fehler.

Ohne Joystick-Ausschlag sehe ich im Serial Monitor immer:

CCMD:67
M1:0
M2:0

Würdest Du jetzt mit dem Auskommentieren beginnen?

Habe hatte alle commands geprüft. War alles so wie gedacht. Jetzt habe 
ich begonnen, Auszukommentieren.
Bei der Reaktivierung des case 'F' hängt er nun wieder und im Serial 
Monitor kommt:

oCMD:111

Er printet die Motor Speed auch nicht mehr

Joachim B. schrieb:
> du solltest endlich mal auf Input prüfen und alles was nicht

Habe ich probiert. Das Resultat ist, dass die Kommandos verzögert 
ankommen und die Motoren trotzdem hängen bleiben.

void loop() {

  if (bluetooth.available()) {
    cmd = bluetooth.read();
    Serial.write(cmd);
    if ((cmd >= 'A' && cmd < 'J') || (cmd >= '0' && cmd < '6'))
    {
    switch (cmd)
    {
      case 'C':
        md.setM1Speed(0); // stopped
        md.setM2Speed(0); // stopped
        break;

und so weiter..

Bevor wir uns alle den Kopf zerbrechen über die Empfänger-Seite poste 
ich mal noch den Sketch der Sender-Seite. Vielleicht ist da etwas nicht 
koscher.
Danke an alle, die helfen!

Nein ist der Sketch für den Sender. Habs grad nochmals überprüft.

Hallo alle

Es gibt News: die Ursache ist gefunden. Es ist eine Ursache, die mir 
immer mal wieder im Kopf rumschwirrte, aber der ich trotzdem zu wenig 
Aufmerksamkeit schenkte. Die Ursache ist Noise von den DC-Motoren (beide 
entkoppelt mit je drei 100nF caps) die in das RF-Modul gelangte. Und 
zwar über Ground, also dem Alu-Chassis. Ich habe alles HF entkoppelt und 
seit da hängt nichts mehr.

Ich danke Euch allen für die vielen Inputs!