PDF, 519,4 KB

Technische Universität Berlin
Fakultät IV – Elektrotechnik und Informatik
Praktikum Digitale Systeme
0430 L 390
NetX500
Wetter-Station
Gruppe MC2
Christian Deutschmann, Kay Massow, Tobias Schulze, Markus Hagen
Betreuer: Manuel Borchers
„ Inhalt
1.
2.
3.
4.
5.
6.
7.
Einführung ....................................................................................................................................... 3
1.1
Das Projektziel ...................................................................................................................... 3
Übersicht über das Projekt ............................................................................................................... 4
2.1. Der Workflow bis zum laufenden System ............................................................................ 4
2.1.1. Makefile statt HiTop............................................................................................... 4
2.1.2. Den Task schreiben................................................................................................. 4
2.1.3. rcX konfigurieren.................................................................................................... 4
2.1.4. Kompilieren ............................................................................................................ 4
2.2. Die Dateistruktur (Wo finde ich was?) ................................................................................. 5
Implementierung .............................................................................................................................. 6
3.1. Die Kommunikation mit der Außenwelt............................................................................... 6
3.1.1. Anpassen von µIP................................................................................................... 6
3.1.2. Anpassen der Pingdemo.......................................................................................... 6
3.1.3. Anpassen des Hello-World Beispiels...................................................................... 7
3.1.4. Der Task1 ............................................................................................................... 7
3.2. Die Kommunikation mit den Sensoren ................................................................................. 8
3.2.1. Einlesen der Sensordaten ........................................................................................ 8
3.2.2. Umwandlung .......................................................................................................... 8
3.2.3. Datenübergabe ........................................................................................................ 8
Die Sensorplatine ............................................................................................................................. 9
4.1. Die Sensoren ......................................................................................................................... 9
4.1.1. Temperatur.............................................................................................................. 9
4.1.2. Luftruck .................................................................................................................. 9
4.1.3. Luftfeuchte.............................................................................................................. 9
4.1.4. Windgeschwindigkeit ............................................................................................. 10
4.1.5. Lichtintensität ......................................................................................................... 11
4.2. SMBus vs. I2C-Bus ............................................................................................................... 11
4.3. GPS ....................................................................................................................................... 11
4.4. LC-Display............................................................................................................................ 12
Der Java-Client ................................................................................................................................ 13
5.1. Die Benutzeroberfläche......................................................................................................... 13
5.2. Die Implementierung in Grundzügen.................................................................................... 14
5.2.1. WeatherGUI............................................................................................................ 14
5.2.2. OptionsFrame ......................................................................................................... 14
5.2.3. HistoryFrame .......................................................................................................... 14
5.2.4. DrawPanel .............................................................................................................. 14
5.2.5. WeatherClient ......................................................................................................... 14
5.2.6. WeatherData ........................................................................................................... 14
Literaturverzeichnis ......................................................................................................................... 15
Anhang............................................................................................................................................. 16
7.1. Sensorboard Bestückungsplan, -Unterseite, -Oberseite ........................................................ 16
7.2. Sensorboard Schaltplan......................................................................................................... 18
2 / 18
„ 1. Einführung
Das Projekt Digitale Systeme hatte im
Wintersemester 2006/2007 zum ersten Mal die
Möglichkeit mit dem Netzwerk-Controller netX
von der Firma Hilscher zu arbeiten. Der
Fachbereich
Elektronik
und
medizinische
Signalverarbeitung hatte dazu von Hilscher mehrere
netX 100 Starterkits zur Verfügung gestellt
bekommen.
ƒ
1.1. Das Projektziel
Unsere Zielsetzung war es anhand eines konkreten
Projektes erste Erfahrungen mit dem Controller und
der Entwicklungsumgebung zu sammeln.
Nach mehreren Projektvorschlägen haben wir uns
für eine verteilte Wetterstation entschieden. Die
Wetterstation sollte mit Hilfe von Sensoren die
relevanten Wetterdaten erfassen und diese dann bei
Abfrage zur Verfügung stellen. Die Abfrage der
Wetterdaten selbst sollte über einen entfernten
Aufruf von einem beliebigen Computer aus
erfolgen. Durch die Verwendung von IP als
Transportprotokoll
ist
eine
weltweite
Kommunikation über das Internet gewährleistet.
3 / 18
„ 2. Übersicht über das Projekt
ƒ
2.1. Der Workflow bis zum laufenden System
ƒ
In diesem Kapitel wird kurz ein Beispiel gezeigt,
wie man einen einfachen Task in das rcXBetriebssystem integrieren kann.
ƒ
Jetzt wurden alle Änderungen vorgenommen.
Zuletzt muss für die Kompilierung das Makefile
und die Linker-Datei von netX angepasst werden.
Zunächst wird das Makefile für den neuen Task
erweitert. Das Makefile enthält im wesentlichem
vier verschiedene Variablen, die für unser Anliegen
wichtig sind:
1. OBJECTS
Hier werden die Objektdateien angeben,
welche beim Kompilieren erzeugt werden
sollen. Für den Task1 muss z.B. der
Eintrag
$(OBJECTDIR)/TaskX.o
hinzugefügt werden.
2. LIBS
Hier werden die Dateipfade zu den
benötigten
Bibliotheken
angegeben.
Sollten für unsere Applikation weitere
Bibliotheken benötigt werden, muss diese
Variable um den Eintrag -L<path>
erweitert werden. Wobei path der absolute
Pfad zum Bibliotheksverzeichnis ist.
3. INCLUDES
Hier werden alle benötigten IncludeVerzeichnisse angegeben. Genauso wie bei
den Bibliotheken wird hier mit der Option
-I<path> der Pfad zum IncludeVerzeichnis angegeben.
4. CFLAGS
Hier werden die Kompileroptionen
festgelegt. Hier sollte man allerdings nur
mit Vorsicht Hand anlegen, da diese
speziell für rcX angepasst sind. Eine
Änderung könnte zu Inkompatibilitäten
führen.
2.1.1. Makefile statt HiTop
Die Entwicklungsumgebung HiTop5 von hitex hat
sich nur bedingt als vorteilhaft erwiesen. Es
empfiehlt sich HiTop nur zum Hochladen des
Programms sowie zum Debuggen zu verwenden, da
es immer wieder zu unerklärlichen Phänomenen unter anderem auch Abstürze - kommen kann.
Zum Kompilieren wurde deshalb ein Makefile
geschrieben, welches das hochzuladende Image
erzeugt. Da das Makefile im Wesentlichen zwei
Projekte kompilieren muss kann es unter
Umständen dazu kommen, dass ein Teil des
Gesamtprojektes nicht neu kompiliert. Ein
einfacher Aufruf von make clean ist dabei bereits
eine Abhilfe.
ƒ
2.1.2. Den Task schreiben
Als erstes wird eine neue C-Datei für den Task
erzeugt. Diese wird dann am besten in dem
Verzeichnis abgelegt, wo bereits die anderen Tasks
abgelegt worden sind. Also im Verzeichnis rcX\src.
Bei der Konfiguration von rcX kann man festlegen,
welche Funktionen zum Start und zum Beenden des
Tasks aufgerufen werden. Eine Funktion zum
Beenden des Tasks wird nicht von rcX gefordert,
könnte aber im Besonderem dann wichtig sein,
wenn man sich zuvor Speicher alloziert hat der
wieder freigegeben werden muss.
Damit der Kompiler das Image erzeugen kann,
fehlen noch weitere Linker-Informationen, welche
in der Datei netx.lnk stehen. Hier müssen nochmals
alle benötigten Objektdateien der Applikation
eingetragen werden.
Jetzt muss nur noch das Makefile mit make
aufgerufen werden. Ist unser HiTop-Projekt bereits
geladen, erscheint nach Erzeugung des Images in
HiTop eine Benachrichtigung, dass sich das Image
geändert hat und ob es hochgeladen werden soll.
Bei der Verwendung von weiteren Tasks ist darauf
zu achten, dass das Scheduling von rcX nicht
umgesetzt werden konnte. Deshalb muss der
Prozessor manuell (durch Schlafen legen) abgeben
werden.
ƒ
2.1.3. Kompilieren
2.1.2. rcX konfigurieren
Gab es beim Kompilieren oder Linken Fehler, so
wurde kein neues Image geschrieben. Dann heißt es
Fehlermeldungen analysieren und Fehler suchen.
Damit der Task von rcX aufgerufen werden kann,
muss er zuvor in der Konfigurationsdatei
Config_netX.c dem Betriebssystem bekannt
gemacht werden. Dazu wird im Abschnitt
Configuration of the Application Task-List dem
Array atrXStaticTasks ein neuer Eintrag vom Struct
RX_STATIC_TASK_T eingefügt.
4 / 18
ƒ
2.2. Das Dateisystem (Wo finde ich was?)
Dieses Kapitel gibt ein Überblick über die
Dateiordner und deren Inhalte.
Das gesamte Projekt wird mit einem Makefile
kompiliert. Dadurch ist es erforderlich, dass die
derzeitige Dateistruktur beibehalten wird. Die
Umstellung der Struktur beinhaltet automatisch die
Notwendigkeit das Makefile sowie weitere Dateien
anzupassen.
Abb. 1: Verzeichnis uip-1.0
Die Unterordner vom Ordner uip-1.0:
apps: Enthält die Beispiel-Applikationen von
µIP. Dazu gehören auch der Webserver,
sowie das von uns verwendete HelloWorld Beispiel für die TCP/IPKommunikation zum Client.
doc:
Original-Dokumentation zum µIP-Projekt
von Adam Dunkels.
lib:
Bibliothek von µIP.
rcX:
Von uns angelegter System-Ordner für den
netX. In diesem Ordner befinden sich
sämtliche Dateien vom Betriebssystem
rcX, die Dateien des verwendeten
Hilscher-Beispiels Pingdemo und die
Tasks für die Benutzer-Applikation sowie
für die Hardwareansteuerung. Das gesamte
Verzeichnis
ist
außerdem
das
Projektverzeichnis von HiTop!
uip:
Basis-Ordner von µIP. Einige Dateien
wurden für unsere Zwecke angepasst.
unix: Beispiel-Portierung von µIP für das
Betriebssystem Linux. Diese Portierung
war Vorlage für unsere Portierung auf rcX.
Das gesamte Projekt liegt im Verzeichnis uip-1.0
(Abb. 1). Es wurde während des Projektes kein
besonderer Wert darauf gelegt ob die Ordner und
deren Position intuitiv zu bestimmen sind.
Grundsätzlich basiert die Dateistruktur auf µIP.
µIP empfahl für die Portierung auf ein anderes
System einen neuen Unterordner für das jeweilige
System anzulegen. Dies ist mit dem Ordner rcX
geschehen. Im Ordner rcX befinden sich alle
Dateien die zum netX gehören, inklusive das
Betriebssystem rcX nebst den Dateien für die
jeweiligen Benutzer-Applikationen. Es werden
allerdings nicht alle Dateien für das Projekt
verwendet.
5 / 18
„ 3. Implementierung
Um dennoch die Eigenschaften der gepackten
Structs beizubehalten, musste im gesamten µIPProjekt - µIP Quellcode und verwendete BeispielApplikationen - jeder Definition eines Structs das
Pragma packed manuell im Programmcode
angehängt werden.
Die Implementierung scheint zunächst etwas
undurchsichtig zu sein. Doch nachdem man sich
näher mit µIP und dem Betriebssystem rcX
beschäftigt hat, dürfte es keine Fragen mehr geben.
Als erstes wird die Implementierung der
Kommunikation erläutert. Anschließend wird auf
die
Implementierung
der
Sensortreiber
eingegangen.
Beispiel:
struct uip_udp_conn {
uip_ipaddr_t ripaddr;
u16_t lport;
u16_t rport;
u8_t ttl;
uip_udp_appstate_t appstate;
} __attribute__((packed));
Die Implementierung des Java-Clients ist in einem
gesonderten Kapitel aufgeführt.
ƒ
3.1. Die Kommunikation mit der Außenwelt
Für alle weiteren Implementierungsdetails zu µIP
sei auf die Dokumentation von µIP verwiesen.
Die Kommunikation wird mit Hilfe von µIP, dem
Hello-World Beispiel von µIP und dem PingdemoBeispiel von Hilscher realisiert.
µIP wurde von Adam Dunkels am Swedish Institute
of Computer Science entwickelt und ist eine
Implementierung eines TCP/IP Protokoll Stack
speziell für Mikrocontroller. µIP unterstützt die im
Internet üblichen Protokolle wie ARP, SLIP, IP,
UDP, ICMP (Ping) und TCP und darf unbeschränkt
genutzt werden.
Das Hello-World Beispiel baut die ServerSocketVerbindung auf und übernimmt die Übertragung
der Wetterdaten. Die Integration von µIP in rcX
geschieht durch das angepasste Pingdemo-Beispiel.
ƒ
Die Pingdemo von Hilscher wurde als Beispiel
ohne Verwendung von rcX implementiert. Die
Pingdemo empfängt ein Ethernet-Frame und
behandelt diesen entsprechend. Es wird zum einen
das ARP-Protokoll sowie das ICMP-Protokoll
unterstützt. Alle anderen Pakete werden ignoriert.
Empfängt der netX ein neues Ethernet-Frame, so
wird ein Interrupt ausgelöst.
Die aufgerufene Interrupt-Serviceroutine der
Pingdemo
VIC_ISR_Comm0
(irq_handler.c)
bestimmt für den Ethernet Port 0, welcher InterruptTyp ausgelöst wurde. Die Interrupts für die Ports
unterscheiden sich in der Übertragungsrichtung
(Gesendet/Empfangen) und der Priorität.
Anschließend wird die Interrupt-Behandlungroutine
für den jeweiligen Interrupt-Typ aufgerufen. Die
Behandlungsroutine EthGetInd0 (irq_handler.c)
holt sich die Adresse des Ethernet-Frames aus dem
FIFO-Puffer vom Port 0 der Hardware und ruft
anschließend
die
Funktion
PacketHandler
(pingdemo.c) als Applikation auf, um das EthernetFrame zu behandeln.
Die Kommunikation ist derzeit ausschließlich über
Port 0 möglich.
ƒ
3.1.2. Anpassen der Pingdemo
3.1.1. Anpassung von µIP
Zunächst musste µIP für die Verwendung unter rcX
angepasst werden. Dazu wurde der Ordner rcX
angelegt. Im src-Verzeichnis von rcX befindet sich
die Datei Task1.c welcher unser µIP-Task ist und
für die Kommunikation zuständig ist.
Für die Integration von µIP in das Betriebssystem
rcX wurden Änderungen an den Compileroptionen
von µIP notwendig. Alle Compilereinstellungen
von
rcX
wurden
übernommen,
um
Inkompatibilitäten entgegenzuwirken.
Beim Versuch die Pingdemo zusammen mit rcX
zum laufen zu bekommen, wurde die InterruptServiceroutine VIC_ISR_Comm0 nicht mehr
aufgerufen. Der Grund dafür liegt darin, dass alle
Interrupts zuvor im Betriebssystem konfiguriert
werden müssen. Es hätte also rcX mitgeteilt werden
müssen, welche Serviceroutine bei welchem
Interrupt aufgerufen werden muss.
Der Einfachheit halber wurde darauf verzichtet und
die Interrupt-Service-Routine VIC_ISR_Comm0
manuell aus der Task1.c in einer Endlosschleife
aufgerufen. Dadurch wird indirekt der FIFO-Puffer
des netX gepollt und man kann auf die Interrupts
verzichten.
Die umfangreichste Änderung ist die Auslassung
der Option -fpack-struct, welche dem Kompiler
angibt, dass alle Elemente innerhalb der Structs in
µIP im Speicherbereich ohne Freiraum - also direkt
hintereinander - stehen müssen. Dies ist
erforderlich, weil in µIP die meisten Operationen
auf den Structs mit Zeiger-Arithmetik durchgeführt
werden. Würde ein Zeiger durch das Auslassen des
Pragmas packed in einen falschen Speicherbereich
zeigen, ist die korrekte Fortführung von µIP nicht
mehr möglich.
6 / 18
Die Funktion PacketHandler wird nur dann
aufgerufen, wenn Tatsächlich ein Paket im Puffer
liegt.
ƒ
3.1.3. Anpassen des Hello-World Beispiels
Das Hello-World Beispiel von µIP stellt einen
einfachen SocketServer dar. Die Funktion
hello_world_appcall wird von µIP aufgerufen,
wenn jemand von außen versucht eine SocketVerbindung zum entsprechenden Port - bei uns Port
1000 - aufzubauen. Das Beispiel sendet zunächst
einen String, auf den der Client antworten soll.
Anschließend wird die Antwort ausgegebenen.
Die Pingdemo erhält also jetzt alle Ethernet-Frames
die auf Port 0 empfangen werden und kann dies nun
behandeln. Im unserem Projekt wird die
Behandlung der Ethernet-Frames µIP überlassen.
Dazu wird der Inhalt des Ethernet-Frames - das
Paket - in den globalen Puffer uip_buf kopiert.
Anschließend folgen nur noch Anweisungen aus
der ursprünglichen main-Funktion von µIP, welche
die Behandlung des Pakets durchführen. Unter
anderem wird dann während der Behandlung des
Paketes das von uns angepasste Hello-World
Beispiel von µIP aufgerufen. Nachfolgend sind alle
beteiligten Funktionen der Pingdemo aufgelistet:
Es wird das Beispiel für die Übertragung der
Wetterdaten an den Client verwendet. Der Client
stellt dazu eine Socket-Verbindung her und sendet
einen beliebigen String. Anschließend werden die
Wetterdaten
aus
den
Sensoren
gelesen,
gegebenenfalls konvertiert und anschließend in
einem String angeordnet, wobei das Semikolon die
Werte voneinander trennt. Dieser String wird dann
zum Client gesendet.
An dieser Stelle wird festgelegt in welcher
Reihenfolge die Werte im String auftauchen. Wird
die Reihenfolge geändert, kann der Client den
String nicht mehr korrekt auswerten.
PacketHandler:
Wird
von
der
InterruptBehandlungsroutine aus aufgerufen. Sie
leitet das Ethernet-Frame an die Funktion
process_uip_packet weiter.
process_uip_packet:
Kopiert das Ethernet-Frame in den
uip_buf. Falls der Frame größer ist als der
Puffer von µIP, wird dieser nicht behandelt
und der Frame wieder freigegeben.
Anschließend
übernimmt
µIP
die
Behandlung des Paketes. Bevor die
Funktion terminiert, wird das Frame
wieder freigegeben.
eth_driver_send:
Sendet ein Ethernet-Frame auf den
jeweiligen Port. Es wird versucht einen
Speicherplatz für ein Frame vom FIFOPuffer des netX zu bekommen. Ist ein
Frame verfügbar, wird der uip_buf in das
Frame kopiert und anschließend versendet.
Ist das Paket im uip_buf kleiner als die für
den Ethernet-Standard IEEE 802.3
vorgeschriebene Mindestgröße von 60
Bytes, wird die Länge des Paketes manuell
auf 60 Bytes gesetzt. Bevor die Funktion
terminiert wird das Frame wieder
freigegeben.
set_macs:
Setzt die MAC-Adressen der netX
Ethernet-Ports. Wird für die Initialisierung
benötigt.
Wie das Hello-World Beispiel bzw. die SocketVerbindungen von µIP aufgerufen wird, ist Teil von
µIP und kann in der dazugehörigen Dokumentation
nachgeschlagen werden.
ƒ
3.1.4. Der Task1
Der Task1 ist für die Kommunikation zuständig. Er
initialisiert den netX und µIP und geht dann in eine
Endlosschleife, welche die bereits angesprochene
Interrupt-Serviceroutine periodisch aufruft. Nach
jedem Aufruf legt sich der Task für eine kurze Zeit
schlafen, damit Task2 die Sensoren auslesen kann.
Leider muss die CPU manuell an die anderen Tasks
abgegeben werden, weil es nicht möglich war die
preemptive Prozess-Planung von rcX zu
verwenden.
Daher ist es unbedingt notwendig, jeden Task bis
auf weiteres mit dem Befehl rX_SysSleepTask
schlafen zu legen, um die CPU für andere Tasks
frei zu machen.
Die „statischen“ Tasks werden rcX in der Datei
Config_netX.c bekannt gemacht. Wie im Einzelnen
rcX konfiguriert wird, ist in der rcXDokumentation beschrieben.
Alle weiteren Funktionen sind noch von der alten
Pingdemo und werden nicht mehr verwendet.
7 / 18
ƒ
3.2. Die Kommunikation mit den Sensoren
ƒ
Essentiell für die Wetterbeobachtung sind die
Temperatur, Luftfeuchtigkeit, Luftdruck und
Windgeschwindigkeit. Zusätzlich wird noch die
Lichtintensität gemessen, um z.B. die Tage mit
Sonnenschein oder den Bewölkungsgrad messen zu
können.
Ein
GPS-Gerät
erweitert
den
Funktionsumfang für eine mobile Anwendung der
Wetterstation.
Nachdem die Daten eingelesen wurden liegen sie
meist in Form einer Ganzzahl in einem Register des
Prozessors. Um für den Menschen lesbare Werte zu
erhalten werden sie daher entsprechend den
Formeln in den Datenblättern umgewandelt.
Die Temperatur wird z.B. durch 256 geteilt, die
Lichtintensität hingegen ist relativ komplex mit
ihrer logarithmischen Skala. Hier sei auf die
entsprechenden Datenblätter und den Sourcecode
verwiesen.
Die Entscheidung fiel größtenteils auf integrierte
Sensoren. Dadurch erübrigt sich das aufwändige
Kalibrieren und die Korrektur der Kennlinien.
Außerdem sind die integrierten Sensoren genau
betrachtet nicht teurer als ihre analogen
Gegenstücke, denn für letztere braucht man
üblicherweise einige weitere Bauteile zur
Temperaturkompensation,
Linearisierung
und
Anpassung der Kennlinien und zu guter Letzt auch
einen Digital-Analogwandler, um die gemessenen
Größen für einen Mikrocontroller nutzbar zu
machen. Der erhebliche zusätzliche Aufwand und
die zusätzlichen Fehlerquellen haben uns bewogen
auf digitale Sensoren zurückzugreifen, die lediglich
geeignet angesprochen werden müssen.
ƒ
3.2.2. Umwandlung
ƒ
3.2.3. Datenübergabe
Nach der Umwandlung werden die Werte als
Fließkommazahlen in eine globale Struktur
geschrieben. Dies hat mehrere Vorteile. Zum einen
steht immer ein aktueller Wert zum Abruf breit,
denn die Sensoren benötigen teilweise bis zu einer
Sekunde um Daten zu erfassen. Dies spielt bei der
Wetterbeobachtung zwar keine Rolle, verzögert
aber unnötig den Datentransfer, wenn immer erst
eine Datenerfassung beim Sensor beantragt werden
muss. Das bedeutet gleichzeitig, dass die Sensoren
im „Dauerbetrieb“ arbeiten und ständig die Daten
in der Struktur aktualisieren. Ein weiterer Vorteil ist
zum anderen eine einfache Kommunikation
zwischen den einzelnen Softwareteilen. Mailboxen
oder andere Arten der IPC haben im Allgemeinen
einen deutlich größeren Overhead und sind zudem
verhältnismäßig umständlich zu bedienen.
3.2.1. Einlesen der Sensordaten
Da das Starterkit für den netX100 kein eingebautes
I²C-Interface besitzt, musste das Protokoll von
Hand
implementiert
werden.
Die
Kommunikationsroutinen
benutzen
kein
Hardwaretimer oder Interrupts, sondern machen
alles zu Fuß. Es wird jeweils aktiv auf die nächste
Taktsignalflanke gewartet und die Datenleitungen
entsprechend geschrieben oder gelesen.
Für den Luftdruck wird der A/D-Wandler auf dem
Entwicklungsboard verwendet, alle anderen
Sensoren sind an den PIO-Pins angeschlossen. Das
Auslesen der Sensoren erfolgt in einer
Endlosschleife.
Um die Weiterverarbeitung der Daten im Task1 zu
gewährleisten muss Task2 mit der Systemfunktion
rX_SysSleepTask die Kontrolle abgeben. Dies
geschieht immer dann, wenn Task2 eine längere
Zeit auf Sensordaten warten muss. Ebenso am Ende
eines kompletten Schleifendurchlaufs, also
nachdem alle Sensoren einmal ausgelesen wurden.
8 / 18
„ 4. Die Sensorplatine
Auf der Sensorplatine befinden sich die in den
nachfolgenden
Abschnitten
beschriebenen
Sensorschaltungen. Angeschlossen wird die
Sensorplatine über eine 64 polige Stiftsockelleiste
an das Entwicklungsboard.
Als Versorgungsspannungen werden +5V und zwei
zueinander symmetrische Spannungen von +12 bis
+15V und -12 bis -15V benötigt. Für die lokale
Ausgabe der Daten ist der Anschluss eines
Grafikdisplays vorgesehen.
ƒ
4.1.3. Luftfeuchte
Zur Messung der relativen Luftfeuchtigkeit wird
der SHT75 der Firma Sensirion verwandt. Die
Anbindung des Sensors geschieht digital über eine
Two-Wire-Schnittstelle.
Schaltplan, Layouts und Bestückungsplan befinden
sich im Anhang.
ACHTUNG: Sowohl im Schaltplan als auch im
Layout sind die Eingänge des Operationsverstärkers
NE5532N(IC2) vertauscht. Es müssen die
Anschlüsse 2 und 3 sowie 5 und 6 getauscht
werden.
Abb. 2: SHT1x und SHT7x (Quelle: Datenblatt SHTxx)
ƒ
ƒ
4.1. Die Sensoren
Eigenschaften:
− vollständig kalibriert
− absolute Genauigkeit +/- 1,8% r.F. (im Bereich
von 20-80% RH)
− 8 oder 12 Bit Werte
− Messbereich 0-100%
− präzise Taupunkberechnung
− keine äußere Beschaltung notwendig
− Ansprechzeit < 4s
− CRC-Prüfsumme
− zusätzlicher Temperatursensor
− Genauigkeit des Temperatursensors: +/- 0.3°C
bei 25°C
4.1.1. Temperatur
Zur Temperaturmessung wird ein DS1631 von
Dallas Semiconductor eingesetzt. Dieser integrierte
Baustein misst die Temperatur im Bereich von -55
°C bis +125 °C. In dem Bereich von 0°C bis 70°C
besitzt er eine Genauigkeit von ±0.5°C.
Angeschlossen wird er über den I²C-Bus. Der
Sensor wird im „continuous-conversion mode“
betrieben, so dass jederzeit ein aktueller Messwert
im Register steht und dieser nur ausgelesen zu
werden braucht.
Die Messungen werden mit 12 Bit Genauigkeit
gespeichert,
auch
wenn
aufgrund
des
Temperaturfehlers und des Messbereiches 9 Bit
ausreichen würden.
ƒ
Anbindung:
Angesteuert wird er SHT75 über zwei PIO Pins des
NXSB 100. Der Bus besteht aus einer
Datenleitung(DATA) und einer Taktleitung(SCL).
Die Datenleitung ist an PIO38 und die Taktleitung
an PIO37 des NXSB 100 angeschlossen.
Da es sich um ein Single-Master System handelt,
obliegt die Kontrolle der Taktleitung ausschließlich
dem NetX-Mikrocontroller, so dass der Pull-Up
Widerstand für die Taktleitung entfallen kann (Abb.
3). Die Datenleitung muss allerdings analog zum
I²C Bus im Ruhezustand über einen Pull-Up
Widerstand auf High-Potential gelegt sein.
4.1.2. Luftdruck
Integrierte Luftdrucksensoren sind selten und teuer,
daher wurde für die Luftdruckmessungen ein
analoger Sensor verwendet. Die Entscheidung fiel
auf einen Sensor aus der MPXAZ6115A-Serie von
Freescale Semiconductor. Er kommt mit einer
geringen Anzahl externer Bauteile aus, davon
abgesehen gab es keine besonderen Gründe für die
Wahl.
Der Sensor misst den absoluten Luftdruck zwischen
15 kPa und 11 kPa und gibt eine zum Luftdruck
linear proportionale Spannung zwischen 2 V und
4.7 V aus. Diese Spannung wird mit einer
Operationsverstärkerschaltung auf einen Bereich
zwischen 0 V und 3.3 V umgewandelt. Dies ist
notwendig, damit der A/D-Wandler auf dem
Starterboard komplett ausgesteuert wird.
Abb. 3: Anbindung des SHT75 (Quelle: Datenblatt SHTxx)
9 / 18
ƒ
Busprotokoll:
Zum Einsatz kommt eine an die I²C Schnittstelle
angelehnte Two-Wire Schnittstelle. Allerdings
können außer einem einzelnen SHT75 keine
weiteren Sensoren angeschlossen werden, so dass
es sich um eine reine Punkt-zu-Punkt Verbindung
handelt. Aus diesem Grund benötigt das
Busprotokoll keine Adressierung.
Start- und Stopbedingung sind ebenfalls geändert.
Eine Startbedingung besteht zunächst aus einer
fallenden Flanke der Datenleitung während die
Taktleitung high ist. Zusätzlich muss die
Datenleitung bis zum nächsten high-Pegel der
Taktleitung low bleiben, um dann während dem
high-Pegel der Taktleitung auf high zu steigen
(Abb. 4) . Eine Stopbedingung in dem Sinne des
I²C Bussystems existiert nicht.
4.1.4. Windgeschwindigkeit
Der Sensor für die Windgeschwindigkeit ist ein
handelsübliches Anemometer mit vier Schaufeln.
Gemessen wird die Anzahl der Umdrehungen pro
Sekunde. Dazu ist im Inneren ein Reedkontakt
angebracht, der von einem Magneten jede
Umdrehung einmal geschlossen wird. Es wird die
Windgeschwindigkeit also proportional in eine
Frequenz umgewandelt. Der Reedkontakt ist an
einem PIO-Pin angeschlossen und zieht ihn im
geschlossenen Zustand auf Low. Den PIO-Pins
stehen leider keine Interrupts zur Verfügung, also
muss der Sensor fortwährend abgefragt werden.
Da alle 4 ms der Pegel des Signals geprüft wird
ergibt sich zusammen mit dem konstanten DutyCycle
des
vom
Anemometer
erzeugten
Rechtecksignals ein Meßbereich von 0,31 m/s bis
12,96 m/s. Der Zähler wird dabei jede Sekunde
ausgelesen und für die nächste Messung
zurückgesetzt, wodurch sich die untere Grenze
ergibt.
Verwendet wird der 12 Bit Modus des SHT75, so
dass zwei Byte nacheinander ausgelesen werden
müssen(Abb. 5). Die zusätzliche CRC Prüfsumme
wird nicht ausgewertet. Der Temperatursensor
findet keine Verwendung.
Abb. 4 Übertragungsbeispiel für den SHT75 (Quelle: Datenblatt SHTxx))
Abb. 5 Messsequenz des SHT75 (Quelle: Datenblatt SHTxx))
10 / 18
ƒ
als typischerweise 35 ms Low bleibt. Auf dem I²CBus dagegen kann das Taktsignal beliebig lange
Low bleiben. In der Tat ziehen die Geräte auf dem
I2C-Bus das Taktsignal auf Low, wenn sie noch
Daten verarbeiten und noch nicht bereit sind für das
nächste Bit. Bei extrem langsamen Geräten kann
dadurch ein unbeabsichtigter Timeout-Reset bei
den SMBus-Geräten ausgelöst werden. Auf der
anderen Seite gibt es bei I²C keine Möglichkeit ein
hängen gebliebenes Gerät, welches die Taktleitung
auf Low hält davon abzuhalten, den Bus zu
belegen.
4.1.5. Lichtintensität
Der Lichtsensor ist ein TSL2550 von Texas
Advanced Optoelectronic Solutions (TAOS). Er
wird über den SMBus angesprochen.
Er besitzt zwei unabhängige Photodioden mit
verschiedenen spektralen Empfindlichkeiten. Die
eine Photodiode ist für einen relativ großen Bereich
des sichtbaren Lichtes empfindlich, wohingegen die
andere hauptsächlich im infraroten Bereich
anspricht.
Beide Dioden arbeiten unabhängig voneinander.
Durch
eine
geeignete
Berechnung
(im
Wesentlichen
eine
Subtraktion)
beider
Messergebnisse erhält man einen virtuellen Sensor,
der
der
spektralen
Empfindlichkeit
des
menschlichen Auges nachempfunden ist. Die
Angabe der Messergebnisse ist somit als
Lichtintensität in lux und als Bestrahlungsstärke in
W/m² möglich.
Weiterhin unterscheiden sich die beiden BusSysteme in ihren High- und Lowpegeln, sowie in
den minimalen und maximalen Busströmen. Es gibt
allerdings auch hier je nach Betriebsspannung eine
ausrechend große Schnittmenge, die bei
entsprechender Wahl der Pull-Up Widerstände
einen einwandfreien Betrieb ermöglicht.
Die Fähigkeit von SMBus-Geräten an den Master
ein Interrupt (ALERT#) zu senden wird bei uns
nicht verwendet, würde aber ein SMBus-Master
erfordern, da dies in der I²C-Spezifikation nicht
vorgesehen ist.
ƒ
4.3. GPS
Für die Positionsbestimmung wird ein GPS
Navigations-System der Firma H-Tronic eingesetzt.
Zusätzlich zu den Positionsdaten Längengrad,
Breitengrad und Höhe werden die Informationen
Datum und Uhrzeit ausgewertet und lokal auf
einem Display angezeigt.
Abb. 6 Im TSL2550 sind zwei Photodioden mit
unterschiedlichen Lichtempfindlichkeiten.
Ein Auslesen der Daten dauert 400 ms für eine
Photodiode. Für beide Dioden also insgesamt 800
ms.
ƒ
4.2. SMBus vs. I2C-Bus
Der Temperatur- und der Lichtsensor hängen am
selben Bus, obwohl sie für (vom Namen nach)
verschiedene Bussysteme entwickelt wurden. Die
Unterschiede zwischen SMBus und I²C-Bus sind
allerdings nur gering, wodurch man beide Sensoren
zusammen betreiben kann. Die Busprotokolle sind
weitgehend identisch, wodurch die Adressierung
kein Problem darstellt.
Abb. 7 GPS Empfangsmodul der Firma H-Tronic)
Das fertige, einsatzbereite Modul verfügt über eine
aktive
Antenne
und
benötigt
eine
Versorgungsspannung
von
12-24
Volt.
Angeschlossen wird das Modul an die die RS232
Schnittstelle des NXSB 100. Prinzipiell lässt sich
jedes GPS Modul anschließen, dass seine Daten im
NMEA-0183 Format ausgibt.
Zu den wichtigsten Unterschieden (siehe
Literaturverzeichnis [3]) gehört der Timeout und
(als Konsequenz) die minimale Datenrate des
SMBus. Timeout bedeutet dass ein Slave sein
Interface zurücksetzt, wenn das Taktsignal länger
11 / 18
ƒ
Datenübertragung
Die Positionsdaten des GPS-Moduls werden im
NMEA-0183 Format ausgegeben. NMEA steht für
National Marine Electronics Association und ist ein
Standard für die Kommunikation zwischen
Navigationsgeräten in der Schifffahrt. Wird auch
oft für die Kommunikation zwischen GPS
Empfängern und PCs eingesetzt.
Die Übertragungsgeschwindigkeit beträgt 4800
Baud. Ausgegeben werden die Daten als ASCII
Zeichen, gruppiert in Datensätzen mit maximal 82
Zeichen. Jeder Datensatz wird durch ein '$'
eingeleitet und durch ein Zeilenvorschub (LF)
beendet. Die Daten innerhalb der Datensätze sind
durch Kommata voneinander getrennt.
4.2. LC-Display
Die Flüssigkristallanzeige ist ein Standard
Grafikdisplay mit dem T6963-Controller von
Toshiba. Es wird über das Dual-Port Memory
Interface an das netX Entwicklungsboard
angeschlossen und über die Sensorplatine mit den
nötigen Spannungen versorgt.
Beispiel
$GPRMC,074832.897,A,5228.3245,N,01310.7952,E,…
'GPRMC' ist die Kennung des Datensatzes, wobei
GP für GPS Gerät steht und RMC den
Mindestdatensatz kennzeichnet, der von jedem GPS
Gerät ausgegeben werden muss. '074832.897' steht
für die aktuelle Uhrzeit 07:48:32.897. Das darauf
folgende 'A' gibt an, dass die Daten in Ordnung
sind. Würde der GPS Empfänger keine SatellitenSignal empfangen, wäre an dieser Stelle ein V für
Warnung.
Die nächsten beiden Daten geben den Längengrad
an: 52°28,3245' nördliche Länge. Die darauf
folgenden analog den Breitengrad: 013°10,7952'
östliche Breite. Es folgen in dem hier beschriebenen
Datensatz noch einige weitere Daten und am Ende
eine Wagenrücklauf (carriage return) gefolgt von
einem Zeilenvorschub (line feed). An dieser Stelle
sei aber auf den NMEA Standard verwiesen.
Konkret ausgewertet werden Uhrzeit, Datum,
Längengrad und Breitengrad aus dem GPRMC
Datensatz, sowie die Höhe aus dem GPGGA
Datensatz.
12 / 18
„ 5. Der Java-Client
Die Portierung von µIP ist im Wesentlichen
Gelungen. Das eigentliche Vorhaben auf dem netX
den Webserver von µIP laufen zu lassen konnte
jedoch nicht umgesetzt werden. Aufgrund des
aufkommenden
Zeitmangels
musste
die
Entscheidung getroffen werden anstatt des
Webservers
auf
die
„normale“
TCP/IP
Kommunikation über Sockets zurückzugreifen.
Dadurch entstand die Notwendigkeit einen Client
zu schreiben, welcher die Wetterdaten anstelle des
Webbrowsers anfragt.
Wir haben uns für einen Java-Client entschieden,
weil die Programmierung von Sockets in Java
wesentlich einfacher ist als in C/C++. Außerdem
können wir mit AWT/Swing zugleich ohne
zusätzliche
Software
eine
grafische
Benutzeroberfläche anbieten.
Abb. 8 WeatherGUI
ƒ
5.1. Die Benutzeroberfläche
Die Benutzeroberfläche bietet dem Nutzer einen
Überblick über die Wetterdaten in Form einer
handelsüblichen Wetterstation für Zuhause (Abb.
8). Der Client öffnet eine Socket-Verbindung zum
netX und empfängt die Wetterdaten. Diese werden
dann teilweise in die üblichen Maßeinheiten
umgerechnet, bevor sie zur Anzeige gebracht
werden.
Abb. 9 OptionsFrame
Unter dem Menüpunkt EinstellungenÆVerbindung
können die Einstellungen zur Socket-Verbindung
und dem Anfrage-Intervall geändert werden. Die
URL und der Port müssen mit den Einstellungen für
den netX (µIP) übereinstimmen. Das AnfrageIntervall bestimmt wie oft der Client beim netX
neue Wetterdaten anfordert. Kann keine
Verbindung zum netX hergestellt werden, wird ein
Hinweis auf der Kommandozeile ausgegeben.
13 / 18
ƒ
5.2. Die Implementierung in Grundzügen
ƒ
Die gesamte Anwendung besteht aus sechs Klassen.
Vier Klassen für die grafische Benutzeroberfläche,
eine für die Socket-Verbindung zum netX und eine
für die Speicherung eines Wetterdatensatzes. Alle
Fenster für die Benutzeroberfläche wurden mit
Hilfe von CloudGarden's Jigloo SWT/Swing GUI
Builder entwickelt.
ƒ
Ein Panel, in dem Arrays grafisch dargestellt
werden können.
Dabei wird die Anzeige automatisch zwischen den
Maximal- und Minimalwerten skaliert. Leider
kommt es bei Arrays mit identischen Werten zur
einer fehlerhaften Anzeige, da bei der Skalierung
die Berechnung nicht mehr ausgeführt werden
kann. Folgende Funktionen sind in der Klasse
definiert:
drawArray:
Zeichnet das übergebene Array auf der
gesamten Anzeigefläche. Sie skaliert dazu
den Anzeigebereich zwischen den
Maximal- und Minimalwert der im Array
gespeicherten Werte.
setArray:
Setzt das zu zeichnende Array. Diese
Funktion wird verwendet um von außen,
also z.B. vom HistoryFrame, das Array
anzuzeigen. Das Array wird also erst nach
dem nächsten Paint-Ereignis angezeigt.
5.2.1. WeatherGUI
Hauptfenster der grafischen Benutzeroberfläche. In
ihr werden alle anderen Klassen verwendet.
Neben dem Konstruktor und der InitialisierungsFunktion (Jigloo) wurden noch weitere Funktionen
von uns eingefügt.
setWeatherData:
Setzt die Werte der angezeigten
Komponenten auf die des übergebenen
Wetterdatums.
calculateWindspeed:
Wandelt
die
Maßeinheit
der
Windgeschwindigkeit von m/s auf km/h
um.
calculateWindforce:
Berechnet aus der Windgeschwindigkeit
die Windstärke nach Beaufort anhand einer
Lookup-Table.
update:
Aktualisiert die Parameter für die
Anfragerate, der URI und der PortNummer. Wird vom OptionsFrame
aufgerufen.
Außerdem
wurden
noch
zwei
Threads
(TimeThread,
UpdateThread)
eingefügt.
TimeThread aktualisiert jede Sekunde die Uhr auf
der Anzeige. UpdateThread holt in im
vorgegebenen Intervall die aktuellen Wetterdaten
vom WeatherClient ab.
ƒ
ƒ
5.2.5. WeatherClient
Stellt die Verbindung zum netX her. Kann auch
separat aufgerufen werden.
connect:
Stellt eine Socket-Verbindung zur aktiven
URL auf den aktiven Port her.
disconnect:
Schließt die Socket-Verbindung.
getWeatherData:
Stellt eine Socket-Verbindung zum netX
her und fordert die Wetterdaten an
(blockierendes Lesen). Nachdem die Daten
empfangen worden sind, werden diese mit
Hilfe der split-Funktion aufgeteilt und
anschließend gemäß der Spezifikation in
ihre vorgesehenen Datentypen konvertiert
und in ein neues WeatherData-Objekt
geschrieben, welches dann zurückgegeben
wird.
5.2.2. OptionsFrame
Fenster für die Optionen. Enthält nur die üblichen
Funktionen die von Jigloo generiert wurden. Beim
Klick auf den OK-Button wird die Funktion update
aus der WeatherGUI aufgerufen.
ƒ
5.2.4. DrawPanel
ƒ
5.2.6. WeatherData
Objekt
für
die
Speicherung
eines
Wetterdatensatzes. Enthält nur die üblichen Getterund Setterfunktionen für die Feldvariablen.
5.2.3. HistoryFrame
Fenster für die Anzeige der vergangenen 20
Datensätze. In der Funktion buttongroup_
ItemStateChanged wird die Queue der letzten 20
Wetterdatensätze geholt und die jeweiligen
gewünschten Daten mit Hilfe der Klasse
DrawPanel zur Anzeige gebracht.
14 / 18
„ 6. Literaturverzeichnis
[1]
„The I²C-Bus Specification“, Rev 2.1, 1/2000, Phillips
[2]
„System Management Bus Specification“, Rev 1.1, 12/1998, SBS Implementers Forum
[3]
„Comparing the I2C Bus to the SMBus“, MAXIM Application Note 476
[4]
„DS1631/DS1631A/DS1731
High-Precision
Digital
Thermometer
and
Thermostat“,
Digital
Semiconductor
[5]
„MPXAZ6115 Technical Datasheet“, Rev 3, 06/2005, Freescale Semiconductor
[6]
„NE5532, NE5532A, NE5532I, NE5532AI DUAL LOW-NOISE OPERATIONAL AMPLIFIERS“,
SLOS075A, 11/1979 – Revised 9/1990, Texas Instruments
[7]
„TSL2550 AMBIENT LIGHT SENSOR WITH SMBus INTERFACE“, TAOS029D, 12/2005, TAOS
[8]
„SHT1x / SHT7x Humidity & Temperature Sensor“ , Rev 2.04, SENSIRION
[9]
Halbleiter-Schaltungstechnik, Tietze, Ulrich, Schenk, C., Springer
15 / 18
„ 7. Anhang
ƒ
7.1. Sensorboard Bestückunsplan, -Unterseite, -Oberseite
Abb. 10 Bestückungsplan
Abb. 11 Unterseite
16 / 18
Abb. 12 Oberseite
17 / 18
ƒ
7.2. Sensorboard Schaltplan
18 / 18