Ich habe einen String in dem alles mögliche stehen kann. Wörter/Zahlenkombinationen mehrere Wörter mit Leerzeichen voneinander getrennt usw.... Wie kan ich da mit Switch Case einzelne fälle eines strings unterscheiden? Wie das ganze mit Chars oder Integer Werten geht ist mir klar habe aber einen ganzen String ...
iss nich, geht nur mit integralen Werten.
Gast
#2496247
gar nicht, nimm if else if
Ich habe nun eine Eingabe die über UART gemacht wird:
z.B. HELP$0a das$0a ist ja das \n
Aber wenn ich jetzt sag if(line == ("HELP\n" || "help\n")) dann geht er
da nicht rein. Was mache ich falsch? Line beinhaltet den String mit dem
Text.
Jemand eine Idee?
Gast
#2497591
André R. schrieb: > Jemand eine Idee? ja. C Buch lesen, am besten das Kapitel über strings, dort steht dann auch drin wie man stings zu vergleichen sind.
André R. schrieb: > Aber wenn ich jetzt sag if(line == ("HELP\n" || "help\n")) dann geht er > da nicht rein. Das geht so nicht. Das Zauberwort heist: strcmp(Str1,Str2) Also: if(!strcmp(line,"HELP")) tu was
Gibt es für die Funktion strncmp in der string.h auch eine möglichkeit automatisch Groß/Kleinschreibung zu ignorieren?
André R. schrieb: > Ich habe einen String in dem alles mögliche stehen kann. > Wörter/Zahlenkombinationen mehrere Wörter mit Leerzeichen voneinander > getrennt usw.... Dann brauchst Du einen Parser. Peter
Gast
#2497616
André R. schrieb: > Gibt es für die Funktion strncmp in der string.h auch eine möglichkeit > automatisch Groß/Kleinschreibung zu ignorieren? ja steht in der doku gleich mit drin.
Ich hab jetzt als Lösung einfach mit strupr den string auf großschreibung setzen lassen unabh. von der EIngabe. das funktioniert soweit. danke
Gast
#2498519
hm.. nur mal so ein gedanke.. man könnte.. die ersten 4 buchstaben eines strings relativ einfach in ein 32bit integer verwandeln, und ab da wäre ein case mit integers einfach. wie in manchen programmiersprachen/system üblich würde man dann nur den ersten teil eines wortes berücksichtigen, hier halt 4 buchstaben. wird aber schnell nicht den anforderungen genügen, und wörter die kürzer als 4 zeichen sind müsste man mit leerzeichen verlängern.
Vergiß es wieder, jeder hat so seine Jugendsünden.
Gast
#2498734
Wie Peter schon sagte, bau dir einen Parser. Am Besten einen, der gleich in der Uart-ISR beim Empfang der Zeichen arbeitet...
Matthias Lipinsky schrieb: > Wie Peter schon sagte, bau dir einen Parser. In der Codesammlung sind einige Beispiele. Matthias Lipinsky schrieb: > Am Besten einen, der gleich in der Uart-ISR beim Empfang der Zeichen > arbeitet... Besser nicht, sondern nach Zeilenende im Main. Sowas kann schonmal dauern und das ist ungünstig im Interrupt. Peter
Gast
#2498758
>Sowas kann schonmal dauern und das ist ungünstig im Interrupt.
Was dauert da?
Ich meine eine StateMaschine in der ISR, die, abhängig vom gerade
empfangenen Byte (und den vorigen ;-) geeignet weiterspringt.
Matthias Lipinsky schrieb: > Was dauert da? Z.B. einen float-Parameter würde ich ungerne im Interrupt parsen. Außerdem ist es sehr umständlich, immer nur ein Zeichen zu parsen. Man müßte jedesmal den kompletten Parserkontext sichern (welcher Parserschritt, Wort, Zeichen im Wort, Parameternummer, Parametertyp, Parametervorzeichen usw.) Viel einfacher ist es, wenn der zu parsende Satz komplett im Puffer steht. Peter
Peter Dannegger schrieb: > Außerdem ist es sehr umständlich, immer nur ein Zeichen zu parsen. Man > müßte jedesmal den kompletten Parserkontext sichern (welcher > Parserschritt, Wort, Zeichen im Wort, Parameternummer, Parametertyp, > Parametervorzeichen usw.) > > Viel einfacher ist es, wenn der zu parsende Satz komplett im Puffer > steht. Sehe ich genauso. Im Interrupt das empfangene Byte in den Puffer und im Protokoll eine eindeutige Erkennung wann ein Befehl/Eingabe zu Ende ist. Dann in der ISR ein Flag setzen, und das Hauptprogramm wartet auf dieses Flag bevor es den Parser anwirft.
Gast
#2500359
Matthias Lipinsky schrieb: > > Ich meine eine StateMaschine in der ISR, die, abhängig vom gerade > empfangenen Byte (und den vorigen ;-) geeignet weiterspringt. Richtig. Es ist zwar etwas mehr (Denk-)Aufwand, die Statemachine zu entwerfen und das Array aufzuschreiben statt schnell einen "Parser" mit ein paar Ifs hinzuschludern. Aber dafür braucht man in der ISR nur wenige Takte, weniger RAM, hat keine Pufferüberläufe und kann sinnvolle Fehlermeldungen erzeugen.