Mal wieder COM Port ... schwer zu erklären ^^

hi!

hm... das problem ist dass es nicht immer nur ein \r\n ist. manche antworten haben am anfang und am ende \r\n und manche nur am ende. außerdem bestehen manche antworten manchmal aus mehreren \r\n wie:
\r\nAT\r\nOK\r\n

gabba wally

Christoph

Die serielle Schnittstelle liefert im einfachsten Fall einen einfachen Bytestrom. TCP/IP liefert immer einen Bytestrom.
Du musst also irgendeine Art Protokoll definieren, mit dem du innerhalb dieses Bytestroms einzelne Befehle, Abschnitte oder was auch immer erkennen kannst.

Du könntest z.B. eine bestimmte Zeichenfolge festlegen, die den Anfang eines jeden Befehls markiert.

Das der "Bytestrom" mal getrennt ist und mal nicht, liegt einmal an den Timeout-Werten des Empfängers (wenn eine bestimmte Zeit nichts kommt, ist eben der "Bytestrom" zu Ende und danach beginnt eine neuer ...) oder der Sender macht einfach keine Pause beim Senden und packt 2 oder mehr Befehle zusammen. Die Handy-Befehlssequenzen haben aber alle einen eindeutigen Anfang und ein Ende - Du mußt nur rausfinden welche - und danach Deinen Befehls-"Parser" schreiben

Blackbird

ok...dnke für die antwort. hab mir schon gedacht, dass ich das ganze wohl irgendwie durchparsen muss. aber erschien mir irgendwie net so die "saubere" lösung...
ok, ich werds mal versuchen.
aber wie gesagt: das parsen is schon wieder ein problem, weil nur manche antworten vom handy fangen mit \r\ an und hören auch so auf. und manche hören nur mit \r\n auf. und manche antworten sind sozusagen zwei antworten in einer.
schick ich z.b. "at\r" hin. kommt "\t\nAT\r\nOK\r\n" zurück. d.h. ich kann nciht einfach nach den \r\n parsen... aber jo... ich schau mal. danke!
wenn noch wer was weiß wär ich dankbar wenn ers hier reinschreiben würd!

gabba wally

und manche antworten sind sozusagen zwei antworten in einer.
schick ich z.b. "at\r" hin. kommt "\t\nAT\r\nOK\r\n" zurück. d.h. ich kann nciht einfach nach den \r\n parsen...

Wieso kannst du nicht nach \r\n parsen? Du gehst einfach deinen Puffer von vorne bis hinten durch bis du auf ein \r\n triffst, dann kopierst du dir diesen teil-string (in deinem beispiel: "\t\nAT\r\n") irgendwo hin um damit zu arbeiten (vielleicht ne queue oder so). und dann machst du solange weiter bis du wieder auf ein ganzen befehl gefunden hast. Wenn zwar zeichen bekommen hast aber noch keinen ganzen befehl machst du halt solange read() oder was auch immer bis du den ganzen befehl hast usw... Es kann naemlich vielleicht auch vorkommen das du einmal "\t\nAT\r\nOK\r\nAT" bekommst dann hast du nur 2 befehle und einen "halben".

Das sollte aber alles viel genauer beschrieben sein in einem rfc oder sonstigem dokument zu deinem handy.

Edit: Wenn du soetwas "\r\nAT\r\n" bekommst dann funktioniert das genauso wie oben beschrieben. dann bekommst du halt 2 befehle: einmal "\r\n" und einmal "AT\r\n". Ich kenn zwar weder dein handy noch dein protokoll aber vielleicht kommst du damit wenn du das einfach als einen leeren befehl interpretierst.

ja... protokoll is gut. da gitbs in dem sinn kein protokoll. das is eben einfach ein virtueller COM port wo daten in einem buffer ankommen/gesendet werden.

Was ich mit dem "\r\nAT\r\nOK\r\n" beispiel meinte:
Es ist nämlich gard eben nicht "\r\nAt\r\n" eine antwort und die andere"OK\r\n" sondern dass gehört zusammen. und wenn cih nach \r\n parse dann wird diese antwort eben nicht erkannt sondern in 2 teilen.

So far,

Gabba Wally

ach ja: hab ein K700i von sony ericsson und hab mir schon einige PDFs von den devoloper seiten von SE runtergeladen. aber da findet man auch nciht viel mehr außer eben paar hundert seiten solcher AT befehle für SE handys.

Wo ist eigentlich Dein Problem?

Die Zeichenfolge \r\n ist 'eh nutzlos und dient nur zum Trennen der Befehle. Wieviele davon davor und dahinter sind, spielt doch für die Kommandos überhaupt keine Rolle.
Wenn ich das richtig verstanden habe, ist es doch so:

Ein Kommando vom Handy:
\r\nATx\r\n
Zwei aufeinanderfolgende (oder schnell getippte) Kommandos:
\r\nATx\r\nATy\r\n

Im ersten Fall ist ATx das Kommando und im zweiten Fall sind es ATx und ATy.

Blackbird

nein...es kommt nicht immer \r\nATx\r\n an! es kann z.b. auch was ganz anderes ankommen, abhängig davon was ich zum handy schicke. "AT" kommt eigentlich nur vor wenn ich "At\r" hinschicke

junix

Aber es kommt immer xx\r\n Deshlab baust du dir nen Empfangs-Automaten:

(Initial-)State 1:
Auf daten Warten
Ausgangstransitionen:
Byte empfangen -> State 2
Programmende -> State end

State 2:
Byte entgegen nehmen und in Puffer ablegen.
Das byte prüfen
Ausgangstransitionen:
byte == \r -> State 3
byte != \r -> State 2
Programmende -> State end

State 3:
Byte entgegen nehmen und in Puffer ablegen.
Das byte prüfen
Ausgangstransitionen:
byte == \n -> State 4
byte != \n -> State error
Programmende -> State end

State 4:
Empfang eines kompletten Befehls signalisieren; Sprung auf State 1

State error:
Fehler bekannt machen. Sprung auf State 1

State end:
Aufräumen.

Ich hoffe es ist so nachvollziehbar was ich meine.