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. Einführung ....................................................................................................................................... 3 1.1 Das Projektziel ...................................................................................................................... 3 2. Ü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 3. 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 4. 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 5. 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 6. Literaturverzeichnis ......................................................................................................................... 15 7. 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 rcX-Betriebssystem integrieren kann. 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. 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.2. rcX konfigurieren

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.

2.1.3. Kompilieren 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 Include-Verzeichnisse angegeben. Genauso wie bei den Bibliotheken wird hier mit der Option -I<path> der Pfad zum Include-Verzeichnis 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.

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. Gab es beim Kompilieren oder Linken Fehler, so wurde kein neues Image geschrieben. Dann heißt es Fehlermeldungen analysieren und Fehler suchen.

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. 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.

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 Hello-World Beispiel für die TCP/IP-Kommunikation 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.

5 / 18

3. Implementierung 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. Die Implementierung des Java-Clients ist in einem gesonderten Kapitel aufgeführt. 3.1. Die Kommunikation mit der Außenwelt

Die Kommunikation wird mit Hilfe von µIP, dem Hello-World Beispiel von µIP und dem Pingdemo-Beispiel 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 ServerSocket-Verbindung auf und übernimmt die Übertragung der Wetterdaten. Die Integration von µIP in rcX geschieht durch das angepasste Pingdemo-Beispiel. Die Kommunikation ist derzeit ausschließlich über Port 0 möglich. 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. 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.

Um dennoch die Eigenschaften der gepackten Structs beizubehalten, musste im gesamten µIP-Projekt - µIP Quellcode und verwendete Beispiel-Applikationen - jeder Definition eines Structs das Pragma packed manuell im Programmcode angehängt werden. 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)); Für alle weiteren Implementierungsdetails zu µIP sei auf die Dokumentation von µIP verwiesen. 3.1.2. Anpassen der Pingdemo

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 Interrupt-Typ 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 Ethernet-Frame zu behandeln. Beim Versuch die Pingdemo zusammen mit rcX zum laufen zu bekommen, wurde die Interrupt-Serviceroutine 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.

6 / 18

Die Funktion PacketHandler wird nur dann aufgerufen, wenn Tatsächlich ein Paket im Puffer liegt. 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: PacketHandler:

Wird von der Interrupt-Behandlungsroutine 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 FIFO-Puffer 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.

Alle weiteren Funktionen sind noch von der alten Pingdemo und werden nicht mehr verwendet.

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 Socket-Verbindung 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. 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. Wie das Hello-World Beispiel bzw. die Socket-Verbindungen 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 rcX-Dokumentation beschrieben.

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. 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.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.

3.2.2. Umwandlung 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. 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. 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. 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. 4.1. Die Sensoren

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. 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.

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.

Abb. 2: SHT1x und SHT7x (Quelle: Datenblatt SHTxx)

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 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.

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. 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.

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 Duty-Cycle 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.

Abb. 4 Übertragungsbeispiel für den SHT75 (Quelle: Datenblatt SHTxx))

Abb. 5 Messsequenz des SHT75 (Quelle: Datenblatt SHTxx))

10 / 18

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.

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. 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

als typischerweise 35 ms Low bleibt. Auf dem I²C-Bus 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. Weiterhin unterscheiden sich die beiden Bus-Systeme 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. 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.

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. 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 Satelliten-Signal 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.

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.

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. 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. 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 Anfrage-Intervall bestimmt wie oft der Client beim netX neue Wetterdaten anfordert. Kann keine Verbindung zum netX hergestellt werden, wird ein Hinweis auf der Kommandozeile ausgegeben.

Abb. 8 WeatherGUI

Abb. 9 OptionsFrame

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. 5.2.1. WeatherGUI

Hauptfenster der grafischen Benutzeroberfläche. In ihr werden alle anderen Klassen verwendet. Neben dem Konstruktor und der Initialisierungs-Funktion (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 Port-Nummer. 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.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.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.

5.2.4. DrawPanel 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.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.6. WeatherData

Objekt für die Speicherung eines Wetterdatensatzes. Enthält nur die üblichen Getter- und Setterfunktionen für die Feldvariablen.

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