Fernwirken mit GSM Master ET - Versuch 752
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Interdisziplinäres Laborpraktikum
Master ET
Versuch 752
Fernwirken mit GSM
Institut für Zuverlässiges Rechnen
Technische Universität Hamburg-Harburg, 2009
Stand: 22. Mai 2012, D. Baack et al.INHALTSVERZEICHNIS 1
Inhaltsverzeichnis
1 Beschreibung des Versuchsziels und -inhalts 1
2 Beschreibung der verwendeten Hardware 2
2.1 Beschreibung der Hardwareumgebung . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2 Der Kontakt zum GSM-Netz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3 Kommunikationsprotokolle 5
3.1 Allgemeine Protokollprinzipien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Punkt-zu-Punkt Verbindungen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.3 Beispiel Garagentor-Steuerung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4 Software-Diagramme und Beschreibung der Funktionen 11
4.1 GSM und SMS-Kommunikation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5 Anmerkungen zur Versuchsdurchführung 19
5.1 Quellcode kompilieren und den Mikrocontroller beschreiben . . . . . . . . . . . . . . . 19
5.2 Kurzeinführung Oszilloskop . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6 Aufgaben 20
1 Beschreibung des Versuchsziels und -inhalts
Der in dieser Anleitung beschriebene Versuch soll verdeutlichen, dass sich schon mit recht einfachen
Mitteln zuverlässige, kostengünstige, flexible und sinnvoll einsetzbare Systeme zur Fernwartung bzw.
Fernsteuerung erstellen lassen.
Zu diesem Zweck wird das bereits flächendeckend verfügbare GSM1 -Netz genutzt, um Steueranwei-
sungen mittels SMS2 an ein Empfangsgerät zu verschicken. Im vorliegenden Versuch beschränkt sich
die Steuerung auf das An- und Ausschalten von Leuchtdioden bzw. auf das Drücken von Tastern als
Eingangssignale. Dennoch liegt es nahe, dass diese Bausteine problemlos durch andere ersetzt werden
können. Statt einfacher Leuchtdioden können z.B. Lichtanlagen kontrolliert und elektrische Geräte
gesteuert werden. Zudem kann auf Änderungen an den Eingängen in vielfältiger Weise reagiert wer-
den. Von einfachen Garagentorsteuerungen mit Rückmeldungen bis zu Alarmanlagen, die per SMS
einen Einbruch melden, ist das System universell einsetzbar. Aufgrund der Nutzung der verfügbaren
GSM-Infrastruktur kann auf das System nahezu von jedem Ort aus zugegriffen werden. Darüber hin-
aus sollen in diesem Versuch grundlegende Protokollmechanismen wie z.B. Bestätigen des Empfangs,
Rückmeldung bei (Syntax-)Fehlern, Senden von Zustandsinformationen usw. angewandt und selbst
entwickelt werden. Es soll dabei mit der Programmiersprache C auf einer hohen sprachlichen Ebene
1
Global System for Mobile communication
2
Short Message Service2 Beschreibung der verwendeten Hardware 2
gearbeitet werden, ohne sich intensiv mit der zugrunde liegenden Hardware und deren Realisierung
auseinandersetzen zu müssen.
Es liegt in diesem Versuch eine Hard-/Softwareumgebung vor, die mit entsprechender Softwareim-
plementierung imstande ist, Steueranweisungen per SMS zu empfangen und auszuführen, Zustands-
und Erfolgsmeldungen zu versenden sowie auf fehlerhafte Anweisungen angemessen zu reagieren.
In diesem Versuch sollen Sie in ein bereits bestehendes Programm, wel-
ches den Mikrocontroller steuert, modifizieren. Dafür benötigen Sie le-
diglich grundlegende Kentnisse in C.
2 Beschreibung der verwendeten Hardware
Die zentrale Steuerung und Verwaltung aller Komponenten übernimmt ein RISC-Mikrocontroller der
Firma ATMEL. Zum Einsatz kommt hier das Modell atmega32. Dieser übernimmt die Ansteuerung
der externen Komponenten (LED, LC-Display, Eingänge), die Kommunikation mit dem GSM-Modul
MC35 der Firma Siemens sowie die Auswertung und Ausführung der nötigen Operationen für den SMS-
Versand und SMS-Empfang. Der Mikrocontroller stellt ebenfalls die nötige UART-Schnittstelle zur
Kommunikation mit dem GSM-Modul zur Verfügung. Die notwendige Pegelanpassung zwischen dem
5V TTL-Pegel des Mikrocontrollers und der 12V-Spannung der RS232-Schnittstelle des GSM-Moduls
übernimmt ein externer MAX232-Baustein. Die weiteren Bauteile entsprechen der Standardbeschal-
tung der atmega-Baureihe und dienen der Stromversorgung, der Takterzeugung und der Beschaltung
der Ein- und Ausgänge. Sie sind jedoch nicht Bestandteil dieses Versuches und sollen daher nur kurz
aufgezeigt werden. Für Interessierte liegt dieser Anleitung zusätzlich der Schaltplan der Hardwareum-
gebung bei (bei Praktikumsbeginn).
2.1 Beschreibung der Hardwareumgebung
Der ausgewählte Controller atmega32 besitzt alle für die Umsetzung der geplanten Hardware not-
wendigen Eigenschaften. Der mit maximal 16 MHz taktbare atmega32 ist ein Modell der mittleren
Leistungsklasse in der atmega-Modellreihe. Die Unterschiede zu den anderen Modellen dieser Reihe
liegen in erster Linie im vorhandenen Speicher für die Programme und Daten sowie in einigen Ex-
trafunktionen. Die maximale Taktfrequenz liegt bei allen Modellen bei 16 MHz. Der 32 KByte große
Programmspeicher (der „Flash“) des atmega32 nimmt den eigentlichen Maschinencode inklusive kon-
stanter Daten auf, während der 2048 Byte große Datenspeicher (das „SRAM“) bei der Speicherung von
dynamischen Variablen zum Einsatz kommt. Die folgenden, wichtigen Eigenschaften charakterisieren
den atmega32:
Hochleistungs-8-bit Mikrocontroller (RISC-Architektur) mit:
• 131 Befehlen – davon viele mit nur 1 Takt • 32 x 8 flexibel nutzbare Register
Ausführungszeit
• Bis zu 16 MIPS Datendurchsatz bei 16 MHz2.2 Der Kontakt zum GSM-Netz 3
• On-chip 2-Zyklus Multiplizierer • 1024 Bytes EEPROM, bis zu 100.000 Mal
wiederbeschreibbar
• 32 KByte frei programmierbarer Flash-
RAM, bis zu 10.000 Mal wiederbeschreibbar
• In-System Programming • 2 KByte internes SRAM
Peripherie und I/O-Eigenschaften
• Zwei unabhängige 8-bit Timer/Zähler • Serieller UART (5V TTL)
• Ein 16-bit Timer/Zähler
• 32 unabhängige I/O Pins
• Echtzeitzähler
• Externe und interne Interruptquellen
• 8-Kanal 10-bit Analog-Digital-Wandler
• Two-wire Serial Interface (I2C) • Interner Taktgenerator
Betriebsspannungen Taktung
• 4,5 – 5,5V • 0 - 16 MHz
Leistungsaufnahme bei 1MHz, 3V, 25◦ C
• Aktiv : 1,1 mA • Idle Mode: 0,35 mA
Der gewählte Mikroprozessor wurde um die notwendige externe Beschaltung erweitert. Dazu zählen
die Stromversorgung, der externe Takt, die externen Interrupts, der Anschluss der ISP, der Anschluss
der Leuchtdioden, der Anschluss des LCD und die Beschaltung der UART Schnittstelle.
2.2 Der Kontakt zum GSM-Netz
Das kompakte Modul MC35i der Firma Siemens bietet ein vollwertiges GSM-Endgerät inkl. aller
Funktionen für den digitalen Datenverkehr im GSM-Netz. Da es nicht für den direkten, eigenständigen
Einsatz gedacht ist, fehlen - im Gegensatz zu einem „echten“ Mobiltelefon - Tastatur, Display, Laut-
sprecher und Mikrofon. Die Kommunikation mit dem Modul erfolgt wie bei jedem handelsüblichen
Handy über eine serielle Schnittstelle.
Als Informations- und Debuggingmöglichkeit steht noch ein zweizeiliges Standard- LC-Display der
Firma Batron, hier Modell LCD162c, zur Verfügung, welches mit dem Mikrocontroller zur Ausgabe
von Daten genutzt werden kann.2.2 Der Kontakt zum GSM-Netz 4
LC-Display
Tor2 Tor1
Tor2 GSM-Netz
IO-Ports
UART
Tor1
Tuer
Garage RS-232
ATMEL ATmega32
Treiber
Alarm
Fenster SUB-D GSM-Modem
9-polig
ISP
Kaffee Siemens MC35
Heizung
GND Reset Programmier-
VCC buchse
Abbildung 1: Versuchsaufbau
Dies ist kein Hardware- sondern ein Softwareversuch. Machen Sie sich
dennoch klar, welche Rolle die Hardware hier auch für ihr Programmie-
ren spielt. Ihr C-Programm wird nach dem Kompilieren auf den Mi-
krocontroller übertragen. Der Mikrocontroller wiederum ist per serieller
Schnittstelle mit dem GSM- Modul (versteht nur AT-Befehle) verbun-
den, welches als Sende- und Emfangsstation der SMS dient (siehe Abb.
1). Es treten also mehrere Schnittstellen mit unterschiedlichen Sprachen
auf: Schnittstelle Student zu PC (Student spricht C und Compiler über-
setzt für PC in Maschinensprache) sowie Schnittstelle PC zu Mikrocon-
troller (von Maschinensprache zu AT-Befehlen)3 Kommunikationsprotokolle 5
3 Kommunikationsprotokolle
3.1 Allgemeine Protokollprinzipien
Die allgemeine Bedeutung des Wortes Protokoll wird in der Regel mit einer Verhaltensvorschrift gleich-
gesetzt. Sich beispielsweise bei einem offiziellen Empfang „an das Protokoll zu halten“ bedeutet, nicht
vom vorher genau festgelegten Weg und Ablauf abzuweichen. Diese Bedeutung gilt auch, wenn wir von
Kommunikationsprotokollen sprechen. Allen Kommunikationspartnern, seien es nun nur zwei (bei einer
direkten Punkt-zu-Punkt Kommunikation nach dem seriellen RS232-Standard) oder mehrere Partner
(z.B. bei Bussystemen wie Ethernet oder USB) sind diese Protokollvorschriften bekannt. Es wird sich
strikt an diese Vorschriften gehalten und es wird vorausgesetzt, dass sich auch alle anderen Teilneh-
mer ebenfalls exakt nach diesen Vorschriften verhalten. Nur so ist zu gewährleisten, dass sich jedes
System zu jeder Zeit in einem klar definierten Zustand befindet, den es nur bei Eintreten vorher ein-
deutig definierter Ereignisse ändern kann. Diese Eigenschaft ist nicht nur bei der Kommunikation von
entscheidender Bedeutung. Jedes Computersystem kann nur funktionieren, wenn es nach einem Zu-
standsdiagramm abläuft. „Entweder-Oder-Zustände“ sind darin ebenso ausgeschlossen wie willkürliche
und nicht reproduzierbare Zustandsänderungen.
3.2 Punkt-zu-Punkt Verbindungen
Bei einfacher Punkt-zu-Punkt Kommunikation, z.B. bei der seriellen RS232, gibt es in der Regel vier
relevante Zustände sowie drei wichtige Ereignisse nach denen sich Zustände ändern können.
Beispiele für Zustände:
Senden, Warten bzw. Ruhezustand, Empfangen, Bestätigen der empfangenen Daten.
Beispiele für Ereignisse:
Daten zum Versand vorhanden, Daten zum Empfang vorhanden und Bestätigung des Empfangs
erhalten.
Das einfache Zustandsdiagramm einer Kommunikationseinheit, sowohl für den Sender als auch für
den Empfänger, stellt sich daher wie folgt dar (s. Abb. 2).
Dieser Ablauf gilt grundsätzlich für alle Punkt-zu-Punkt Verbindungen, die eine gesicherte Über-
tragung benötigen. Gesichert bedeutet hier, dass sichergestellt wird, dass die Gegenstelle alle Daten
erhalten hat. Von großer Bedeutung ist bei der gesicherten Kommunikation das Timeout-Ereignis. Es
wird dabei nach Absenden der Daten eine vorher genau festgelegte Zeit, die Timeout-Dauer Tt , auf
das Eintreffen der Empfangsbestätigung, das sogenannte „Acknowledge“ („ACK“), gewartet. Erhält die
Sendeeinheit nach Ablauf dieser Zeit keine Empfangsbestätigung, gilt der Sendevorgang als gescheitert.
Nun ist es abhängig vom verwendeten System, ob die nicht bestätigten Daten erneut gesendet werden
oder ob der komplette Sendevorgang beendet wird. Am Beispiel der Garagentor-Steuerung wird die
Timeout-Systematik in Punkt 3.4 genauer betrachtet.
Um den Ablauf einer Kommunikation und die Relation zwischen Sender und Empfänger darzu-
stellen, kommt ein so genanntes „Weg-Zeit-Diagramm“ zum Einsatz, in welchem sowohl der zeitliche
als auch der örtliche Ablauf einer Übertragung verdeutlicht werden kann. Der normale Vorgang einer3.2 Punkt-zu-Punkt Verbindungen 6
Abbildung 2: Einfaches Zustandsdiagramm einer Sende- und Empfangseinheit
gesicherten Punkt-zu-Punkt Kommunikation wird mit folgendem Diagramm dargestellt (s. Abb. 3).
Auf der linken Seite befindet sich der Sender, in der Mitte die Übertragungsstrecke z.B. bestehend
aus direkter Kabelverbindung, Internet oder GSM-Netz, während auf der rechten Seite der Empfänger
dargestellt ist. Der zeitliche Ablauf der Kommunikation liest sich nun von oben nach unten.
Zum Zeitpunkt (1) werden die Daten vom Sender über den Übertragungsweg an den Empfänger
verschickt, wo sie nach der Zeit T2 eintreffen ⇒ Punkt (2). Nach dem Empfang der Daten sendet der
Empfänger nach Ablauf der Zeit T3 die Empfangsbestätigung ⇒ Punkt (3), die dann die Zeitdauer T4
benötigt, um beim Sender einzugehen ⇒ Punkt (4). Aus der Sicht des Senders hat der gesamte Vorgang
nun die Zeit T1 benötigt. Die Zeitdauer vom Senden der Daten bis zum Empfang der Bestätigung muss
stets innerhalb der vorgegebenen Zeitdauer Tt (Timeout) liegen. Trifft die Bestätigung nicht innerhalb
der Zeit Tt beim Sender ein, so ist der Sendevorgang gescheitert. In diesem Fall wird in der Regel
der Versand wiederholt und bei weiterem Ausbleiben der Bestätigung abgebrochen. Die nachfolgenden
Beispiele erläutern einige Gründe für das Ausbleiben der „ACK“-Information (s. Abb. 4).
Tritt dieser Fall auf, so haben die Daten den Empfänger nie erreicht. Da der Empfänger keine
Daten erhalten hat, wird er auch kein „ACK“ senden und der Sender wird den Empfang der Daten
nicht bestätigt bekommen. Innerhalb der Timeoutzeit Tt wird also kein „ACK“ eintreffen und der
Sender sendet die Daten erneut (s. Abb. 5).
In diesem Beispiel haben die Daten zwar den Empfänger erreicht, jedoch ging die daraufhin ver-
schickte Bestätigung verloren. Folglich erhält der Sender innerhalb der vorgeschriebenen Zeit keine
Bestätigung und wiederholt die Datenübertragung. Diese Daten müssen vom Empfänger erneut bestä-3.2 Punkt-zu-Punkt Verbindungen 7
Abbildung 3: Weg-Zeit-Diagramm einer erfolgreichen und gesicherten Übertragung
Abbildung 4: Verlust der Sendedaten bei der Übertragung zum Empfänger3.3 Beispiel Garagentor-Steuerung 8
Abbildung 5: Verlust der Bestätigung bei der Übertragung zum Sender
tigt werden. Der geschilderte Ablauf gilt grundsätzlich für alle Punkt-zu-Punkt Verbindungen, die eine
gesicherte Übertragung benötigen.
3.3 Beispiel Garagentor-Steuerung
Im Folgenden sollen die Punkt-zu-Punkt-Verbindung und die dort auftretenden Ereignisse und Zu-
stände am Beispiel einer Garagentor-Steuerung erläutert werden. Dieses Beispiel soll mit Hilfe der
vorliegenden Versuchsumgebung nachvollzogen werden.
Im Beispiel Garagentor-Steuerung werden der Antriebsmotor durch eine Leuchtdiode und der
Schließkontakt durch einen Taster ersetzt (s. Abb. 6).
Vom Mobiltelefon wird eine SMS gesendet mit der Anweisung, das Garagentor an Port 5 zu schlie-
ßen. Das Signal wird über das GSM-Modul an den Mikrocontroller weitergeleitet. Daraufhin wird der
an Port 5 angeschlossene Motor (LED) aktiviert, um das Tor zu schließen. Ist das Tor geschlossen (LED
erlischt) wird der Schließkontakt geschlossen (manuelle Betätigung des Tasters an Port 7). Durch die
Schließung wird per SMS die Nachricht (ACK) an das Mobiltelefon des Absenders verschickt, dass das
Garagentor nun geschlossen ist.
Bleibt dieses Signal aus (Taster wird nicht betätigt), erhält der Absender nach Ablauf einer be-
stimmten Zeit (Timeout) die Nachricht, dass das Tor nicht geschlossen wurde. Gründe hierfür könnten
sein, dass der Mikrocontroller das Signal zum Schließen nicht erhalten hat oder etwas das Garagentor
blockiert.3.3 Beispiel Garagentor-Steuerung 9
Abbildung 6: Simulation der Garagentorkomponente
Dieses Beispiel beinhaltet zwei unabhängige, nacheinander genutzte Übertragungsstrecken: Die Da-
tenübertragung vom Mobiltelefon zum Mikrocontroller erfolgt ohne Empfangsbestätigung über das
GSM-Netz. Der Empfang wird erst bei vollständiger Ausführung der Anweisung vom Mikrocontrol-
ler durch SMS bestätigt. Die gesicherte Übertragung findet zwischen Mikrocontroller und Garagen-
tor/LED statt: Das Signal (Schließen des Tors) wird umgesetzt, und das Schließen des Kontaktes an
Port 7 bestätigt dem Mikrocontroller den Erfolg (ACK). Hier erfolgt die Sicherung durch ein Timeout.
Die Zeit, die die Daten bzw. die Signale vom Sender zum Empfänger benötigen, wird in der Über-
tragungstechnik als „Propagation Delay“ (= Ausbreitungsverzögerung) bezeichnet. Bei einer Kabelver-
bindung wird diese Verzögerung durch die Ausbreitungsgeschwindigkeit des elektrischen Signals und
durch die Länge und Beschaffenheit des Verbindungskabels definiert. Je länger die Verbindung, gleich
ob optisch oder elektrisch, desto größer ist die Laufzeit der Daten, gleichbedeutend mit der Erhöhung
des Propagation Delays. Diese Verzögerungen sind in der Regel bei elektrischen Signalen recht gering,
müssen aber bei jeder Planung einer Datenübertragung entsprechend berücksichtigt werden. Im Fall
der Auslieferung einer SMS über das GSM-Netz kann diese Verzögerung jedoch bekanntermaßen einige
Sekunden bis Minuten dauern. Nach dem Absenden der Daten wartet der Sender (Mobiltelefon) auf
das Eintreffen der SMS mit dem Ergebnis der Ausführung.
Nachdem die Daten (SMS) den Empfänger (GSM-Modul/Mikrocontrollersystem) erreicht haben,
wird die SMS ausgewertet und der Impuls zum Schließen des Tores an den Motor der Torsteuerung
gesendet. Nun hat das Tor eine definierte Zeit (Timeout) zum Schließen zur Verfügung. Das erfolgreiche
Schließen des Tores wird durch den Kontaktschalter signalisiert. Bleibt diese Bestätigung innerhalb des
Timeout-Fensters aus, gilt die Übertragung/Anweisung als nicht fehlerfrei ausgeführt. Diese Informa-
tion wird dann dem Auftraggeber (Mobiltelefon) mitgeteilt (s. Abb. 7).
Der Nutzer sendet mit seinem Mobiltelefon eine entsprechende SMS „Garage:an“ 3 mit der Anwei-
3
„Garage:an“ bedeutet hier das Schließen des Tores. Im Gegensatz dazu wird „Garage:aus“ als Öffnen des Tores
interpretiert. Diese Umsetzung müsste dann der in der Realität angeschlossene Torantrieb durchführen.3.3 Beispiel Garagentor-Steuerung 10
Abbildung 7: Weg-Zeit-Diagramm einer SMS-Steuerung inkl. Bestätigung
sung, das angeschlossene Garagentor zu schließen (1). Nachdem die SMS ihren Weg über das GSM-Netz
zum SMS-Steuermodul gefunden hat und dort ausgewertet wurde, gibt das Steuermodul das Signal an
den Motor der Garagentorsteuerung, das Tor zu schließen (2). Von diesem Zeitpunkt an beginnt im
Steuerungsmodul der Timeout-Zähler Tt zu laufen. Wenn das Garagentor geschlossen ist, wird durch
das Schließen des Kontakts das Signal zum Steuerungsmodul gegeben, dass das Tor geschlossen ist.
Dann wird eine entsprechende SMS an das Mobiltelefon geschickt und die erfolgreiche Ausführung der
Anweisung „Garage:an" bestätigt. Der Timeout-Timer ist nicht mehr von Bedeutung.
Anders sieht dies aus, wenn die Information „Tor geschlossen“ nicht oder nicht rechtzeitig zum Steu-
ermodul gelangt. Nach Ablauf der Zeit Tt wird die Misserfolgsmeldung an das Mobiltelefon gesendet
(s. Abb. 8). Ein erneuter Schließversuch erfolgt nicht. Eine eventuelle Schließbestätigung, die nach dem
Ablauf der Zeit Tt das Steuermodul erreicht, wird ignoriert.
Die Verwaltung des Timeouts beim Schließen des Tores obliegt der Software, die auf dem Mikro-
controller läuft.4 Software-Diagramme und Beschreibung der Funktionen 11
Abbildung 8: SMS-Anweisung mit ausbleibender Bestätigung
Die leicht eingängigen Protokollprinzipien, die Sie in diesem Abschnitt
kennengelernt haben, lassen sich im Beispiel der Garagentorsteuerung
wiederfinden. Auf diesen Versuch angewendet, bedeutet dies für Sie, dass
Sie eine der LEDs auf dem Mikrocontroller per SMS steuern und eine
Nachricht über Erfolg oder Misserfolg dieses Steuerversuchs an den Steu-
ernden (das Mobiltelefon) zurücksenden. Dies tun Sie im Rahmen der
kennengelernten Protokollprinzipien (d.h. Sie müssen die Totzeit berück-
sichtigen). Das ACK, welches über Erfolg oder Misserfolg eines Steuer-
versuchs entscheidet (innerhalb von Totzeit oder später), wird von Ihnen
selbst per Taster ausgelöst (siehe Abb. 6).
4 Software-Diagramme und Beschreibung der Funktionen
Ein Hauptaugenmerk bei diesem Versuch soll auf der Softwareumsetzung liegen, auf die im Folgenden
näher eingegangen werden soll. Die Programmierung des Mikrocontrollers erfolgt mittels der Pro-
grammiersprache C sowie dem dafür erforderlichen C-Compiler für den Atmel Controller. Für die
Ansteuerung des LC-Displays, des GSM-Moduls und zur Verwaltung der Kommunikation mittels SMS4.1 GSM und SMS-Kommunikation 12
steht eine spezielle C-Bibliothek zur Verfügung. Die Möglichkeit, solche Funktionen zum Teil selbst zu
entwickeln, ist Bestandteil des Versuchs.
Die Funktionen sind im Folgenden als Schichtmodelle dargestellt. Diese Darstellungsweise verdeut-
licht, dass die abstrakten Funktionen, die bei der Nutzung dieser Software Verwendung finden, stets
auf einer der unterliegenden „hardwarenäheren“ Schicht geringerer abstrakter Funktionalität aufbauen.
Es handelt sich dabei um Funktionen, die für sich alleine genommen wenige Auswirkung besitzen, in
der Summe jedoch die Basis und Voraussetzung für abstraktere Funktionen wie das Versenden einer
SMS bilden.
Die nach außen hin simpel erscheinenden Funktionen werden dabei umso spezieller, je näher man
sich der Hardwareebene nähert. Das Versenden einer SMS ist keine triviale Aufgabe für den Mi-
krocontroller. Um diese komplexen Funktionen auf Anwenderebene aufzubauen, müssen alle dafür
notwendigen Unterfunktionen von der Hardwareebene aufwärts erstellt werden. Die Funktionen der
Treiberebene sind spezielle Funktionen für den eingesetzten Prozessor und greifen in der Regel direkt
auf dessen Register oder Ports zu.
Funktionen stellen die Schnittstellen zwischen dem Anwender bzw. Programmierer und der Maschi-
ne dar. Der Zugriff auf die Funktionalitäten des Microcontrollers erfolgt über abstrakte Schnittstellen.
Diese Schnittstellen kapseln die hardwarenahe Implementierung und vereinfachen den Zugriff für den
Programmierer.
Abbildung 9 zeigt die Aufspaltung der abstrakten Funktion send_sms, die als Parameter Empfän-
gerrufnummer X und SMS-Text Y entgegennimmt. Dieser Funktionsaufruf wird zunächst in eine Reihe
von AT-Befehlen aufgeteilt. Jeder dieser Befehle wird weiter in kleinere Unterfunktionen geteilt. Diese
Prozedur wiederholt sich für jeden Befehl erneut. Es ist ersichtlich, dass eine sehr große Anzahl von
einfachen Befehlen ausgeführt werden muss, um eine SMS mit dem Text X an die Handynummer Y zu
versenden.
Die in den nachfolgenden Gliederungspunkten dargestellten Funktionen und Strukturen stellt die
C-Bibliothek zur Verfügung4 .
4.1 GSM und SMS-Kommunikation
Basierend auf den Grundfunktionen der UART- und LCD-Library, wurden die Funktionen für die
GSM-Modul-Steuerung und die SMS-Verwaltung erstellt (s. Abb. 10). Auf eine Übersicht der Grund-
funktionen der UART- und LCD-Library wurde hier verzichtet, da sie für den Versuch nicht relevant
sind.
Neben den genannten Funktionen sind für den Datenaustausch mit dem GSM-Modul zwei globale
Datenstrukturen definiert.
4
Die genaue Syntax und Ansteuerung für alle dargelegten Funktionen sind dem Quellcode der Bibliothek selbst zu
entnehmen. Der Quellcode wird bei Praktikumsbeginn ausgehändigt.4.1 GSM und SMS-Kommunikation 13
Abbildung 9: Aufspaltung einer komplexen Aufgabe in einfache Basisfunktionen
Abbildung 10: Schichtmodell der seriellen GSM/SMS-Routinen4.1 GSM und SMS-Kommunikation 14
Abbildung 11: Die GSM-Datenstruktur
4.1.1 GSM-Befehls-Datenstruktur
Zur Steuerung von Modems bzw. anderer Datenendgeräte verwendet man den so genannten AT-
Befehlssatz. Dessen Befehle werden als einfacher ASCII-Klartext über die serielle Schnittstelle an das
Endgerät geschickt und lösen dort die entsprechenden Aktionen aus. Um beispielsweise ein Modem
(in diesem das GSM-Modul) zur Anwahl einer Telefonnummer zu bewegen, muss der Befehl „AT D
Rufnummer“ (D für Dial) an das Gerät geschickt werden. Um einen ankommenden Anruf entgegen zu
nehmen, ist der Befehl „AT A“ (A für Answer) an das Gerät zu senden5 .
Auf unbekannte Befehle antwortet das Gerät mit der Zeichenfolge „+ERROR“ auf gültige Befehle
mit einer befehlsabhängigen Antwort. Gültige Befehle werden dann auch stets mit einem „+OK“ als
Antwort abgeschlossen.
Eine Datenstruktur (s. Abb. 11) für die zur Steuerung des GSM-Moduls notwendigen AT-Befehle
liegt in der C-Bibliothek vor. Der gewünschte Befehl wird ins Datenfeld „Command“ geschrieben und
mit der Funktion send_gsm_command(0) abgeschickt. Anschließend findet sich im Feld „Answer“
der Antwortstring und im Feld „Success“ die Information, ob der Befehl erfolgreich (Success=true)
oder fehlerhaft (Success=false) abgearbeitet wurde. Die Datenstruktur ist in der Library unter dem
Variablennamen „gsm“ erreichbar.
Beispiel:
Folgender C-Programmcode verdeutlicht das Absenden eines AT-Befehls an das angeschlossene
GSM-Modul:
//***************************************
strcpy (gsm.command,“AT +cgmi“);
// Der Befehl „AT +cgmi“ wird in der Datenstruktur GSM ins
// Feld COMMAND eingetragen
// Mit dem Befehl „AT +cgmi“ wird die Herstellerkennung des
// angeschlossenen GSM-Gerätes abgefragt
send_gsm_command (0);
// Der Befehl wird abgesendet, auf Debug-Rückmeldungen wird
// verzichtet
5
Eine Übersicht über die wichtigsten AT-Befehle ist dem Anhang A zu entnehmen.4.1 GSM und SMS-Kommunikation 15
Abbildung 12: Die SMS-Datenstruktur
if (gsm.success)
{
lcd_textout (gsm.answer);
}
else
{
lcd_textout (“ Fehler“);
}
// Das Ergebnis, d.h. die Rückantwort des GSM-Moduls auf
// diesen Befehl, wird im Erfolgsfall auf dem Display
// ausgegeben. Andernfalls erscheint die Meldung „Fehler“.
**********************************//
4.1.2 SMS-Datenstruktur
Analog zur GSM-Befehlsdatenstruktur existiert ein Konstrukt zur Aufnahme einer SMS-Nachricht. Die
SMS-Datenstruktur (s. Abb. 12) enthält eine empfangene SMS bzw. die SMS, die versendet werden
soll. Zum Versenden einer SMS wird die Datenstruktur entsprechend mit den gewünschten Werten
beschrieben. Durch Aufruf der Funktion send_sms werden diese Daten dann in das SMS-Format
umgesetzt und verschickt.
Nach dem Aufruf der Funktion read_sms wird, sofern vorhanden, eine aktuelle SMS aus dem GSM-
Modul gelesen und die SMS-Datenstruktur entsprechend mit den Werten beschrieben. Es existiert also
nur eine Struktur, die sowohl eine ausgehende als auch eine eingegangene SMS enthält.
4.1.3 SMS-Versand & Empfang
Beispiel 1:
Folgender Programmcode verdeutlicht das Absenden einer SMS:
//***************************************4.1 GSM und SMS-Kommunikation 16
// Absenden einer SMS
//***************************************
strcpy (sms.to,“01734343434“);
strcpy (sms.text,“Hallo GSM-Welt“);
// Eintragen der relevanten Daten in die SMS-Datenstruktur
send_sms();
// Absenden der vorbereiteten SMS. Aus den SMS-Daten wird eine
// Reihe von GSM-Befehlen erzeugt, die nacheinander an das
// GSM-Gerät geschickt werden. Daher ist der Erfolgsfall auch
// wie bei jedem GSM-Kommando hier nun im Feld gsm.success
// gespeichert und kann abgefragt werden.
if (gsm.success)
{
lcd_textout (gsm.answer);
}
else
{
lcd_textout (“Fehler“);
}
// Das Ergebnis, d.h. die Rückantwort des GSM-Moduls auf
// diesen Befehl, wird im Erfolgsfall auf dem Display
// ausgegeben. Andernfalls erfolgt die Meldung „Fehler“.
**********************************//
Beispiel 2:
Folgender Programmcode verdeutlicht den Empfang und die Anzeige einer eingegangenen SMS:
//******************************
// SMS Empfang
//******************************+
read_sms();
// Auslesen der vorliegenden SMS
if (gsm.success)
{
// Liegt eine SMS vor, ist gsm.success gesetzt.
// Dann Ausgabe der SMS
lcd_textout (sms.from);
// Ausgabe des Absenders
lcd_line2();4.1 GSM und SMS-Kommunikation 17
// Zweite Zeile im Display
lcd_textout (sms.text);
//Ausgabe des Textes
delete_sms();
// Befehl zum Löschen der SMS. Ohne diesen Befehl
// würde diese SMS immer wieder ausgelesen.
}
else
{
lcd_textout(“Keine SMS vorhanden”);
// Keine neue SMS gefunden
}
4.1.4 SMS mit Funktion
Die Hard- und Softwareumgebung soll aber nicht nur den Text der SMS ausgeben können, sondern
in erster Linie der Steuerung angeschlossener Geräte dienen. Die SMS unterliegt wie jede Steuerungs-
anweisung bestimmten Regeln. Die Funktion liest den Inhalt der SMS aus und beschreibt damit die
Attribute der SMS-Datenstruktur.
Um den Zustand eines Ausgangs zu ändern, muss die SMS den Namen des Ausgangs, gefolgt von
einem Doppelpunkt und dem gewünschten Zustand, enthalten. Mehrere Anweisungen für verschiedene
Ausgänge können durch Leerzeichen getrennt angegeben werden. Jeder Ausgang des Systems kann mit
einem eindeutigen, leicht zu merkenden Namen versehen werden, mit dem der Ausgang angesprochen
werden kann. Es müssen sich keine Nummern oder Zuordnungen gemerkt werden, vergleichbar mit dem
Zusammenhang Domainnamen IP-Adresse im Internet. Diese Zuordnung findet sich zu Beginn
der C-Bibliothek und hat die Form:
=Portnummer
Betrachten Sie dazu auch Abb. 1. Als Ausgänge stehen die Ports 0-5 zur Verfügung. Die Ports 6
und 7 sind als Rückmeldeports reserviert und können nicht direkt angesprochen werden.
Der Text einer SMS, die also z.B. den Eingang: „Kaffee“ auf „1“ also auf „An“ schaltet, würde dann
lauten „Kaffee:an“. Sinnvollerweise könnte damit als Anwendung das Einschalten einer angeschlossenen
Kaffeemaschine erfolgen. Auf eine Unterscheidung zwischen Groß- und Kleinschreibung ist hierbei zu
achten. Mit dem Inhalt „Kaffee:aus Flur:aus“ könnte eine Kaffeemaschine an Port 0 sowie das Flurlicht
an Port 1 ausgeschaltet werden.
Die Ports 4 bzw. 5 besitzen eine besondere Eigenschaft. Diese Ports sind ebenso wie die Ausgänge
0-3 schaltbar, warten dabei jedoch auf eine Rückmeldung der korrespondierenden Eingänge 6 bzw. 7.
Das bedeutet, wenn der Ausgang 4 oder 5 per SMS-Anweisung geschaltet werden soll, ist ein entspre-
chender Zustand des Ports 6 oder 7 notwendig. Am Beispiel der Garagentorsteuerung entsteht eine
positive Rückmeldung (Garagentor ist geschlossen) bei geschlossenem Zustand des Schließkontaktes.4.1 GSM und SMS-Kommunikation 18
Die Eingangszustände an Port 6 und 7 sind in diesem Versuch mit zwei Tastern simuliert. Weitere
mögliche Anweisungen im SMS-Text :
„Text:“
Gibt den Text auf dem Display aus
„Status“
Gibt den Zustand aller 8 Ports zurück
Beispiel 3:
//******************************
// SMS Empfang und auswerten
//******************************+
read_sms();
// Auslesen der vorliegenden SMS
if (gsm.success)
{
parse_sms();
// Parsen , Analysieren und Auswerten des Inhalts
}
Nach dem Ausführen der Funktion parse enthält das Feld sms.typ nun die erkannte Art der SMS-
Steuerung. Folgende Typen stehen zur Verfügung:
• sms.typ=0;
Der SMS Text enthält keine auswertbaren Informationen. Entweder wurde die richtige Syntax
nicht beachtet oder die SMS enthält keine erkennbaren Befehle. In diesem Fall sollte an den
Absender der SMS eine entsprechende Rückantwort erfolgen. Der Absender der SMS steht nach
wie vor im Feld sms.from.
• sms.typ=1;
Die SMS enthält einen Befehl zum An- oder Ausschalten bestimmter Einfachports. Einfachports
sind die Ausgänge 0-3 und bedürfen keiner Rückmeldung. Da die SMS die Namen der Ausgänge
in Klartext enthält, müssen diese zunächst übersetzt werden. Diese Korrespondenztabelle findet
sich zu Beginn des Quellcodes der C-Bibliothek und ordnet jedem Ausgang ein leicht merkbares
Wort zu, mit welchem dann der Ausgang in der SMS benannt wird. Im Falle des SMS-Typs 1 hat
die Funktion parse dann den Inhalt des Feldes sms.text von der Form „Garage:an Kaffee:aus“ in
die Form „1:1 3:0“ umgewandelt (also in der Form Portnummer:Zustand). Die Funktion set_ports
kann nun anhand dieses so umkodierten Text-Strings die entsprechenden Ports auf „high“ bzw.
„low“ setzen.5 Anmerkungen zur Versuchsdurchführung 19
• sms.typ=2;
Dieser Typ bezeichnet SMS-Anweisungen, die lediglich Text auf dem LC-Display ausgeben sollen.
Der auszugebende Text befindet sich dabei im Feld sms.text.
• sms.typ=3;
Die SMS enthält Anweisungen zum Schalten der Ports mit Rückmeldung. In diesem Fall hat die
Funktion parse wie bereits beim SMS-Typ 1 den Inhalt des Felds sms.text in die Form „1:0 2:1
3:1. . . “ umgewandelt. Nun werden die Ports noch mit der Funktion set_ports entsprechend dieser
Anweisung geschaltet. Anschliessend ist aber noch die Abfrage der entsprechenden Rückmelde-
ports notwendig. Nur wenn der korrespondierende Rückmeldeport in der Totzeit den gleichen
Status angenommen hat wie der zu schaltende Ausgang, kann der Vorgang als erfolgreich abge-
schlossen betrachtet werden. Das heißt, wenn Ausgang Garage (Port 4) auf Schließen geschaltet
wird, ist bei dem entsprechenden Rückmeldeport 6 ebenfalls auf den Zustand Geschlossen zu
warten. Die hierfür gültige Timeout-Zeitdauer kann im C-Code festgelegt werden. Ports mit
Rückmeldung sind die Ausgänge 4 und 5. Die korrespondieren Rückmeldeports sind 6 und 7.
• sms.typ=4;
Hierbei handelt es sich um eine Status-SMS. Mit dieser SMS wird eine Statusmeldung angefordert.
Die Funktion create_status erzeugt dabei einen Textstring, in dem alle aktiven Ausgänge mit
Namen angegeben werden. Nicht geschaltete Ausgänge tauchen in diesem String nicht auf. Dieser
Text kann nun an den Anforderer der Statusmeldung geschickt werden.
Machen Sie sich mit den Datenstrukturen der Klassen GSM und SMS
vertraut (Methoden!). Ausserdem sollten Sie sich klar machen wie mit
den Funktionen strcpy(Ziel,Quelle); und strcat(Ziel,Quelle); umzugehen
ist und welche Datentypen ihre Parameter haben.
5 Anmerkungen zur Versuchsdurchführung
5.1 Quellcode kompilieren und den Mikrocontroller beschreiben
Die Quellcodedatei(en) werden mit dem zur Verfügung stehenden Editor „Programmers Notepad V2.0“
geladen. Achten Sie darauf, nicht die Dateinamen zu ändern, da sonst die vorgegebene Dateistruktur
nicht mehr gegeben ist. Laden Sie Ihre Quellcodedatei durch einen einfachen Dopelklick, unser Editor
wird normalerweise automatisch ausgewählt. Der Editor ist in der Lage, C-Strukturen zu erkennen
und visualisiert diese mit einer entsprechenden Farbgebung, so ist die Struktur des C-Quellcodes gut
erkennbar.
Speichern Sie ihren fertigen Quellcode ab und öffnen Sie nun ein Fenster mit dem Befehlsinterpreter.
Ein darauf verweisender shortcut steht zur Verfügung. Falls das nicht der Fall ist,gehen Sie auf „Start“5.2 Kurzeinführung Oszilloskop 20
-> „Ausführen“ und geben „command“ in das vorgesehene Feld ein. In der erscheinenden Eingabeauffor-
derung wechseln Sie ins richtige Verzeichnis und starten mit dem Befehl „make“ den Kompiliervorgang.
Ist dieser erfolgreich, so finden Sie im Verzeichnis nun eine Datei mit Namen „sms-control.rom“, welche
den ausführbaren Maschinencode für den Mikrocontroller enthält.
Schlug der Kompiliervorgang fehl, so ist aus den dann erscheinenden Fehlermeldungen auf das
Problem zu schließen. Bei Fragen dazu steht der Versuchbetreuer zur Verfügung. Der kompilierte Code
muss nun mit dem Programm „PonyProg“ in den Controller übertragen werden. Starten Sie dazu das
Programm und laden Sie die Datei „sms-control.hex“. Klicken Sie auf „Write program (FLASH)“ und
der Kopiervorgang startet.
Der Mikrocontroller führt danach das Programm automatisch aus. Von neuem wird er aber auch
durch Betätigen des Reset-Tasters gestartet.
5.2 Kurzeinführung Oszilloskop
Im Rahmen dieses Versuches soll ein digitales Oszilloskop mit Speicherfunktion er seriellen Kommuni-
kation verwendet werden. Bei dem zu verwendenden Gerät handelt es sich um ein Tektronix TDS 1002.
Besonders hilfreich bei der Kommunikationsanalyse unter Benutzung dieses Geräts ist, daß nicht nur
periodische Signalverläufe dargestellt werden können, sondern daß bei entsprechender Konfiguration
von Triggereinheit sowie Zeit- und Verstärkungsbasis auch einzelne Protokollabschnitte in einem nicht
verfliegenden Bild festgehalten werden können.
„Klassisch“ aufgebaute Oszilloskope haben auf der rechten Seite einen Stellknopf für die Einstellung
der Zeitbasis (hier „Sec(onds)/Div(ision)“), der dort angegebene Wert bezieht sich auf eine Kästchen-
breite auf dem Bildschirm. Stellen Sie also mit dem Wissen, daß die Kommunikation mit einer Baudrate
von 9600 erfolgt, hier zunächst einen sinnvollen Wert ein. Getriggert werden soll auf eine Flanke des
Signals (steigend oder fallend?).
Zu beachten ist insbesondere, daß hier keine periodischen Vorgänge erwartet werden, sondern
ein einmaliges Ereignis. Dieses wird vom verwendeten Oszilloskop nach Betätigen der Tasten „Single
Seq(ence)“ und „Run/Stop“ festgehalten. Erst wenn die letztgenannte Taste gedrückt wurde, erfolgt
nach dem Eintreten einer Triggerbedingung die Aufzeichnung des Signalverlaufs. In gewissen Grenzen
kann das aufgezeichnete Signal auch mittels des „Horizontal Position“-Stellknopfes und einer nachträg-
lichen Veränderung der Zeitbasis verschoben und vergrößert oder verkleinert werden.
6 Aufgaben
1. (a) Schreiben Sie ein Programm, welches die Firmware und den Hersteller des GSM-Moduls
ausliest und in zwei Zeilen auf dem Display anzeigt.
(b) Das Auslesen der Informationen geschieht über die serielle Schnittstelle des GSM-Moduls.
Schließen Sie das Oszilloskop zusätzlich an diese Schnittstelle an; beobachten und erklären
Sie die gemessenen Signalverläufe. Machen Sie sich dazu im Vorwege über Grundlagen der
Datenübertragung via RS-232 kundig.LITERATUR 21
2. Erweitern Sie nun das Programm derart, dass diese Informationen zusätzlich noch per SMS an
eine gültige Handynummer gesendet werden können.
3. Schreiben Sie ein Programm zur Schaltung der Einfachports 0 bis 3 per SMS.
4. Verfassen Sie anschließend ein Programm, welches auf das Eintreffen einer SMS wartet, diese
auswertet und Anweisungen zur Ausgabe von Text auf dem Display ausgibt. Erweitern Sie das
Programm derart, dass eine Rückantwort bei ungültigem SMS-Inhalt gesendet wird. Senden Sie
dabei die Ursprungs-SMS mit einem entsprechenden Kommentar zurück.
5. Schreiben Sie eine Alarmfunktion, die eine SMS sendet sobald das Alarmsignal von Taster 1, z.B.
einem angeschlossenen Glasbruchsensor, ausgelöst wird.
6. Schreiben Sie eine Prozedur, die in der Lage ist, mit den Rückmeldeports 4 und 5 inklusive der
Korrespondenzports 6 und 7 umzugehen. Sie sollen hierfür per SMS Ports schalten und eine
Rückmeldung über den Erfolg bzw. Misserfolg versenden.
7. In der folgenden Aufgabe sollen Sie eine der Schwächen des GSM- Netzes, die die Eindeutigkeit
der Kommunikation zwischen Sender und Empfänger beeinflussen kann, abfangen. Konkret ist
ein Szenario gemeint, in dem die tatsächliche Reihenfolge des Empfangs der SMS nicht mit der
Reihenfolge des Sendens übereinstimmt: Sie senden die Nachricht A (z.B. bei Kaffee:an) und
danach B (z.B. Kaffee:aus), empfangen werden jedoch B und dann A, woraufhin mit D und
C geantwortet wird (diese werden eventuell auch wieder vertauscht...). Welche Probleme können
auftreten? Was für einen Protokollmechanismus können Sie implementieren um diese Fehlerquelle
zu entdecken/zu vermeiden?
8. Fügen Sie dem zu sendenden Text einen CRC-8-Prüfwert hinzu. (Software zum Berechnen des
Prüfwerts liegt vor.) Programmieren Sie auf dem Mikrocontroller eine Funktion, die verhindert,
daß bei falschem Prüfwert eine Aktion ausgeführt wird. Näheres zur Auswertung erfahren Sie
vom Versuchsbetreuer.
Literatur
[1] AT-Befehlssatz aus http://www.itu.int/rec/T-REC-V.250/de
[2] ITU V.24 (ähnlich RS-232) http://www.itu.int/rec/T-REC-V.24/deSie können auch lesen
