Für die Tage der offenen Tür der HTBL Hollabrunn im Jahr 2017/18 entstand ein Testprogramm, welches die neuen Features des Minimalsystems demonstrieren sollte. Hierzu wurde ein einfaches \gls{GUI} für das NEXTION-Display programmiert, welche die X, Y und Z Werte der Beschleunigung vom über SPI angesteuerten Gyroskop ausliest, und in Form eines Graphen anzeigt. Des weiteren wurde eine -- nicht 100\% funktinierenden -- Funktion zum Speichern des Graphen (auf dem verbauten EEPROM) programmiert.
Das Hauptprogramm in \texttt{main.c} initsialisiert alle Ports sowie den SysTick Interrupt. Die einzelnen Komponenten wurden für die Übersichtlichkeit in extra Files ausgelagert. Im Hauptprogramm ist außerdem der Main-Loop, welcher die Werte vom BMA einliest und am Display ausgibt. Der Main-Loop fragt auch Displayeingaben ab und reagiert auf diese (Start/Stopp, Speichern und Laden).
\lstinputlisting[language={[ANSI]C}, caption=Tag der offenen Tür: Hauptprogramm, label=lst:sw-odd-main]{Mieke/SW/ODD/main.c}
Dieses File enthält die Implementation des Input/Output Teils, hauptsächlich initsialisiert sie die einzelnen Peripherieeinheiten, sie stellt aber mit \texttt{USART\_SendString()} auch eine häufig genutzte Funktion zum senden von Strings über UART zuer Verfügung, welche die Standard CMSIS Library nicht beinhaltet.
In diesem File wird zuerst das Display initsialisiert, danach stellt das File noch Funktionen zum senden von Gyro Daten und zum Aus- und Einschalten bereit. Im File ist auch ein Interrupt-Handler für USART3 ausprogrammiert, welcher Button-Klicks welche das Display sendet verarbeitet und zwischenspeichert, bis sie von einer weiteren Funktion, welche im Main-Loop aufgerufen wird, ausgegeben werden.
Das BMA-File enthält eine Funktion zum auslesen und verarbeiten der drei Beschleunigungsachsen X, Y und Z. Die Funktion wird vom Main Loop aufgerufen und gibt die Beschleunigung auf der übergebenen Pointern bereits für das Display vorverarbeitet (verkleinert und zentriert) zurück.
Dieses File enthält zwi Funktionen, eine zum lesen und eine zum schreiben auf das verbaute EEPROM, beide werden von der Main Loop aufgerufen und erlauben es ein Array von Bytes mit der Länge \texttt{length} ab einer Übergebenen Adresse zu speichern beziehungsweise in dieses zu schreiben.
Das Bluetooth-File enthält eine Funktion zum senden von Gyro Data, welche einen String generiert und diesen über USART1 (wo das Bluetooth Modul angeschlossen ist) ausgibt.
Im finalen Programm wurde das Senden der Werte über Bluetooth weggelassen, da es die Main-Loop zu sehr verlangsamte, und somit die Displayausgabe nicht mehr flüssig genug war.
\end{warning}
\lstinputlisting[language={[ANSI]C}, caption=Tag der offenen Tür: Bluetooth Implementation, label=lst:sw-odd-bluetoothc]{Mieke/SW/ODD/bluetooth.c}
Um die im Unterricht hergestellten Einheiten des \gls{Minimalsystem}s testen zu können, musste ein Testpgrogramm geschrieben werden, welches alle verwendeten Peripherieeinheiten ansteuern kann. Dabei war es nicht das Ziel eine bestimmte Funktion zu erreichen, sondern zu testen, ob die Busse komplett durchverbunden sind, oder ob sich irgendwo auf der Leiterkarte kalte Lötstellen oder andere Fehler befinden. Dementsprechend testen diese Tests nur ob generell eine Kommunikation mit einer Peripherieeinheit möglich ist, und nicht ob diese auch korrekt funktioniert.
Im Hauptprogramm werden die UARTs für das anzeigen der Menüs konfiguriert, die Menüs angezeigt und auf Eingaben auf eben diese reagiert. Die einzelnen Tests wurden möglichst kompakt und modular geschrieben. Ein Test stellt dabei immer ein Interface bestehend aus Init-, Run- und DeInit-Funktion.
Dieses File enthält Funktionen um alle USARTs zu initsialisieren, eine Willkommensnachricht an alle zu senden und passend auf die eingabe alle außer einen zu Deaktivieren, dieser verbleibende USART ist dann der, worüber Kommunikation läuft, während alle anderen für Tests zur Verfügung stehen. Des weiteren existieren zwei Funktionen um auf einen neuen Test (beziehungsweise auf eine neue gedrückte Taste) abzufragen. Dies kann entweder blockierend aufgerufen werden, oder nicht blockierend.
Der NE555 Test, bestehend aus Init und DeInit Funktion und einer Funktion, welche die Zustandswechsel über eine Sekunde misst und halbiert ausgibt (ergibt eine Frequenz). Dieser Test kann auch für den LFU und den Infrarot Sensor verwendet werden, da die beiden auch Frequenzen ausgeben.
Der LEDs/Switch test liest die Schalterstellungen ein und gibt diese wieder auf den LEDs aus. Bei Verwendung von USART2 kann es hier zu Problemen kommen, da die Schalter unter anderem auf den Rx und Tx Leitungen von USART2 liegen.
Der EEPROM-Test sendet einige Bytes an den Speicher und liest diese danach sofort wieder aus. Wenn der gesendete und ausgelesene Wert übereinstimmt, dann war der Test erfolgreich.
Der ESP Test öffnet einen WLAN Access Point und einen TCP Server mit dem Port \texttt{2526}, dieser gibt dann alle Daten, welche mit TCP gesendet werden über den verwendeten USART aus.
Um das Display zu testen, wird mehrmals der Screen gelöscht und in einer anderen Farbe gezeichnet. Dieser Befehl sollte auch ohne extra Test-Programm, unabhänging von dem zur Zeit geflashten Programm, auf dem Display funktionieren.
Ein Ziel dieser Diplomarbeit war es eine Library für das Arduino Ethernet Shield (Version 1.0) zu entwickeln, dies ist bis dato nicht 100\%ig gelungen, da die SPI Peripherie des \gls{cpu} Probleme bereitet und in manchen Situationen das \gls{LSb} ignoriert. Zum Beispiel, wenn der Ethernet Controller den Status \texttt{0x13} sendet, beinhaltet das Datenregister nur \texttt{0x12}, das \gls{LSb} ist also immer \texttt{0}. Das derzeitige Hauptaugenmerk liegt beim \gls{Debugging} dieses Fehlers. Eine mögliche Lösung wäre das SPI Interface selbst zu implementieren, und nicht die vorhandene Peripherieeinheit zu verwenden. Der nun folgende Programmcode ist deshalb keine Library, sondern ein eigenständiges Test-Programm, welches noch nicht 100\% funktioniert.
\subsubsection{main.c}
Das Hauptpgrogramm initsialisiert das Ethernet Modul und setzt die entsprechenden IP- und MAC-Adressen, danach wird ein TCP Server auf Port 80 gestartet, und übermittelte Pakete über UART ausgegeben.
In \texttt{socket.c} wird eine Socket API, welche der POSIX Socket API ähnlich ist, zur Verfügung gestellt. Das Headerfile \texttt{socket.h} enthält hierbei nur die Funktionsdeklarationen. Anders als bei der POSIX Socket API, muss hier jeder Socket manuell eine ID \textbf{vor} dem Erstellen erhalten. Diese ID muss zwischen 1 und 4 liegen, und repräsentiert die 4 Sockets (Register und Speicher), welche am Ethernet-Controller vorhanden sind.
Der Code wurde größtenteils von der entsprechenden Arduino Library \cite{arduino:ethernet} übernommen und auf C adaptiert.
Der Ethernet Controller selbst ist ein W5100 \cite{arduino:ethernetchip}. Dieses Headerfile enthält sämtliche Funktionsdeklarationen für diesen Controller, aber auch structs und enums welche die verschiedenen Register und Memory Bereiche spezifizieren.
Der Code wurde größtenteils von der entsprechenden Arduino Library \cite{arduino:ethernet} übernommen und auf C adaptiert.
