AT Kommandos

Die Meldung “Achtung! Aufgepasst!”, oder englisch “Attention!” leitete in der guten alten Modem-Zeit eine Kommando-Sequenz ein.

Diese ATtention Kommandos waren einfache Textzeilen, die immer mit AT eingeleitete wurden um etwas abzufragen oder etwas auszulösen.

Die alten Telefonmodems, für welche dieses Protokoll erfunden wurde, stehen heute nur noch im Museum, doch AT-Kommandos erfreuen sich weiter einer großen Beliebtheit in ganz anderen Gebieten der Technik.

Von ihrem Aufbau her, bin ich kein Freund von AT-Kommandos in modernen Anwendungen. Sie wurden - ähnlich wie HTTP - so gewählt, dass Menschen sie zur Not auch manuell in Terminals eintippen konnten und sind daher der menschlichen Sprache nachempfunden.

Für jede Abfrage gibt es “einfach so” eine Antwort. Das hört sich leicht und verständlich an, ist aber - wie bei uns Menschen auch - recht fehleranfällig.

Alles läuft nach folgendem Schema ab:

Kommando:

ATmachwas mit X

Antwort:

X ist fertig
OK

Oder im Fehlerfall lautet die Antwort einfach:

ERROR

Schon bei der Frage, wie der Zeilenwechsel aussieht, wird es zwischen Implementierungen schwammig, weil einige CR+LF als Zeilenende anerkennen, während anderen nur mit einem alleinigen LF umgehen können.

Noch schlimmer wird es, wenn man mehrere Anfragen abschickt.
Es gibt keine IDs die Antworten mit Anfragen verknüpfen können, und so ist auch hier fraglich, ob man z.B. auf zwei parallele Anfragen nur die erste, nur die zweite oder beide beantwortet bekommt.

Und da AT Kommandos häufig über serielle Verbindungen geschleust werden, kann auch schnell mal ein Byte verloren gehen. Das ist dann eben Pech und der Parser auf der Gegenseite darf entweder sehr kreativ reagieren oder die Anfrage ignorieren. Eine standardisierte Fehlerkontrolle gibt es hierfür leider nicht.

AT Kommandos haben aber den Vorteil, dass sie besonders in C leicht implementiert werden können. Viele Codeumsetzungen kommen mit printf(), scanf() und strcmp() aus und das erklärt, warum dieses uralte Protokoll-Skelett schon so viele Jahre lebt und überlebt hat.

Doch welche Kommandos verfügbar sind, ist und bleibt Hersteller- und anwendungsspezifisch.
Denn heute finden wir AT-Kommandos in vielen Geräten, die Kommunikationsflüsse verwalten und steuern sollen. Von LTE und UMTS Sticks, über WLAN- und Bluetooth Chips bis hin zu GPS oder GSM Empfängern.

Die Kommandos sind dabei entweder die primäre Schnittstelle um mit dem Gerät zu interagieren, oder aber eine separate Verwaltungsschnittstelle um Parameter des eigentlichen primären Protokolls anzupassen.

Beispiele

• Mein USB UMTS Stick meldet sich mit 2 COM-Ports. Einer simuliert eine alte Modem-Schnittstelle, wo über AT-Kommandos eingewählt und aufgelegt werden kann. Ein weitere Port erlaubt separate Verwaltungs-AT-Kommandos.
• Für den ESP8266 und seine Nachfolger gibt es eigente AT-Firmwares, die gerne mit Arduino Projekten genutzt werden. Der Arduino steuert über AT-Kommandos den Aufbau von WLAN-Verbindungen und sogar einfache Socket-Verbindungen.
• Bluetooth Chips für MCU-Projekte nutzen ebenso AT-basierte Befehle um Daten an verbundene Geräte zu übertragen oder von diesen Daten zu lesen.
• GSM/GPRS Module werden ebenfalls mit AT-Firmwares geliefert um Funktionen wie SMS-Versand oder Internetkommunikation zu initiieren.
• Und auch für diverse Mikrocontroller existieren AT-Subkommandos um z.B. ihre PINs zu verwalten.

Fazit

Das Senden von AT-Kommandos und das Parsen der Antworten gehört also weiterhin zu meinen Aufgaben. Einerseits in privaten MCU-Bastelleien, aber andererseits auch zur Ansteuerung anderer Geräte über IoT Brücken.

Lieber wären mir binäre Protokolle, die mit eindeutigen IDs und standardisierten Headern arbeiten, anstatt aus Textantworten Zustände deuten zu müssen.

Doch andererseits ist dieses Schema lange bewährt und - wie gesagt - einfach und relativ platz- bzw. codesparend umzusetzen.

Und dass dabei ein bisschen Retro-Feeling aufkommt, wenn ich die heutige Highspeed Internetverbindung mit den gleichen Kommandos aufbauen kann, wie damals mit einem 56K Modem, darf man ja auch nicht gering schätzen …