Forum: Mikrocontroller und Digitale Elektronik AT-Kommandos auswerten


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Thomas T. (runout)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Zusammen,

ich möchte ein 4G-Modem (u-blox sara-r4xx) in Betrieb nehmen.
Das Target spielt eigentlich keine Rolle.
Es geht um die Auswertung der Resultcodes auf eine AT-Kommando.

Die Antwort auf eine AT-Kommando kann sehr unterschiedlich sein
und nicht nur "OK"'CRLF'...

Ich weis also nicht wenn der Resultcode "fertig" ist.
Muss ich immer, Byte für Byte, parsen wenn ich den Resultcode empfange?

Wäre es auch möglich, die Rückantwort pauschal in einen
Timeout reinrauschen zu lassen und nach dem Timeout den Resultcode 
auszuwerten.
Könnte die Performance etwas ausbremsen aber das ist an der Stelle nicht 
wichtig.

Sorry für die triviale Frage aber AT-Befehle sind irgendwie
etwas "Altwelt"...

Grüße
Runout

von Lothar M. (lkmiller) (Moderator) Benutzerseite


Bewertung
2 lesenswert
nicht lesenswert
Thomas T. schrieb:
> Wäre es auch möglich, die Rückantwort pauschal in einen
> Timeout reinrauschen zu lassen und nach dem Timeout den Resultcode
> auszuwerten.
Diesen Holzhammer würde ich nur als Sicherungsleine verwenden.

> Die Antwort auf eine AT-Kommando kann sehr unterschiedlich sein
> und nicht nur "OK"'CRLF'...
Aber der Anfang und der Abschluss ist immer CRLF. Siehe in den 
Versionen jeweils den Abschnitt 4.2:
https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=1515

Ich würde also einen Ringpuffer füllen. Wenn ich dann bei einem LF 4 
Bytes rückwärts schaue und da kein LF ist, dann habe ich das Ende einer 
Antwort bekommen.

: Bearbeitet durch Moderator
von Blockwart (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Thomas T. schrieb:
> Sorry für die triviale Frage aber AT-Befehle sind irgendwie
> etwas "Altwelt"...

Das hat überhaupt nichts mit Altwelt, Legacy, Vermächtnis oder was auch 
immer zu tun. Die AT-Befehle sind ein (oder quasi DER Standard) für die 
Kommunikation zwischen "Datenendgeräten" egal auf welcher Plattform.

Zu deinem Problem. Schaue doch einfach in das Datenblatt vom Modem, da 
steht drin, wie die Daten übertragen werden. Entweder kommt zum Schluss 
ein CRLF, es sind definierte Paketlängen oder es wird bei Beginn der 
Übertragung mitgeteilt, wie viele Bytes übertragen werden.

Ein Time-Out sollte immer Pflicht sein, um unterbrochene Übertragungen 
zu erkennen, aber nie als die Standardlösung zum Erkennen von EOT.

von Theor (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Thomas T. schrieb:
> [...]
> Es geht um die Auswertung der Resultcodes auf eine AT-Kommando.

Mit welcher Absicht? Willst Du, wie Dein nachfolgender Text mir 
suggeriert,  nur feststellen, ob die Antwort vollständig ist?

> Die Antwort auf eine AT-Kommando kann sehr unterschiedlich sein
> und nicht nur "OK"'CRLF'...
>
> Ich weis also nicht wenn der Resultcode "fertig" ist.

Ich würde an Deiner Stelle, vollständig ermitteln, welches die möglichen 
Antworten sind. Das bedeutet nicht zwangsweise, dass Du sie vollständig 
parsen musst. Aber ich halte es für sinnvoll, alle Varianten wenigstens 
zu kennen. (Ich kann mich gerade nicht erinnern, aber ich meine am Ende 
kommt immer ein CR, LF, oder CR+LF).

> Muss ich immer, Byte für Byte, parsen wenn ich den Resultcode empfange?

Nein.

> Wäre es auch möglich, die Rückantwort pauschal in einen
> Timeout reinrauschen zu lassen und nach dem Timeout den Resultcode
> auszuwerten.

Letztlich ist das gehupft wie gesprungen. Wesentlich ist, dass Du das 
(bis auf pathologische Fälle) vollständig deterministische Verhalten 
nutzt, um eine vollständig deterministische Auswertung zu machen.

> [...]

von Stefan ⛄ F. (stefanus)


Bewertung
0 lesenswert
nicht lesenswert
ich mache meine "Kommunikations-Funktion" immer so, dass sie ein 
Kommando sendet und dann auf ein bestimmtes Schlüsselwort mit Timeout 
wartet. Wenn das Schlüsselwort empfangen wurde, wird noch etwas länger 
empfangen, bis für eine gewisse Zeit (z.B 50ms) nichts mehr weiter 
kommt.

Das Schlüsselwort ist meistens "OK" und als Timeout verwende ich einen 
zum Befehl passenden Wert. Manche brauchen ja länger als andere.

So läuft die Kommunikation im guten Fall schnell ab und ist im 
Fehlerfall dennoch stabil.

von Thomas T. (runout)


Bewertung
0 lesenswert
nicht lesenswert
Hallo Zusammen,

Lothars-Vorschlag wird es werden... (+ Timeout obendrauf)

Das CR/LF detektieren und dann "rückwärts schauen"...

Die Resultcodes sind wie folgt definiert:
"OK" 0 Final Command line successfully processed and the command is..
"CONNECT" 1 Intermediate Data connection established
"RING" 2 Unsolicited Incoming call signal from the network
"NO CARRIER" 3 Final Connection terminated from the remote part...
"ERROR" 4 Final General failure.The AT + CMEE command..
"NO DIALTONE" 6 Final No dialtone detected
"BUSY" 7 Final Engaged signal detected(the called number is busy)
"NO ANSWER" 8 Final No hang up detected after a fixed network timeout
"NOT SUPPORT" 10 Final Operation not supported
"INVALID COMMAND LINE" 11 Final Invalid command line
"CR" 12 Final Carriage return
"SIM DROP" 13 Final SIM not inserted
"Command aborted" 3000 Final Command execution aborted issuing a 
character..
"DISCONNECT" 14 Final Data connection disconnected

Viele Grüße

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.