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!
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.
