Spricht etwas gegen solch eine konstruktion und wenn ja was? das ganze auf einem avr-gcc switch(class_G){ case 0xD3: //------------------- // Check out Status Messages //------------------- switch(ctype_G){ case TY_UTC_TIME: SCH_Add_Task(recvTime,2,0); break; }//ctype_G //------------------- break;//Terminal Status Messages }//class_G
Mh... das hab ich doch eigentlich und wenn nich würde ja wenisgtens der compiler maulen ... oda ?
Was meinst du genau? Was soll der Code machen? Dagegen spricht nix, aber bei einer switch-Anweisung wird der Compiler eher eine if-else-Kaskade generieren, wenn die case-Werte zu weit auseinander liegen als eine Sprungtabelle anzulegen.
Also wenn class_G = 0xD3 ist dann soll er den nächsten switch abarbeiten (ctype_G) mehr eigentlich nicht. Er Springt nur immer raus ohne den nächsten Switch anzuspringen obwohl class_G den Wert 0xD3 hat
Meine Erfahrung ist, das Debuggen mir printf() keine Sünde ist, wenn man sich einfach nicht mehr zu helfen weiss und der Code einfach nicht das macht, was er soll. Manchmal kommt das die Erleuchtung recht schnell :)
Hmm....hat der Controller keinen UART oder einen Port-Pin übrig? Und auch keine JTAG oder einen Debugger da? Schau dir halt mal den assembler code an, den der gcc aus dem source generiert. Vielleicht wird dann klar, was da passiert.
Oder vergiss meinen letzten Post doch nicht ;) Immer diese "ich spar mir ne Zeile zugunsten der Unübersichlichkeit" Mentalität. Die geht mir auf den Keks. switch(a) { } >Also wenn class_G = 0xD3 ist dann soll er den nächsten switch abarbeiten >(ctype_G) mehr eigentlich nicht. >Er Springt nur immer raus ohne den nächsten Switch anzuspringen obwohl >class_G den Wert 0xD3 hat Dann pack den nächsten switch() in eine Unterroutine. Funktioniert das so wirklich nicht. Müsste man glatt mal ausprobieren ;)
> Funktioniert das so wirklich nicht. Müsste man glatt mal > ausprobieren ;) Klar funktioniert das. Warum auch nicht? Nur: Der Code ist sicher wieder nicht der Originalcode sondern irgendwas für das Posting zurecht gemachtes. Mit dem Effekt, dass im Originalcode wieder irgendein anderes Problem vorliegt und der switch-case muss es dann ausbaden :-)
nein es ist der original code davor ist nur eine Bedingung(if) ob der switch überhaupt angesprungen werden soll. Kann es daran liegen das class_G ein char ist ?
Sören Rohweder wrote: > nein es ist der original code davor ist nur eine Bedingung(if) ob der > switch überhaupt angesprungen werden soll. > Kann es daran liegen das class_G ein char ist ? Nein. >Er Springt nur immer raus ohne den nächsten Switch anzuspringen obwohl >class_G den Wert 0xD3 hat Was bedeutet das? Welcher nächster switch. Zeig doch mal ein bischen mehr aus der Umgebung und was genau wann passiert.
So nun hab ich es selber herausgefunden: class_G ist ein 'char' den kann man nicht gegen ein unsigend Hex Wert vergleichen da der Compiler in den Assembler einen check einbaut, der auf das Negativ Bit überprüft. Ich hab mir das gerade im Assembler nochmal angeschaut, leider bin ich da nun nicht vollends durchgestiegen, weiss aber das es funktioniert wenn ich den char vorher nach int caste.
signed und unsigned mischen (ob ein char signed oder unsigned ist ist implementationsabhängig) führt immer wieder zu Problemen und Überraschungen. Daher solltest du dir angewöhnen: Wenn du auf Byte-Ebene arbeitest dann gibt es nur 'unsigned char' oder uint8_t. Alles andere führt über kurz oder lang immer wieder zu Problemen.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.