Hallo! So, wie ich es aus der library verstanden habe, liefert mit strstr() einen pointer zurück, der auf den Beginn des im Suchstring vorgkommenden substrings zeigt. memcmp liefert mir die info, des ersten nicht überinstimmenden Zeichens, bzw, ob es "größer/kleiner" ist. ?!? vllt könnt ihr mir etwas auf die Sprünge helfen. 1) Frage: Wann verwende ich welche funktion? (PRAKTISCH) 2) Wenn ich nur schauen möchte, ob mir jemand via UART den Befehl "PING\n" gesendet hat, bietet sich da strstr an oder soll ich lieber per memcmp abfragen? Danke für Antworten!
strstr finden auch auch PING in "asdlfjasdfPINGasdfasdf" - damit düfte es klar sein was du brauchst.
nimm strcmp. Du suchst nicht nach einem Substring. Und du hast (hoffentlich) die Null als Stringtermination. Volker
neuling schrieb: > 2) Wenn ich nur schauen möchte, ob mir jemand via UART den Befehl > "PING\n" gesendet hat, bietet sich da strstr an oder soll ich lieber per > memcmp abfragen? Die Frage stellt sich so nicht. Die erste Frage, die du dir stellen musst, lautet: Womit habe ich es zu tun? Sind es Strings, dann sind die Funktionen der str... Familie zuständig Oder sind es einfach nur Abfolgen von Bytes über die nichts weiter bekannt ist. Dann ist die Familie der mem... Funktionen zuständig. Daher kann sich die Frage gar nicht stellen: strstr oder memcmp. Denn beide Funktionen gehören unterschiedlichen Funktionsfamilien mit unterschiedlichen Aufgabenstellungen an. Auf der einen Seite Strings, auf der anderen Seite unstrukturierte Bytefolgen.
selbstverständlich habe ich (wie es standard-C-Strings verlangen) ein terminierendes '\0'. Damit stehen mir ja die string-funktionen zur verfügung. @ Peter: Deine Aussage ist falsch! eine Abfrage mittels strstr von "asdfPINGqwertz" auf "PING\n" sollte keine Übereinstimmung liefern! Dort ist kein '\n' drin enthalten. Ich werde dann einfach strstr nutzen, weil es mir egal ist, wenn ich vor oder nach einem vollst. command (z.B. "PING\n") fehlerhafte Zeichen empfangen sollte. wird ein \n detektiert, checkt meine funktion, welches command es ist. findet es kein command, wird der UART-RX-buffer einfach geleert.
neuling schrieb: > keine Übereinstimmung liefern! Dort ist kein '\n' drin enthalten. Ich > werde dann einfach strstr nutzen, weil es mir egal ist, wenn ich vor > oder nach einem vollst. command (z.B. "PING\n") fehlerhafte Zeichen > empfangen sollte. wird ein \n detektiert, checkt meine funktion, welches > command es ist. findet es kein command, wird der UART-RX-buffer einfach > geleert. Nun ja. Der übliche Ansatz ist es, dass man sog. Whitespace-Character (also Leerzeichen, Tabulator, \n) sowieso aus dem String entfernt (zumindest konzeptionell), ehe man zur Auswertung des Strings geht. Einem Benutzer ist nämlich nicht so ganz klar zu machen, warum
1 | PING<Return> |
akzeptiert wird
1 | PING <Return> |
2 | PING <Return> |
(oder andere Kombinationen davon) aber nicht. Ganz fatal ist es aber, wenn
1 | abcdPING<return> |
als PING-Kommando akzeptiert wird. Das heisst, der vernünftigste Ansatz ist es: Vom Zeilenbeginn her alle Whitespace-Zeichen überlesen Danach das erste Wort zu extrahieren Dieses Wort gegen die Liste der zulässigen Schlüsselwörter zu testen.
wieso <return>?!? meinst du mit return '\r' aus MAC OS oder '\n' aus Linux oder '\r\n' aus Windows? die Commands die ich erhalte, kommen von einem iphone über WLAN an ein WLAN-Modul gesendet. Wir haben verabredet, dass wir alle commands, die wir uns schicken, mit einem \n terminieren. Dann weiß der Empfänger immer, dass er nachschauen soll, ob vor dem \n ein Command vorliegt.
neuling schrieb: > wieso <return>?!? meinst du mit return '\r' aus MAC OS oder '\n' aus > Linux oder '\r\n' aus Windows? Weil dein Benutzer nicht \n eingibt sondern auf die Return Taste haut. Sonst kommt noch ein Schlauberger auf die Idee, er müsse hier PING\n tatsächlich P I N G \ n eingeben (Nicht lachen. Alles schon gehabt.) > die Commands die ich erhalte, kommen von einem iphone über WLAN an ein > WLAN-Modul gesendet. Wir haben verabredet, dass wir alle commands, die > wir uns schicken, mit einem \n terminieren. Dann weiß der Empfänger > immer, dass er nachschauen soll, ob vor dem \n ein Command vorliegt. D.h. du hast gar keinen Benutzer, der irgendwo Text eingibt? Dann kannst du das alles auch viel einfacher machen. Wozu ein kompletter String, wenn es ein Einzelbuchstabe auch tut. Ist einfacher zu generieren, einfacher zu empfangen und einfacher auszuwerten allemal.
der Benutzer ist eine App im iPhone. Diese App selbst fragt mich z.B., wie viele sensoren/aktoren ich habe, dann welche es sind usw... befehle wie 00T\n sendet mir der code der App. Einfach davon ausgehen, dass keine Störungen auf der TCP-Seite(WLAN) sind, tue ich hier mal. Aber mein WLAN-Modul gibt mir die Daten via UART weiter. einen Baudratenquarz nutze ich schon. Soll ich einfach nach exaktem vorkommen abfragen? mein rxbuffer wird am ende IMMER ein \0 tragen. dafür sorge ich. Dann könnte ich einfach strcmp nutzen für direkten vergleich. dann klappt "asdfPING\n" nicht....
neuling schrieb: > mein rxbuffer wird am ende IMMER ein \0 tragen. dafür sorge ich. Dann > könnte ich einfach strcmp nutzen für direkten vergleich. > > dann klappt "asdfPING\n" nicht.... muss es auch nicht. Allerdings gibt es auch keinen der asdfPING\n eingeben wird. Deine Gegenstelle ist ein Programm und das sendet immer PING\n wenn es PING\n meint :-)
und der HF-Sender, der sehr nah an den Leiterbahnen der UART liegt? Ich dachte es wäre eher quick and dirty, darauf zu bauen, nie Fehler über die Schnittstelle zu bekommen, gerade bei einer async. seriellen.
neuling schrieb: > und der HF-Sender, der sehr nah an den Leiterbahnen der UART liegt? Den kannst du sowieso nicht beeinflussen. Und vor allen Dingen kriegst du die von ihm möglicherweise verursachten Störungen auf diese Art sowieso nicht in den Griff.
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.