Android Controlled Audioprocessor (ACA)

Transkript

1 Fachhochschule Nordwestschweiz Hochschule für Technik Bachelor Thesis Elektro- und Informationstechnik Android Controlled Audioprocessor (ACA) Studenten: Nils Frey Jannick Keller Betreuender Dozent: Prof. Dr. Markus Hufschmid 16. August 2013

2 Abstract Es soll ein exibles System zur Verarbeitung von Audiosignalen entwickelt werden, welches für eine Vielzahl von DSV-Anwendungen wie z.b. als Equalizer oder adaptives Filter eingesetzt werden kann. Als Grundlage dieses Systems dient das im Projekt 5 entwickelte DSP-Board, welches mit einem Bluetooth Modul erweitert werden soll. Das Laden der Anwendungen auf das DSP-Board soll mit einem Android Tablet durchgeführt werden, welches gleichzeitig auch als Bediengerät für die DSV- Anwendung dient. Um einen exiblen Aufbau mit verschiedenen Anwendungen realisieren zu können, wird auf dem DSP-Board ein Bootloader eingesetzt, welcher für das Laden neuer Signalverarbeitungsanwendungen auf das DSP-Board verantwortlich ist. Die Android Software ist so aufgebaut, dass ein Grundgerüst die Kommunikation mit dem DSP-Board, sowie die Verwaltung der verschiedenen Module übernimmt. Von dem entwickelten Grundgerüst (ACA) aus, können Module von der Projekthomepage heruntergeladen, verwaltet und die darin enthaltene DSV-Anwendung auf das DSP-Board geladen werden. Als erstes Modul wurde ein Filter Studio realisiert, welches verschiedene Tief-, Hoch- und Bandpässe implementiert. Diese können über die Android Benutzeroberäche eingestellt werden.

3 Inhaltsverzeichnis 1 Einleitung 3 2 Konzept 5 3 Hardware DSP-Board Bluetooth Adapter Datenübertragungsprotokoll 11 5 dspic Software Bootloader Struktur der Bootloader Software Bootloader Hauptablauf Uart Funktionen Framework Funktionen Memory Funktionen Android Software Android Grundgerüst Benutzeroberäche ACAMainActivity ACAMainService ACABluetoothManager DeviceListActivity DSPBoardCommunicationThread DownloadableModuleListActivity ModuleDetailActivity ACAUtilities ModuleManager ACABroadcastReceiver ACAContentProvider ACADatabaseHelper ModuleTable TransferFrame ModuleSelectArrayAdapter Module Filter Studio dspic Signalverarbeitung Initialisierungen Kommunikation Android Benutzeroberäche Service Zusammenfassung und Ausblick 54 9 Bibliographie 56 Nils Frey / Jannick Keller 1

4 A Anhang 57 A.1 Aufgabenstellung A.2 Bluetooth Adapterprint Layout A.3 Memory Organisation der letzten Flash Page A.4 Ehrlichkeitserklärung Nils Frey / Jannick Keller 2

5 1 Einleitung Musik, Sprache und verschiedenste Arten akustischer Signale wären aus unserem Alltag nicht wegzudenken. Wenn wir nicht gerade schlafen, gibt es kaum eine Stunde in der wir nicht mit Musik oder Sprache in Kontakt kommen. Bereits die alten Griechen hatten Freude an Musik! Heute haben wir den Vorteil, dass es diverse technische Hilfsmittel gibt, welche akustische Signale verstärken, dämpfen oder in irgendeiner Weise verarbeiten oder erzeugen. Speziell in der Musikbranche gibt es eine Vielzahl von Geräten; von einem Eektgerät, Loopgerät oder einem Equalizer bis hin zu einem Karaokegerät oder Mischpult. Aber auch im Amateurfunk und anderen Kommunikationssystemen gibt es Geräte zur Verarbeitung von Audiosignalen. All diese Geräte haben sind im Normalfall auf unterschiedlicher Hardware aufgebaut und benutzen unterschiedliche Eingabe und Ausgabeelemente. In diesem Projekt soll ein Gerät entwickelt werden, welches für möglichst viele der obigen Anwendungen eingesetzt werden kann und leicht zu bedienen ist. Als Grundlage dieser Systems dient das im Projekt 5 entwickelte DSP-Board, welches grundsätzlich mit einen Signalprozessor mit Audio Ein- und Ausgängen ausgestattet ist. Ausserdem verfügt dieses Board über 2 Erweiterungsports, an welchen weitere Hardware (z.b. Schalter, Taster, LEDs, ein Display, usw.) angeschlossen werden kann. Da die Anforderungen verschiedener Anwendung ganz unterschiedlich sind, wird als Eingabe- und Ausgabehardware ein Android Gerät verwendet. Dies kann ein Tablet, oder Smartphone sein, welches mit der Android Version 4.0 oder neuer läuft. Dies bringt den grossen Vorteil, dass softwaremässig diverse Konstellationen von Eingabegeräten (Schalter, Taster, Slider, Checkboxen, Radio Buttons, Eingabefelder und viele mehr) erzeugt werden können. Ausserdem verfügen Android Geräte mit ihren hochauösenden Displays und Lautsprecherausgängen über Ausgabeelemente, welche praktisch allen Anwendungen genügen. Um dies zu ermöglichen ist eine Kommunikation zwischen dem DSP-Board und dem Android Gerät über Bluetooth notwendig. Praktisch alle Android Geräte unterstützen Bluetooth und beim DSP-Board kann einer der beiden Erweiterungsports dazu verwendet werden, einen Bluetooth Chip anzusteuern. Somit ist immer noch ein Erweiterungsport für Speichererweiterungen oder andere Zusatzhardware vorhanden. Ein weiterer Vorteil, welcher ein Android Gerät als Bedienelement des DSP-Boards bietet, ist die Möglichkeit über das Android Gerät eine neue Signalverarbeitungssoftware auf den Signalprozessor zu laden. Um einen solchen Aufbau realisieren zu können, ist ein strukturierter und modularer Aufbau der Software, sowohl auf dem Signalprozessor, wie auch auf dem Android Gerät notwendig. Konkret bedeutet dies, dass auf dem Signalprozessor nebst der Signalverarbeitungsanwendung ein Bootloader laufen muss, welcher Funktionen wie das Laden einer neuer Anwendung oder Starten der vorhandenen Anwendung übernimmt. Die Android Software muss über ein Grundgerüst verfügen, welches unter anderem die Kommunikation mit dem DSP-Board regelt, sowie zur Verfügung stehende Anwendungen auf den Signalverarbeitungsprozessor laden und starten kann. Signalverarbeitungsanwendungen, wie z.b. ein Eektgerät oder Equalizer müssen dann einerseits aus einem Android Modul bestehen, welches zum Grundgerüst kompatibel ist und andererseits eine C Programm beinhalten welches auf den Signalprozessor geladen werden kann. Es ist uns in diesem Projekt gelungen, das DSP-Board aus dem Projekt 5 mit einem Bluetooth- Adapter zu erweitern, sodass eine Kommunikation mit einem Android Gerät möglich ist. Wir konnten einen Bootloader für den Signalprozessor schreiben, welcher seine Grundfunktionalität erfüllt sowie ein Android Grundgerüst entwickeln, welches über ein festgelegtes Protokoll mit dem DSP-Board kommunizieren kann. Ausserdem haben wir als erste Signalverarbeitungsanwendung ein Filter Studio entwickelt, welches sowohl auf dem Signalverarbeitungsprozessor als auch als Android App läuft. Dieses Filter Studio verfügt über ein Set von vordenierten Tief- und Hochpassltern, welche auf das Eingangssignal des DSP-Boardes angewandt werden können. Des weiteren können mit dem Filter Studio Bandpasslterungen durchgeführt werden, bei welchen zwischen vier verschiedenen Band- Nils Frey / Jannick Keller 3

6 breiten ausgewählt werden kann und dessen Mittenfrequenz vom Benutzer wählbar ist. In diesem Fachbericht wird zu Beginn das Konzept dieses Systems Android Controlled Audioprocessor detailliert erklärt. Des weiteren ist die Anpassung der Hardware durch hinzufügen eines Bluetooth Adapters dokumentiert und es wird beschrieben, nach welchem Protokoll die Kommunikation zwischen dem Android Gerät und dem DSP-Board aufgebaut ist. Die Software, welche einerseits für den Signalprozessor und andererseits für die Android Geräte geschrieben wurde, ist so dokumentiert, dass der Aufbau und der Ablauf der Software verständlich wird. Um jedoch Details über die konkrete Implementierung der einzelnen Funktionen und Klassen zu erhalten, muss auf den Quellcode, welcher auf der mitgelieferten CD zu nden ist, zurückgegrien werden. Der ozielle Auftrag für dieses Projekt bendet sich im Anhang A.1 dieses Berichtes. Nils Frey / Jannick Keller 4

7 2 Konzept Bei dem im Rahmen dieser Bachelor Thesis entwickelten System Android Controlled Audioprocessor handelt es sich, wie bereits in der Einleitung beschrieben, um ein System, bestehend aus dem DSP-Board, welches mit einem Bluetooth Modul erweitert wurde, sowie einem Android Gerät. Das DSP-Board verfügt über zwei Erweiterungsports, von welchen einer für das Bluetooth Modul verwendet wird und der andere noch für Speichererweiterungen oder andere Hardware zur Verfügung steht. Die Erweiterungsports werden vom Signalprozessor des Typ dspic256mu806 über Peripheral Port Select (PPS) angeschlossen. Dadurch können fast alle Funktionen des dspic an die Erweiterungsports geschaltet werden. Um auf dem Anroid Gerät mehrere DSV-Anwendungen (digitale Signalverarbeitungsanwendungen) verwalten und auf das DSP-Board laden zu können, muss die Software strukturiert Aufgebaut werden. Abbildung 2.1 stellt den konzeptionellen Aufbau graphisch dar. Abbildung 2.1: Gesamtübersicht Wie in der obigen Abbildung dargestellt ist, beinhaltet die Android Software nebst den Modulen für die verschiedenen Anwendungen ein Grundgerüst. Über dieses Grundgerüst läuft die gesamte Kommunikation zwischen dem DSP-Board und den Modulen. Ausserdem können mit dem Grundgerüst neue Module von der Projekthomepage 1 heruntergeladen und installiert werden. Auch das Laden der Module auf den dspic, sowie weiteren Funktionen, wie deinstallieren von Modulen wird im Grundgerüst erledigt. Die Module bestehen grundsätzlich aus der Hex-Datei (Kompilierter C-Code) welche auf das DSP- Board geladen werden kann, dem Android Programm welches das Signalverarbeitungsprogramm steuert und einer XML-Datei in welcher Information über das Modul abgelegt sind. Auch auf dem DSP-Board muss die Software so gestaltet sein, dass es Möglich ist, einzelne neue Module über die Bluetooth Schnittstelle zu installieren und auszuführen. Dazu wird ein Bootloader verwendet, welcher sich in einem separaten Bereich des Flash-Speichers bendet und falls keine Anwendung installiert ist, automatisch ausgeführt wird. Hauptteil der dspic Software stellt jedoch die eigentliche DSV-Software dar. Diese kommuniziert allerdings nicht über den Bootloader mit dem Android Gerät, sonder selber direkt über das Bluetooth Modul mit dem Android Grundgerüst. Damit das Android Grundgerüst überprüfen kann, was für eine Anwendung zur Zeit auf dem DSP Board installiert ist, berechnet es bei der Installation eines Moduls den MD5-Hashwert des Inhaltes der Hex-Datei. Dieser MD5-Wert wird immer nach dem senden des Programmcodes dem Bootloader gesendet. Der Bootloader schreibt diesen Wert dann in den letzten Bereich des nichtüchtigen Flash- Speichers. Somit kann das Android Grundgerüst, u.a. wenn es neu gestartet wird, den gespeicherten 1 Nils Frey / Jannick Keller 5

8 MD5-Hashwert vom Bootloader abfragen und weiss, was für eine Applikation gerade auf dem dspic installiert ist. Der Bootloader selbst verfügt über eine zweistellige Versionsnummer, welche das Android Gerät ebenfalls abfragen kann um die Aktualität des Bootloader überprüfen zu können. Die Liste möglicher Anwendungen, für welche der ACA eingesetzt werden könnte ist sehr gross. In der Tabelle 2.1 sind nur einige Beispiele in den Bereichen Musik, Kommunikation und Messgeräte aufgeführt. Musik Messungen Kommunikation Eektgerät Spektrum Analyzer Modulator/Demodulator (Amateurfunk) Equalizer Bodediagramm Adaptives Filter (Amateurfunk) Filter SNR Stimmverzerrung Loopgerät Klirrfaktor Noisecancelling Tonhöhe verändern Geschwindigkeit verändern Tabelle 2.1: Mögliche Anwendungen unterteilt in Gruppen Bei den Anwendungen aus Tabelle 2.1 handelt es sich keinesfalls um eine vollständige Aufzählung sämtlicher Anwendungen, sondern stellen lediglich einige Möglichkeiten dar. Es wurden auch nicht alle Anwendungen genau auf deren Umsetzungsmöglichkeit untersucht. Um allerdings grob abschätzen zu können, was mit der Hardware des ACA möglich ist und was nicht sind in Tabelle 2.2 die wichtigsten Kenngrössen des verwendeten Signalprozessors dspic33ep256mu806 aufgelistet. Programmspeicher Datenspeicher CPU Geschwindigkeit 256KB Flash 28KB RAM 70 MIPS Tabelle 2.2: Prozessor Kennwerte Diese Kenngrössen reichen bereits aus, um gewisse Aussagen zu der Realisierbarkeit von Anwendungen zu machen. Nebst dem dspic, bendet sich auch ein Audiocodec auf dem Board, welcher die A/D- und D/A-Wandlung der Audiosignale übernimmt. Dieser kann auf unterschiedliche Abtastraten konguriert werden und auch die Auösung der A/D- und D/A-Wandlung kann geändert werden. Wenn man aber von einer Abtastrate von 48 khz und einer A/D-Wandlung von 16 Bit ausgeht, erhält man für ein Stereosignal 192 kb Daten pro Sekunde. Bei den verfügbaren 28 KB RAM könnten die Audiodaten von nicht einmal 150 ms im Datenspeicher abgelegt werden. Sämtliche Anwendungen, welche die Audiodaten über längere Zeit speichern müssen (z.b. Loopgerät) können folglich ohne Zusatzhardware nicht implementiert werden. Als Speichererweiterung können mehrere Varianten in Frage kommen. Die Anschlussmöglichkeit ist durch den zweiten Erweiterungsport gewährleistet. Eine Möglichkeit wäre, zusätzliches RAM über den Erweiterungsport anzuschliessen. Falls allerdings die Möglichkeit bestehen sollte, die Daten einfach auf einem Computer übertragen zu können, wäre unter Umständen eine SD-Karte zu bevorzugen. Der Programmspeicher ist mit 256 KB relativ Gross und sollte, falls das Programm nicht sehr komplex wird, ausreichen. Auch die CPU Geschwindigkeit ist mit 70 MIPS (million instructions per second), im Vergleich zu der älteren Generation dspic von Microchip mit 40 MIPS, schnell. Bei Anwendungen, welche in Echtzeit aufwändige Rechenoperationen durchführen müssen oder wenn die Abtastfrequenz auf 96 khz erhöht wird, muss auch genau abgeklärt werden ob diese Geschwindigkeit Nils Frey / Jannick Keller 6

9 ausreicht. Damit die Android Software Modular aufgebaut ist und leicht um eine neue Anwendung erweitert werden kann, ist das Grundgerüst eine eigene App (ACA) und jedes Modul ist ebenfalls eine vollständige App. Im Moment benden sich alle Apps sowohl auf der Projektwebsite 2 zum Download, können aber auch aus dem Google Play Store installiert werden. Die einzelnen Module für verschiedene Anwendungen sind für sich allerdings nicht Funktionsfähig und können nur von der ACA App aus verwaltet und gestartet werden. Das herunterladen und installieren einer neuen Anwendung kann ebenfalls von der ACA App aus gemacht werden. Weil der Anwender ausser der laufend Anwendung bedienen noch andere Dinge auf dem Smartphone oder Tablet erledigen möchte ist die Software so aufgebaut, dass die Bluetooth Verbindung zum DSP-Board erst abbricht, wenn die App explizit beendet wird. Dadurch soll es auch möglich sein andere Apps auf dem Android Gerät zu verwenden, ohne dass die laufende Signalverarbeitungsanwendung auf dem DSP-Board dadurch unterbrochen oder gestört wird. Die Verbindung des Android Geräts mit dem DSP-Board kann von der ACA App aus aufgebaut werden. Beim ersten Verbindungsaufbau müssen die Geräte noch gepaart werden. Falls das DSP- Board (Bluetooth Modul RN42-Bxxx) nach einem Passwort fragt, muss 1234 eingegeben werden, sofern dies nicht geändert wurde. Dadurch dass mit Bluetooth Punkt-Punkt Verbindungen aufgebaut werden und jedes Bluetooth Modul des DSP-Board über eine eigene MAC-Adresse verfügt, ist immer sichergestellt, dass nur ein Android Gerät mit einem DSP-Board verbunden sein kann. Jedoch könnten problemlos gleichzeitig zwei verschiedene Android Geräte mit zwei verschiedenen DSP-Boards verbunden sein. 2 Nils Frey / Jannick Keller 7

10 3 Hardware Da dieses Projekt auf dem Projekt 5 DSP-Board für Labor und Unterricht aufbaut ist, ist die Hardware des Signalverarbeitungsboards bereits vorhanden und weil das User Interface auf Android läuft, musste auch kein Bediengerät entwickelt werden. Die Verarbeitung der Audiosignale geschieht auf dem DSP-Board, welches unter anderem mit einem dspic33ep256mu806 der Firma Microchip, einem Wolfson Auciocodec WM8731, drei LEDs, drei Tastern und zwei Erweiterungsports ausgestattet ist. Das Board verfügt über einen Line-In Stereo sowie einen Mikrofon Mono Eingang, und einen Line-Out Stereo sowie einem Kopfhörer Stereo Ausgang. Sämtliche Audioanschlüsse sind mittels 3.5mm Klinkebuchsen realisiert. Aufbau und Funktionsweise des DSP-Boardes sind im Kapitel 3.1 kurz zusammengefasst. Detailliertere Informationen über die Hardware des Boardes können im Fachbericht des Projekt 5 nachgelesen werden 3. Um aus diesem DSP-Board und einem Android Gerät einen Android Controlled Audioprocessor (ACA) zu bauen, ist jedoch noch ein Kommunkationskanal zwischen den beiden Geräten erforderlich. Diese Kommunkation wurde mit einem Bluetooth-Chip RN-42, welcher auf einem Adapterboard an einem der beiden Erweiterungsports des DSP-Boards angeschlossen wurde, realisiert. Weil eine drahtlose Kommunikation dem Benutzer mehr Freiheit gibt und praktisch jedes Android Gerät über WiFi sowie Bluetooth verfügt, standen diese beiden Technologien zur Auswahl für die Kommunikation zwischen dem DSP-Board und dem Android Gerät. Da Bluetooth Module günstiger sind als WiFi Module, sehr einfach über eine Uart Schnittstelle ansteuerbar sind und die Übertragungsrate, sowie auch Reichweite von Bluetooth für unsere Anwendung locker ausreichen, haben wir uns für ein Bluetooth Modul entschieden. Die Übertragungsrate der Verbindung ist für diese Anwendung nicht sehr entscheidend, da es nicht vorgesehen ist live Audiodaten Da zur Zeit auch mehrere andere Projektgruppen am Institut für Mikroelektronik mit dem Bluetooth Modul RN-42 arbeiten, und dieses daher für uns sofort verfügbar war, wurde dieses Modul verwendet. Detaillierte Angaben zum Bluetooth Adapterprint benden sich im Kapitel DSP-Board Kernstück des DSP-Boards stellt ein dspic (Digital Signal Controller) von Microchip dar. Es handelt sich dabei um einen Controller vom Typ dspic33ep256mu806, mit 256KB Program Memory (+24KB Auxiliary Flash), 28KB RAM und einer Prozessorgeschwindigkeit von bis zu 70 MIPS. Programmiert kann dieser Prozessor über ICSP mit dem PICKit 3 werden und er ist mit einer I2C, sowie einer I2S Schnittstelle mit dem Audiocodec vom Typ WM9831 verbunden. Abbildung 3.1 gibt einen Überblick, wie die verschiedenen Komponenten auf dem Board miteinander vorbunden sind. Die I2S-Schnittstelle zwischen dem dspic und dem Audiocodec dient zum Austausch der Audiodaten, und die I2C-Schnittstelle zur Konguration des Audiocodecs. Der WM8731 verfügt über stereo 24bit sigma delta ADCs und DACs und unterstützt in der aktuellen Konguration die Abtastraten von 8kHz, 32kHz, 48kHz und 96kHz. Da dieses Board im Rahmen des Projektes 5 entwickelt wurde, benden sich Informationen zur Hardware im entsprechenden Fachbericht Nils Frey / Jannick Keller 8

11 Abbildung 3.1: Komponenten auf dem DSP-Board 3.2 Bluetooth Adapter Beim verwendeten Bluetooth Modul RN-42 handelt es sich um ein Class 2 Bluetooth Modul, welches Bluetooth v2.0 + EDR (Enhanced Data Rate) unterstützt, über eine integrierte Antenne verfügt und über UART (Universal Asynchronous Receiver/Transmitter) ansteuerbar ist. Die genauen Spezikationen sind im Datenblatt [7] nachzulesen. Um mit dem dspic über UART kommunizieren zu können sind die beiden Pins UART_RX (Pin 13) und UART_TX (Pin 14) des Bluetooth Moduls anzusteuern. Ausserdem muss das Bluetooth Modul mit 3.3V versorgt werden und der Status Pin, welcher signalisiert ob das Bluetooth Modul mit einem Gerät verbunden ist, wird zum dspic geführt. Sämtliche anderen Pins des RN-42 müssen nicht angeschlossen werden, sie werden mit internen pullup resp. pulldown Widerständen auf den Defaultwert gezogen. Das Modul wird mit einer Baud rate von 115K betrieben, was ebenfalls Standard ist. Eine Uart Schnittstelle kann beim dspic an allen RPx Pins eingerichtet werden und das Einlesen des Status ist an sämtlichen digitalen Pins des dspic möglich. An beiden Erweiterungsports des DSP-Boards ist die +5V Speisung verfügbar. Dank Peripheral Port Select (PPS), können die gewünschten Funktionen an beinahe alle Pins des dspic gemappt werden. Somit müssen lediglich 5 Leitungen auf das Adapterboard geführt werden und der kleinere der beiden Erweiterungsports (14 Pin DIL Stecker) kann verwendet werden. Weil das Bluetooth Modul mit 3.3 Volt gespeist werden muss, aber die 5 Volt Speisung auf die Erweiterungsports geführt ist, enthält der Adapterprint nebst dem Footprint für das Bluetooth Modul und der DIL Buchse noch einen Spannungswandler von 5 Volt nach 3.3 Volt. Abbildung 3.2 zeigt ein Bild des Adapterprints mit Beschriftung, welche Signale über welche Pins geführt werden. Beim Adapterprint in Abbildung 3.2 sind noch die beiden Pins UART_CTS und UART_RTS auf das DSP-Board geführt, diese werden allerdings nicht benötigt. In Tabelle 3.1 ist übersichtlich dargestellt, welche Funktionen an welche Pins des dspic geführt sind, und über welche Pins sie zum RN-42 Modul gelangen. Das Layout des aktuellen Adapterprints bendet sich im Anhang A.2 dieses Berichtes, wobei es sich bereits um eine überarbeitete Version des in Abbildung 3.2 dargestellten Prints bei welcher zwei Nils Frey / Jannick Keller 9

12 Abbildung 3.2: Bluetooth-Adapterprint DSP-Board Erweiterungsport Bluetooth Modul (RN-42) dspic Pin Funktion Name Pin Pin Name 42 Status RD PIO2 54 UART RX RD6 / RP UART TX 55 UART TX RD7 / RP UART RX - Speisung +5V 1 11 VDD - Speisung GND 14 1, 12, 28, 29 GND Tabelle 3.1: Verbindungen vom DSP-Board zum Bluetooth Modul unbenötigte Leitungen entfernt wurden. Nils Frey / Jannick Keller 10

13 4 Datenübertragungsprotokoll Um die Kommunikation zwischen dem DSP-Board und dem Android Gerät klar zu denieren, wurden einerseits ein Set von Befehlen deniert, welche im Bootloader sowie im Android Grundgerüst implementiert sind, sowie auch Befehle welche von jeder DSV-Anwendung ausgeführt werden können müssen. Ein Befehl ist immer ein Byte lang und kann von einer beliebigen Anzahl Daten gefolgt sein. Bei der Entwicklung einer neuen DSV-Anwendung wird empfohlen, für anwendungsspezische Befehle die Codierungen 0x21 und fortlaufend zu verwenden damit keine bereits für andere Funktionen verwendete Befehle benutzt werden. In Tabelle 4.1 bendet sich eine Zusammenstellung der Hexadezimalwerte sämtlicher Befehle für ein sehr einfaches Beispielprogramm, welches nichts Anderes tut als ein LED ein- und auszuschalten. Befehl Funktion Bootloader Befehle 0x01 Bootloader Version auslesen 0x02 Flash löschen 0x03 Flash programmieren 0x04 CRC auslesen 0x05 DSV-Anwendung starten 0x06 MD5-Hash schreiben 0x07 MD5-Hash lesen Allgemeine Anwendungsbefehle 0x11 Zum Bootloader wechseln 0x12 MD5-Hash lesen 0x13 DSV-Anwendung resetten Anwendungsspeziesche Befehle 0x21 LED einschalten 0x22 LED ausschalten Tabelle 4.1: Übersicht der Befehle Die Kommunikation über Bluetooth ist so aufgebaut, dass das User Interface (Android Gerät) Master der Verbindung ist und der dspic lediglich als Slave arbeitet, die Befehle entgegennimmt, ausführt und bestätigt, indem er dem Android Gerät den erhaltenen Befehl zurücksendet. Der Befehl Bootloader Version auslesen kann vom User Interface dazu genutzt werden um zu überprüfen, ob die aktuelle Bootloader Version auf dem DSP-Board läuft. Der dspic sendet auf diesen Befehl dem Android Gerät nebst dem erhaltenen Befehl 0x01 die Major Version und die Minor Version der Bootloadersoftware zurück (z.b. 0x01-0x01-0x03). Wie diese Daten in ein Frame verpackt werden, wird weiter unten beschrieben. Der Befehl Flash löschen löscht das komplette Program Flash des dspic, selbstverständlich mit Ausnahme des Auxiliary Flash, wo sich der Bootloader bendet. Als Rückgabewert wird lediglich der Befehl selbst zurückgesendet. Beim Befehl Flash programmieren, werden die Daten, welche anschliessend an den Befehl übermittelt werden ins Program Flash geschrieben. Die Daten müssen dabei im Intel HEX-Format übermittelt werden. Dieses Format ist so aufgebaut, dass zuerst in einem Byte bestimmt wird, wie viele Daten übermittelt werden, anschliessend wird die Adresse angegeben, wo die Daten hingeschrieben werden müssen. Danach wird gefolgt, von den eigentlichen Daten noch angegeben, um welchen Typ Nils Frey / Jannick Keller 11

14 der Übertragung es sich handelt und zum Schluss wird noch eine einfache, ein Byte lange Checksumme angehängt. Weil beim dspic nebst der Instruktions Wortbreite auch die Program Memory Wortbreite 24 bit beträgt, muss beim Intel HEX Format nach drei Byte Daten jeweils ein Byte mit Nullen übertragen werden. Genauere Informationen zum Intel HEX-Format sind in den Quellen [11] und [13] nachzulesen. CRC auslesen ist dazu gedacht, aus den Daten im Program Flash den CRC-Wert zu berechnen und zurückzugeben. Dieser Befehl wird allerdings momentan nicht verwendet. Um eine spätere Verwendung ohne viel Aufwand zu ermöglichen und da genügend Programmspeicher im Auxiliary Flash vorhanden ist, wurde dieser Befehl, welcher vom Microchip Bootloader [6] übernommen wurde trotzdem im Bootloader implementiert. Der Befehl DSV-Anwendung starten stoppt den Bootloader sofort und wechselt in die DSV- Anwendung, falls eine istalliert ist. Achtung, auf diesen Befehl erfolgt keine Bestätigung, nicht einmal der Befehl selbst wird zurückgesendet. Mit dem Befehl MD5-Hash schreiben kann der MD5-Wert des Programmcodes einer DSV- Anwendung ins nichtüchtige Program Flash geschrieben werden. Genauere Angaben in welchen Speicherbereich geschrieben wird, benden sich im Kapitel Auch bei diesem Befehl besteht der Rückgabewert lediglich aus dem Befehl selbst. Mit dem Befehl MD5-Hash lesen kann der mit dem Befehl MD5-Hash schreiben geschriebene Wert wieder ausgelesen werden. Dies ist mit dem Hexcode 0x07 möglich, wenn der Bootloader ausgeführt wird oder mit dem Hexcode 0x12 aus einer DSV-Anwendung heraus. Der Befehl Zum Bootloader wechseln kann aus einer DSV-Anwendung ausgeführt werden und ist das Pendant zum Befehl DSV-Anwendung starten. Er ermöglicht einen Wechsel von der DSV- Anwendung in den Bootloader. Auch auf diesen Befehl erfolgt kein Rückgabewert! Wie es der Name bereits sagt, kann mit dem Befehl DSV-Anwendung resetten die laufende DSV- Anwendung zurückgesetzt und nochmal von vorne ausgeführt werden. Um eine korrekte Übertragung zu gewährleisten, und signalisieren zu können, wann ein neuer Befehl oder Daten übermittelt wird und wann eine Übertragung zu Ende ist, werden sämtliche Daten in einem Frame eingebettet und unter anderem auch ein CRC von den Daten und dem Befehl mitgesendet. Der Aufbau der Frames wurde aus dem Bootloader dspic33e/pic24e von Microchip [6], welchen wir als Vorlage für den eigenen Bootloader verwendet haben, übernommen. Um Start und Ende eines Frames zu kennzeichnen werden die Kontrollcharakter in Tabelle 4.2 eingesetzt: Bezeichnung HEX Wert Beschreibung SOH 0x01 Kennzeichnet Start eines Frames EOT 0x04 Kennzeichnet Ende eines Frames DLE 0x10 "Data link escape"wird vor jedem Kontroll Charakter eingefügt Tabelle 4.2: Kontroll Charakter Jedes Frame wird stets nach folgendem Muster zusammengesetzt, bevor es Übermittelt wird: < SOH > [< Daten >...] < CRCL >< CRCH >< EOT > <... > Steht für ein übertragenes Byte und [...] steht für eine unbestimmte Anzahl übertragener Bytes. CRCL und CRCH sind das CRC low Byte respektive high Byte des CRC Codes welcher von Nils Frey / Jannick Keller 12

15 jedem Frame gerechnet wird. Bei der Berechnung des CRC Codes werden nur die Befehle und die Daten berücksichtigt, sämtliche Kontroll Charakter des Frames werden nicht berücksichtigt. Bei der Berechnung des CRC Codes wird der Standard CRC CCIT T (XM odem) verwendet, welcher immer 16 Bit lang ist. Der CRC Code dient dazu verizieren zu können ob die Daten korrekt übermittelt wurden oder ein Übertragungsfehler aufgetreten ist. Nils Frey / Jannick Keller 13

16 5 dspic Software Die Struktur sämtlicher Software des Android Controlled Audioprocessor soll modular aufgebaut sein, sodass es einfach möglich ist, eine neue DSV-Anwendung (Signalverarbeitungsanwendung) zu entwickeln und benutzen. Dies setzt voraus, dass auf dem dspic nebst der aktuell verwendeten DSV-Anwendung (z.b. Filter Studio) ein Bootloader läuft welcher folgende Funktionen übernimmt: Starten der sich im dspic Flash bendenden DSV-Anwendung. Laden eines neuen Programm ins Flash des dspic. Löschen des dspic Flash (ohne den Bootloader selbst zu löschen). Von Android Gerät empfangener MD5-Hash einer DSV-Anwendung abspeichern. Abgespeicherten MD5-Hash auslesen und dem Android Gerät senden. Der dspic33ep256mu806 verfügt über eine, vom Program Flash getrennte, Auxiliary Flash Section, welche sich optimal für die Implementierung eines Bootloader eignet. Die eigentliche Anwendung bendet sich somit im Program Flash und kann vom Bootloader aus gelöscht, neu beschrieben oder ausgeführt werden. Abbildung 5.1: Übersicht Ablauf der dspic Software Der dspic ist so konguriert, dass bei einem Reset, der Bootloader und nicht die DSV-Anwendung ausgeführt wird. Deshalb sind zu Beginn des Booloader einige Abfragen nötig, um zu entscheiden ob sofort zur aktuellen DSV-Anwendung gewechselt werden soll oder der Upgrade Modus des Bootloaders ausgeführt werden muss. Wie der Gesamtablauf des Bootloaders aufgebaut ist, wird in Abbildung Nils Frey / Jannick Keller 14

17 5.1 verdeutlicht. Als Resetadresse ist die erste Adresse des Bootloaders deniert und die wichtigsten Initialisierungen des DSP-Board (u.a. der Tackt) werden initialisiert. Anschliessend werden drei Bedingungen abgefragt, ob in den Upgrade Modus (führt die oben beschriebenen Bootloader Funktionen aus) gewechselt werden soll, oder ob sofort die DSV-Anwendung gestartet werden kann. Falls der Taster SW 1 gedrückt wird, sich keine DSV-Anwendung im Flash bendet oder von der DSV- Anwendung der Befehl Zum Bootloader wechseln erfolgte, wird in den Upgrade Modus gewechselt. Dieser wird erst wieder verlassen wenn vom Bediengerät der Befehl DSV-Anwendung starten erfolgte. Obwohl es vorgesehen ist, verschiedene Anwendungen zu haben, hat es aus zeitlichen Gründen lediglich für die Realisierung einer DSV-Anwendung (Filter Studio) gereicht. Es handelt sich dabei um eine Anwendung, mit welcher verschiedene Filter auf des Eingangssignal angewendet werden können. Eine detaillierte Beschreibung dieser Anwendung bendet sich in Kapitel 7. Beim Wechsel vom Bootloader in die DSV-Anwendung wird jedes Mal ein Byte mit dem Hexadezimalwert 0x10 und beim Wechsel von der DSV-Anwendung in den Bootloader das Byte 0x00 dem Android Gerät übermittelt, damit dieses stets weiss, in welchem Zustand sich der dspic gerade bendet. Da es den Rahmen dieses Fachberichtes sprengen würde, den gesamten Programmcode aufzulisten und zu dokumentieren, wird in den folgenden Kapiteln versucht die Struktur und der Ablauf des Codes klarzumachen und es werden nur wenige, besondere, oder für das Verständnis wichtige Codeausschnitte dargestellt. Der gesamte Quellcode sämtlicher Software bendet sich jedoch auf der mit dem Fachbericht mitgelieferten CD. 5.1 Bootloader Um den Bootloader nicht von Grund auf selber entwickeln zu müssen, wurde als Vorlage der Bootloader [6] dspic33e/pic24e Bootloader vom Microchip verwendet und an die die DSP-Board Hardware angepasst. Dieser Bootloader unterstützt bereits die in Abbildung 5.1 dargestellte Struktur und ist für DSPs ausgelegt welche über ein Auxiliary Flash Segment verfügen. Der dspic33ep256mu806 verfügt über ein Auxiliary Flash Segment, wobei es sich um einen Bereich des Program Flash handelt, welcher vom normalen Program Flash Memory getrennt ist und nebst 24KB Program Flash Memory, über einen eigenen Interrupt Vector Table, eine GOTO Anweisung sowie eine Reset Adresse verfügt. Dies ist äusserst komfortabel für die Implementierung eines Bootloaders, da über die eigene Reset Adresse einfach ein Wechsel in den Bootloader möglich ist und es, dank der Trennung vom normalen Program Flash, sehr einfach möglich ist vom Bootloader aus eine neue Anwendung ins Flash zu programmieren ohne den Bootloader selbst zu überschreiben. Der Bootloader von Microchip ist wie in Abbildung 5.2 aufgebaut, mit einem Framework Task und einem Transport Layer Task, welche pollend aufgerufen und ausgeführt werden. Beim ACA wird als Transport Layer UART verwendet, um mit dem Bluetooth Modul RN-42 zu kommunizieren Struktur der Bootloader Software Um eine gute Übersichtlichkeit zu erhalten, wurde die Bootloader Software in vier C-Dateien unterteilt. Die Tabelle 5.1 gibt eine Übersicht, welche Funktionen sich in welchen C-Dateien benden. Diese Tabelle dient lediglech dazu einen Überblick über die vorhandenen Funktionen zu schaen. Eine Beschreibung der einzelnen Funktionen folgt in den anschliessenden Abschnitten. Damit der Bootloader auf der DSP-Board Hardware korrekt läuft, müssen einige Kongurationsbits gesetzt werden. Die entsprechenden Kongurationen sind aus dem Codeausschnitt 5.3 ersichtlich. Besondere Beachtung ist den beiden Kongurationsbits aus dem Register _F ICD zu schenken: Das Bit RST P RI_AF wird unbedingt benötigt, damit nach einem Reset das Auxiliary Flash, wo sich Nils Frey / Jannick Keller 15

18 Funktion Beschreibung Bootloader.c void main() Hauptfunktion des Bootloaders. void InitializeBoard() Führt notwendige Initialisierungen durch. void JumpToApp() Wechsel von Bootloader zur DSV-Anwendung. BOOL ValidAppPresent() Gibt T rue zurück falls eine DSV-Anwendung im Flash ist. BOOL ForceBootloaderMode() Gibt T rue zurück falls F orcebootloaderm ode gesetzt ist. void backupmd5() Liest den MD5 Wert aus dem Flash aus und speichert ihn in einer Globalen Variable. void generateintelhex() Generiert den Intel Hex Code aus dem MD5 Wert. Uart.c void UartInit() Initialisiert die Uart Schnittstelle für die Bluetooth Verbindung. void UartTask() Uart Hauptfunktion: Verantwortlich für Empfang und Senden von Daten über Bluetooth (Uart). BOOL GetChar(UINT8 *byte) Liest Daten aus dem Uart Rx Register aus (Empfangen). void PutChar(UINT8 txchar) Schreibt Daten ins Uart Tx Register (Senden). Framework.c void FrameWorkTask() Führt die Funktion HandleCommand() aus falls ein gültiges Frame vorliegt. void HandleCommand() Unterscheidet was für ein Befehl empfangen wurde und führt ihn aus. void BuildRxFrame(UINT8 *RxData, INT16 RxLen) Bildet aus den Empfangenen Daten ein Frame und kontrolliert den CRC. UINT GetTransmitFrame(UINT8* Bu) Bildet aus den zu sendenden Daten ein Frame. void WriteHexRecord2Flash(UINT8* HexRecord, UINT totalhex- Schreibt Daten, die im Intel Hex Format empfangen wurden ins Program Flash. RecLen) UINT16 CalculateCrc(UINT8 *data, UINT32 len) Berechnet den CRC Wert. vuint16 CalculateCrcProgMem(UINT32 adress, UINT32 len) Berechnet CRC Wert aus dem Program Flash. Funktion wird nicht verwendet! BOOL ExitFirmwareUpgradeMode() Gibt T rue zurück falls der Upgrade Modus verlassen werden muss. DWORD ReadFlash(DWORD adress) Liest ein Wort aus dem Program Flash aus. NVMem.c UINT NVMemBlockErase() Löscht komplettes Program Flash (Ohne Auxiliary Program Flash). UINT NVMemErasePage(UINT32 address) Löscht eine Page aus dem Program Flash (1 Page entspricht 3KB Speicher) UINT NVMemWriteWord(UINT32 address, UINT32 data) Schreibt ein Wort an gewünschte Adresse. Tabelle 5.1: Übersicht der Funktionen des Bootloaders Nils Frey / Jannick Keller 16

19 Abbildung 5.2: Bootloader Architektur [6] der Bootloader bendet, ausgeführt wird und nicht das normale Program Flash. Das Kongurationsbit ICS_P GD2 ist unbedingt notwendig um debuggen zu können! Mit diesem Bit wird ausgewählt, über welchen ICD Communication Channel der dspic mit dem Programmer (PicKit 3) kommuniziert. Ein einfaches Programmieren des dspic ist möglich, ohne diese Bit zu setzen, für das Debuggen muss es allerdings zwingend gesetzt werden. Listing 5.3: Kongurationsbits 1 // Start up d e v i c e with I n t e r n a l FRC, then a u t o m a t i c a l l y switch to Primary O s c i l l a t o r with PLL 2 _FOSCSEL(FNOSC_PRIPLL & IESO_ON) ; 3 4 // D i s a b l e Clock Switching and Fail Safe Clock Monitor, Configure OSC1 as e x t e r n a l Clock Input, Configure OSC2 as Fcy Output 5 _FOSC(FCKSM_CSECMD & OSCIOFNC_OFF & POSCMD_EC & IOL1WAY_OFF) ; 6 7 _FWDT(FWDTEN_OFF) ; //Watch Dog d i s a b l e d 8 9 _FPOR(FPWRT_PWR128 & BOREN_ON) ; // Set Power on Reset Timer and e n a b l e Brown out Reset // RSTPRI_AF: Device w i l l obtain r e s e t i n s t r u c t i o n from Aux f l a s h 12 _FICD(ICS_PGD2 & RSTPRI_AF) ; // f o r debugging ICS_PGD2 has to be s e t! In den folgenden Abschnitten werden auch Codeausschnitte dargestellt. Dazu muss noch erwähnt werden, dass im Headerle GenericTypeDefs.h einige Denitionen vorgenommen wurden, wobei jedoch meistens der Name klar aussagt, worum es sich handelt. Folglich handelt es sich beispielsweise bei einem BOOL um ein Enum mit den Werten T RUE und F ALSE, oder ein BY T E wurde als unsigned char deniert. Es sind jedoch auch einige komplexere Verbunde (union) deniert, auf dessen Beschreibung wird hier allerdings verzichtet und muss aus dem Headerle GenericTypeDefs.h herausgelesen werden Bootloader Hauptablauf In diesem Abschnitt werden die Funktionen, welche sich in der Datei Bootloader.c benden, beschrieben. In dieser Datei bendet sich die main-funktion, welche den Ablauf des gesamten Bootloader deniert und Ursprung sämtlicher Funktionsaufrufe ist. Der Code der main-funktion, welcher im Listing 5.4 aufgeführt ist, wird detaillierter als die anderen Funktionen erklärt, da dieser Ablauf Nils Frey / Jannick Keller 17

20 wichtig für das Verständnis des Bootloader-Aufbaus ist. Die lokale Variable Result wird als Rückgabewert der NVMem-Funktionen benötigt, hat allerdings keine weitere Bedeutung für die Funktion des Ablaufes. Als erstes wird die Funktion InitializeBoard() aufgerufen, welche den Takt, die Uart-Schnittstelle und die Taster und LEDs initialisiert, sowie die Verwendung von Interrupts ermöglicht. Anschliessend werden die drei Bedingungen, welche bereits aus Abbildung 5.1 ersichtlich waren geprüft. Die Funktion F alidappp resent() gibt T RU E zurück falls irgendein anderer Wert als 0xF F F F F F in die Adresse 0 geschrieben wurde (beim Löschen des Flash wird 0xF F F F F F geschrieben). Die Funktion F orcebootloaderm ode() funktioniert genau gleich wie V alidappp resent(), ausser dass die Adresse 0x2AB00 überprüft wird. Dies ist diejenige Adresse welche von der DSV-Anwendung beschrieben werden muss, gefolgt von einem Reset, falls ein Wechsel in den Bootloader notwendig ist. 1 i n t main ( void ) { 2 3 BOOL Result ; 4 I n i t i a l i z e B o a r d ( ) ; 5 Listing 5.4: Bootloader main Funktion 6 // Enter firmware upgrade mode i f t h e r e i s a t r i g g e r or i f the a p p l i c a t i o n i s not v a l i d 7 i f (!SW1! ValidAppPresent ( ) ForceBootloaderMode ( ) ) { 8 9 backupmd5 ( ) ; // Backupt MD5 Hash i n Flash Address 0x2AB10 10 Result = NVMemErasePage(0 x2ab00 ) ; // Clear Command "Jump to Bootloader " ( Erase Flash Page ) 11 generateintelhex ( ) ; 12 WriteHexRecord2Flash(& w r i t e B u f f e r [ 0 ], 43) ; // Write MD5 Backup to Program Flash // I n d i c a t e s the Android Device that Bootloader i s running 16 PutChar (0 x01 ) ; 17 PutChar (0 x00 ) ; // Send 0x00 18 PutChar (0 x00 ) ; 19 PutChar (0 x00 ) ; 20 PutChar (0 x04 ) ; LED1_ON; // I n d i c a t e the u s e r that the Bootloader i s running while (! ExitFirmwareUpgradeMode ( ) ) // Be i n loop t i l l framework r e c i e v e s " run a p p l i c a t i o n " command from User I n t e r f a c e 25 { 26 UartTask ( ) ; // Run Transport l a y e r t a s k s 27 FrameWorkTask ( ) ; // Run frame work r e l a t e d t a s k s ( Handling Rx frame, p r o c e s s frame and so on ) 28 } 29 LED1_OFF; // Turn Bootloader I n d i c a t o r o f f 30 } JumpToApp ( ) ; // execute DSP A p p l i c a t i o n r e t u r n 0 ; 35 } Bevor dann in einer While-Schleife solange der UartT ask und der F ramew orkt ask ausgeführt werden bis ExitF irmwareu pgradem ode true zurück gibt, werden noch einmalig einige Funktio- Nils Frey / Jannick Keller 18

21 nen aufgerufen um das allenfalls gesetzte Force-Bootloader-Mode-Flag zu löschen, ohne dass der MD5-Wert welcher sich in derselben Page des Program Flash bendet, gelöscht wird. Dies ist nötig, weil beim Schreiben des Flash zwar jede Adresse einzeln beschrieben werden kann, beim Löschen muss allerdings immer eine ganze Page, was 3KB Daten entspricht, gelöscht werden. Die Funktion backupmd5 liest den MD5-Wert aus dem Flash aus und legt ihn in einer globalen Variable ab. Anschliessend wird die Page, in welcher sich das Force-Bootloader-Mode-Flag bendet, gelöscht. Weil zum Schreiben des MD5-Wertes, die bereits von Microchip im Bootloader implementierte Funktion W ritehexrecort2f lash verwendet wird, muss zuerst noch mit der Funktion generateintelhex der MD5-Hash in den Intel HEX Code gewandelt werden. Ist die Austrittsbedingung aus der while-schleife erfüllt, wird die Funktion JumpT oapp ausgeführt, was einen Wechsel ins normale Program Flash zur Folge hat Uart Funktionen In der Datei Uart.c benden sich vier Funktionen: Die Funktion U artinit wird von der Funktion InitializeBoard aufgerufen und Initialisiert die Uart2 Schnittstelle des dspic mit einer Baudrate von 115K. Ebenfalls in dieser Funktion wird die Uart2 Funktionalität des dspic auf die Pins gemappt an welchen sich das Bluetooth-Modul RN-42 bendet. In dem Upgrade Modus der main-funktion werden hintereinander der Uart-Task und der Framework- Task aufgerufen. Der U artt ask ist für das Einlesen der Daten, welche mit dem Bluetooth-Modul empfangen werden sowie das Senden von Daten über das Bluetooth-Modul verantwortlich. Jedes Mal, wenn der U artt ask (Listing 5.5) aufgerufen wird, wird überprüft ob neue Daten empfangen wurden und diese gegebenenfalls dem Framework weitergesendet, um daraus ein Fram zu erzeugen und sie verarbeiten zu können. Nach dem Empfangen werden immer auch sämtliche Daten, welche vom Framework in den Sendebuer T xbuf f gelegt wurden, über das Bluetooth-Modul gesendet. 1 void UartTask ( void ) 2 { 3 UINT8 TxLen ; 4 UINT8 Rx ; 5 UINT8 ptr ; 6 // Check i f any c h a r a c t e r i s r e c e i v e d. 7 i f ( GetChar(&Rx) ) 8 { 9 // Pass the bytes to frame work. 10 BuildRxFrame(&Rx, 1) ; 11 } 12 ptr = TxBuff ; 13 // Get transmit frame from frame work. 14 TxLen = GetTransmitFrame ( ptr ) ; 15 i f ( TxLen ) 16 { 17 // There i s something to transmit. 18 while ( TxLen ) 19 { 20 PutChar ( ( ptr++)) ; 21 } 22 } 23 } Listing 5.5: Uart Task Nils Frey / Jannick Keller 19

22 Die Funktion GetChar überprüft nur, ob neue Daten anliegen und falls ja, schreibt sie die Daten in die Variable Rx. P utchar macht nichts Anderes als die du sendenden Daten ins Transmit-Register des UART2 Interface zu schreiben Framework Funktionen In der Datei Framework.c werden aus den empfangen Daten Frames gebildet und diese auch verarbeitet. Die Funktion BuildRxF rame erhält Byte weise Daten vom Uart-Task und unterscheidet, ob es sich dabei um ein SOH, ein EOT, ein DLE, oder um normale Daten handelt. Falls es sich um normale Daten handelt, wird das Byte in den Receive-Buer geschrieben. Falls es sich um ein SOH handelt, wird ein neues Frame gestartet und somit die Länge des Receive-Buers auf Null zurückgesetzt. Falls das erhaltene Byte ein EOT ist, wird der CRC-Code der Daten im Receive-Buer berechnet um festzustellen, ob dieser mit dem mitgesendeten CRC-Code übereinstimmt. Falls es ich um ein DLE handelt, wird die boolean Escape gesetzt, um zu kennzeichnen, dass es sich beim folgenden Byte nicht um ein SOH, EOT oder DLE handelt. Mit GetT ransmitf rame wird aus den zu sendenden Daten ein Frame erzeugt. Dazu muss zuerst der CRC-Wert der Daten im Transmit-Buer gerechnet werden und anschliessend zu Beginn des Frames ein SOH, am Schluss ein EOT, sowie vor allen Hexadezimal werten 0x01, 0x04 oder 0x10, ein DLE hinzugefügt werden. Die Funktion HandleCommand führt für jeden Bootloader Befehl, aus Tabelle 4.1 die entsprechenden die entsprechenden Operationen durch. Beim Befehl Bootloader Version auslesen, wird lediglich die Versionsnummer, bestehend aus einer Major-Nummer und einer Minor-Nummer, zurückgesendet. Beim Befehl Flash löschen, wird die NVMem-Funktion N V M emblockerase ausgeführt und das gesamte Program Flash gelöscht. Handelt es sich um den Befehl Flash programmieren, wird durch Aufruf der Funktion W ritehexrecord2f lash der übermittelte Code ins Program Flash geschrieben. Bei der aktuellen Version werden beim Laden einer neuen DSV-Anwendung ins Program Flash jeweils nur 10 Byte Daten pro Befehl Flash programmieren mitgesendet, damit bei einem grossen Programm nicht ein riesiger Buer für die Zwischenspeicherung der Daten benötigt wird. Beim Befehl DSV-Anwendung starten wird lediglich der Boolean RunApplication auf True gesetzt, was zur Folge hat, dass beim nächsten Aufruf der Funktion ExitF irmwareu pgradem ode aus dem Bootloader Upgrade Modus, der Rückgabewert True erfolgt. Falls der Befehl MD5-Hash schreiben aufgerufen wurde, werden die dem Befehl folgenden Daten in das Intel HEX Format gewandelt und anschliessend mit der Funktion W ritehexrecord2f lash ins Flash geschrieben. Mit dem Befehl MD5 Hashlesen werden sechs mal hintereinander mit der Funktion ReadF lash drei Byte des abgespeicherten MD5-Hash aus dem Program Flash ausgelesen und in den Transmit-Buer geschrieben. Die Funktion W ritehexrecord2f lash ist so aufgebaut, dass sie aus Daten, welche im Intel HEX Format kommen, die Adresse und die zu speichernden Daten herauslest und diese mit der Funktion NV MemW ritew ord ins Program Flash speichert. Mit der Funktion ReadF lash kann pro Funktionsaufruf ein DWORD (32 Bit) aus dem Program Flash gelesen werden. Um diese beiden Funktionen korrekt verwenden zu können, muss man sich allerdings bewusst sein, wie die Adressierung des Program Flash aufgebaut ist und wo die Daten hingeschrieben werden. Falls eine DSV-Anwendung ins Flash geschrieben wird, übernimmt der Compiler die Generierung des Intel Hex Formats und ab Adresse 0 kann jede Flash Adresse einzeln beschrieben werden. Da die letzte Page des Program Flash (0x2A000 bis 0x2ABF F) für den Befehl DSV-Anwendung starten und als Speicher für den MD5-Hash der aktuell geladenen DSV-Anwendung verwendet wird, darf das Flash maximal bis zur Adresse 0x29F F F beschrieben werden! Wird der Intel HEX Code selber erzeugt, muss zusätzlich Nils Frey / Jannick Keller 20

23 daran gedacht werden, dass jedes vierte Byte ein Phantom Byte ist und nicht beschrieben werden kann. Beim Lesen aus dem Flash wird eine virtuelle Adressierung des Program Flash verwendet, wobei jede Adresse zwei Byte Speicher entspricht. Dies hat zur Folge, dass die eigentliche Adresse durch 2 geteilt werden muss um die Adresse zu erhalten, welche der Funktion ReadF lash übergeben werden muss. Dazu kommt, dass beim Lesen nur jede zweite Adresse ausgelesen werden kann und dafür ein DWORD mit 3 Byte Daten + 1 Phantom Byte zurückgibt. Der MD5-Hash wird ist bei der Program Flash Adresse 0x2AB10 und fortlaufend gespeichert. Im Anhang A.3 ist dargestellt, welcher Wert sich genau an welcher Adresse bendet, was sehr hilfreich sein kann, wenn man genau wissen will, wo die einzelnen Bytes gespeichert sind und wie sie ausgelesen werden können Memory Funktionen Die Datei NVMem.c enthaltet drei Funktionen zum Löschen bzw. Beschreiben des Program Flash Memory, welche vom Framework verwendet und auch von der main Funktion verwendet werden. Die Funktion NV MemBlockErase löscht das gesamte Flash, die Funktion NV MemEraseP age löscht eine Page des Program Flash und mit der Funktion können 3 Bytes ins Program Flash geschrieben werden. Nils Frey / Jannick Keller 21

24 6 Android Software Die Android Software bildet die Benutzeroberäche zur Steuerung des DSP-Board. Sie ist generell in zwei Teile aufgeteilt, das Grundgerüst und die Module. Eine grobe Ansicht des Aufbaus der Kommunikation zwischen der Android Software und dem DSP-Board ist in Abbildung 6.1 gezeigt. Die Kommunikation läuft nach dem in Abschnit 4 beschriebenen Protokoll ab. Das Grundgerüst bildet die Grundlage für die Verwaltung der Module und die Kommunikation mit dem DSP-Board und den Modulen. Die genaue Beschreibung bendet sich im Abschnitt 6.2. Die Module bieten die Benutzeroberäche zur Steuerung der DSV-Anwendung und sind dementsprechend für jede Anwendung unterschiedlich. Einige grundlegende Funktionen müssen jedoch in jedes Modul eingebettet werden. Die genaue Beschreibung zu den Modulen ist in Abschnitt 6.3 zu nden. Als Beispiel wurde ein Modul für ein Filter Studio erstellt, worüber in Abschnitt 7.2 nachzulesen ist. Abbildung 6.1: Grobübersicht der Kommunikation zwischen den Android Modulen und dem DSP- Board Nils Frey / Jannick Keller 22

25 6.1 Android Da es bei der Programmierung mit Android einige Unterschiede zu Java gibt, werden einige wichtige Unterschiede hier kurz erläutert. Android Apps bestehen im Grunde aus Activities und Services. Activities sind die Programmteile, welche die Benutzeroberäche verwalten. Eine Activity darf nicht für längere Zeit blockiert werden, da sie sonst vom Android Betriebsystem abgeschossen werden. Deshalb dürfen nur kleinere Verarbeitungen innerhalb der Activity vorgenommen werden. Die Benutzeroberäche, welche von einer Activity angezeigt wird, wird durch eine oder mehrere Layout-Dateien erstellt. Eine Layout-Datei ist eine XML-Datei, die nach bestimmten Kriterien deniert, welche Elemente wie angeordnet werden, und welche Eigenschaften diese haben. Es gibt eine grosse Anzahl an vorgegebenen Elementen, wie Buttons, Textfelder usw., aber auch Layouttypen, wie LinearLayout, Relativlayout usw.. Im Editor können diese per Drag and Drop fast beliebig kombiniert werden. Für grössere Verarbeitungen muss auf einen Service oder einen Thread zurück gegrien werden. Threads, die in einer Acrivity ausgeführt werden, leben jedoch nur solange wie die Activity selber, da sie im gleichen Prozess laufen. Services hingegen können in einem eigenen Prozess ausgeführt werden und können somit im Hintergrund weiter laufen, auch wenn die Activity geschlossen wird. Ein Service hat selber keine Benutzeroberfäche, wofür wiederum eine Activity benötigt wird. Um das Android Betriebsystem dazu zu bringen eine Operation auszuführen, wird ein sogenannter Intent benötigt. Zu diesen Operationen gehören das Starten von jeglichen Activities oder Services, sowie das Zugreifen auf Systemfunktionen, wie das Einschalten des Bluetoothadapters. Mit einem Intent wird dem Betriebsystem die eigene Absicht mit gewissen Eigenschaften mitgeteilt. Das Betriebsystem sucht dann nach allen möglichen Operationen, die zu den Eigenschaften der Absicht passen, und gibt eine Auswahl dieser zurück. Falls nur eine Operation zu der Absicht passt, wird diese ausgeführt. Für die Kommunikation zwischen Activities und Services gibt es die Messenger. Dafür muss die empfangende Instanz einen Messenger und einen zugehörigen Handler erstellen. Der Handler beinhaltet eine Methode, welche aufgerufen wird, wenn eine Message mit dem entsprechenden Messenger gesendet wurde. Der Messenger wird dann der Instanz übergeben, von wo aus die Message gesendet werden sollen. Ein Messenger kann auch an mehrere Instanzen übergeben werden. Um auf Systemaktivitäten reagieren zu können, muss ein BroadcastReceiver implementiert werden. Einem Broadcast wird ein Intent übergeben, welcher an alle Applikationen die auf diesen Intent zutreen gesendet wird. Um anzugeben, bei welchen Broadcasts der eigene BroadcastReceiver als Empfänger in Frage kommt, muss dies mit einem Intent-Filter festgelegt werden. Für die Systemaktivitäten sind diese vorgegeben und müssen nur angegeben werden. Es können jedoch auch eigene Broadcasts versendet und für diese entsprechende Intent-Filter deniert werden. Für einige Systemfunktionen, wie Intetnet oder Speicherzugri, werden zudem Permissions benötigt. Diese werden dem Benutzer bei der Installation der Applikation angezeigt. Damit soll verhindert werden, dass ein Programm Zugri auf Systemfunktionen erhält, ohne dass der Benutzer davon Kenntnis hat. Alle Teile der Applikation müssen im AndoidManifest registriert werden. Seien es Activities, Services, Receiver, Intent-Filter oder Permissions, wenn sie im AndroidManifest nicht aufgeführt sind, können diese nicht verwendet werden. Nils Frey / Jannick Keller 23

26 6.2 Grundgerüst Im nachfolgenden Kapitel wird das Android Grundgerüst beschrieben. Dieses ist das Hauptprogramm und übernimmt die Verwaltung der Module, sowie die Kommunikation zwischen dem DSP-Board und den Modulen. In der Tabelle 6.1 sind alle Klassen des Grundgerüstes mit einer kurzen Beschreibung aufgelistet. Klassenname ACAMainActivity (6.2.2) ACAMainService (6.2.3) ACABluetoothManager (6.2.4) DeviceListActivity (6.2.5) DSPBoardCommunicationThread (6.2.6) DownloadableModuleListActivity (6.2.7) ModuleDetailActivity (6.2.8) ACAUtilities (6.2.9) ModuleManager (6.2.10) ACABroadcastReceiver (6.2.11) ACAContentProvider (6.2.12) ACADatabaseHelper (6.2.13) ModuleTable (6.2.14) TransferFrame (6.2.15) ModuleSelectArrayAdapter (6.2.16) Beschreibung Verwalten der Benutzeroberäche der Hauptansicht. Hauptprogrammuss und Koordination aller Programmteile. Bluetoothverbindung aufbauen und Daten senden und empfangen. Verwalten der Anzeige der Bluetoothgeräte. Thread zum generieren und senden der Commands an das DSP-Board. Verwalten der Anzeige der herunterladbaren Module. Verwalten der Anzeige der Moduldetails. Bereitstellen einiger allgemein verwendeten Methoden. Bereitstellen der Methoden zum Managen der installierten Module. Empänger für Systembroadcasts. Bereitstellung von Datenbankzugrismethoden. Hilfsfunktionen zum Erstellen und Upgraden der Datenbank. Bereitstellen der Informationen zur Modultabelle. Klasse zum Zusammenfassen der Informationen eines Übertragungs-Frame. Angepasste Version des ArraAdapters. Tabelle 6.1: Klassenübersicht des Android Grundgerüstes Wenn die App ACA gestartet wird, wird vom System die Activity ACAMainActivity ausgeführt. Von dieser aus wird dann der Service ACAMainService gestartet, welcher sich um die Verwaltung des gesamten Programmes kümmert. Zu Beginn wird dann gleich eine Bluetoothverbindung mit dem DSP-Board hergestellt und der Thread DSPBoardCommunicationThread gestartet. Danach ist das Programm bereit und es wird auf eine Benutzereingabe gewartet. Der Ablauf ist in Abbildung 6.2 zu sehen. Bei einer Benutzereingabe auf der Hauptoberäche wird von der ACAMainActivity aus die entsprechende Methode im ACAMainService aufgerufen. Von dort aus wird dann die Verarbeitung durchgeführt oder wiederum eine Methode aus einer der anderen Klassen ausgeführt. Die Rückmeldungen, wie angeforderte Daten oder die Auorderung die Benutzeroberäche neu zu laden, werden meist über das Message-System bewerkstelligt. Nils Frey / Jannick Keller 24

27 6.2.1 Benutzeroberäche Abbildung 6.2: Startablauf des Android Grundgerüstes Die Benutzeroberäche setzt sich aus mehreren Layouts zusammen. Das Hauptfenster besteht aus zwei TextViews und einem GridView. Im Ausgangszustand sieht dies wie in Abbildung 6.3 aus. Das GridView ist eine Art Kacheloberäche (Abbildung 6.4), in welches zur Laufzeit Elemente hinzugefügt werden können. Es können zudem beliebig viele Elemente hinzugefügt werden und bei einem Überlaufen des Bildschirmes wird es scrollbar gemacht. Im GridView werden die installierten Module als Kacheln mit Titel und Icon angezeigt, wie dies in Abbildung 6.5 zu sehen ist. Wie auf dem Bild zu entnehmen ist, gibt das erste TextView die Kategorie der im GridView angezeigten Module an. Der Text wurde eingefügt, da geplant war eine Kategorie Last Used Module anzuzeigen, was jedoch nur teilweise implementiert werden konnte, und deshalb ausgeblendet ist. Das zweite TextView, am unteren Rand des Bildschirmes gibt Informationen über den Zustand der Bluetoothverbindung an. Es kann folgende drei Zustände anzeigen: Not connected, Connecting und Connected. Abbildung 6.3: Ansicht des Hauptfenster im Ausgangszustand Um im GridView die Module schön mit Name und Icon anzeigen zu können, wurde eine weitere Nils Frey / Jannick Keller 25

28 Abbildung 6.4: Schematische Darstellung eines GridView [4] Abbildung 6.5: Hauptfenster der Android Software Layout-Datei, bestehend aus einem TextView und einem ImageView (Abbildung 6.6) erstellt. Für jedes installierte Modul wird dann ein solches Layout mit entsprechendem Titel im TextView und Icon im ImageView instanziert und dem GridView hinzugefügt. Für diesen Zweck wurde ein ArrayAdapter, wecher eine Liste von Strings speichert um einem ListView oder GridView hinzuzufügen, angepasst und die Funktion getv iew() überschrieben, so dass ein solches Layout zurückgegeben wird anstelle eines Strings. Nils Frey / Jannick Keller 26

29 Abbildung 6.6: Layout für Modulkacheln ACAMainActivity In der Activity ACAMainActivity wird, wie schon erwähnt, die Hauptansicht des Android- Grundgerüstes verwaltet. Konkret heisst dies, dass bei Änderungen an der Benutzeroberäche diese aktualisiert wird und das bei Benutzereingaben diese engegengenommen werden und die dazugehörigen Methoden aufgerufen werden. Eine Benutzereingabe kann entweder das Auswählen eines Menüeintrages oder eines installierten Moduls sein. Die Methoden dazu benden sich nicht in der Klasse ACAMainActivity sondern in der Klasse ACAMainService, zudem bestehen diese Methoden lediglich aus einem Startbefehl eines Thread, welcher dann die Aufgabe erledigt. Diese Art der Implementierung ist notwendig, da die Activity nicht für längere Zeit beschäftigt sein darf, weil sonst die Benutzeroberäche blockiert ist und das Android Betriebsystem diese beendet. Wenn ein Element der Benutzeroberäche neu geladen werden muss, wird eine Message an die ACAMainActivity gesendet und diese lädt die Ansicht neu ACAMainService Der Service ACAMainService ist der Hauptteil des Andoid-Grundgerüstes. Er übernimmt die Koordination der beteiligten Klassen, sowie die Kommunikation zwischen diesen (Abbildung 6.7). Der ACAMainService nimmt entweder über einen Methodenaufruf (nur im Falle der ACAMainActivity) oder über eine Message die Anweisung zum Ausführen einer Funktion entgegen. Falls diese Funktion Teil des Services ist, wird sie direkt ausgeführt, anderenfalls wird über einen Methodenaufruf eine Message (nur im Falle der ACAMainActivity) oder einen Intent (bei neu gestarteten Activities) die Funktion in der entsprechenden Klasse ausgeführt. Wenn sich die auszuführende Funktion im ACAContentProvider bendet, wird diese über eine Systemfunktion ausgeführt, dies ist im Abschnitt beschrieben. Die wichtigsten Funktionen im ACAMainService werden im Folgenden kurz beschrieben. Die Funktionen, welche längere Verarbeitungszeit benötigen, wie das Downloaden der Module, werden in separaten Thread ausgeführt. Zu jedem Thread gehört eine Methode, welche sich um das Starten und Restarten des Threads kümmert. Listing 6.8 zeigt den Code einer solchen Methode am Beispiel des LoadModulesFromDBThread. Diese Thread-Starter-Methoden sind notwendig, da nicht einfach neu gestartet werden kann, sondern zuerst neu erstellt werden muss, zudem darf der Thread nur einmal laufen. Der LoadModulesFromDBThread lädt, wie der Name schon andeutet, die Informationen der installierten Module aus der Datanbank, erstellt einen ArrayAdapter mit diesen und sendet der ACA- MainActivity eine Message, damit diese den Adapter abholt um die Module im GridView anzuzeigen. Dazu wird die Methode getinstalledm odules() aus der Klasse ModuleManager ausgeführt. Der Thread InstallModuleThread erstellt, falls noch nicht vorhanden, den Ordner ACA im externen (ausserhalb der App) Speicher des Android Gerätes und lädt die Datei modulelist.xml von der Projekthomepage 4 herunter. Die Datei muss ebenfalls zuerst erstellt werden, falls sie nicht exis- 4 Nils Frey / Jannick Keller 27

30 Abbildung 6.7: Ablauf der Kommunikation innerhalb des Android Grundgerüstes. (Ausgezogene Linie: Methodenaufruf, gestrichelte Linie: Message, gepunktete Linie: Systemaufruf) tiert, da sie sonst nicht gespeichert werden kann. Diese XML-Datei enthält Informationen über die zum Download stehenden Module. Genaueres dazu ist im Abschnitt zu nden. Danach wird 1 / Listing 6.8: Thread-Starter-Methode 2 Checks i f the LoadModulesFromDBThread Object "mloadmodulesfromdb" e x i s t s and i f i t s a l r e a d y running. 3 I f i t does not e x i s t or i s not running anymore i t w i l l be ( re ) c r e a t e d and s t a r t e d. 4 I f i t e x i s t and i s running a DEBUG Message i s c r e a t e d. 5 / 6 p u b l i c synchronized void loadmodulesfromdb ( ) { 7 i f (mloadmodulesfromdb == n u l l ) { 8 mloadmodulesfromdb = new LoadModulesFromDBThread ( ) ; 9 mloadmodulesfromdb. s t a r t ( ) ; 10 } e l s e { 11 i f (! mloadmodulesfromdb. i s A l i v e ( ) ) { 12 mloadmodulesfromdb = new LoadModulesFromDBThread ( ) ; 13 mloadmodulesfromdb. s t a r t ( ) ; 14 } e l s e { 15 i f (DEBUG) { 16 Log. d (TAG, "mloadmodulesfromdb Thread i s a l r e a d y running " ) ; 17 } 18 } 19 } 20 } Nils Frey / Jannick Keller 28

31 die Activity DownloadableModuleActivity gestartet und mit dem Intent der Pfad der XML-Datei übermittelt. Im Thread DownloadAPKThread wird die APK-Datei von der Projekthomepage 5 heruntergeladen. Auch hier wird zuerst, falls nötig, der Ordner ACA und die herunterzuladende Datei erstellt. Der Thread benötigt dazu das StringArray downloadm oduleinf o, welches den Namen der Datei, sowie den Link dazu enthält. Das StringArray wird von der DownloadableModuleActivity zurückgegeben. Um dem Thread das Array als Parameter zu übergeben, muss die start() Methode überschrieben werden. Diese ist in Listing 6.9 gezeigt. Nach dem Herunterladen wird eine Message an den ACA- MainService gesendet, um über den Download zu informieren. Diese Message beinhaltet ebenfalls das downloadm oduleinf o StringArray. 1 / Listing 6.9: Überschriebene start-methode 2 Overwrites the s t a r t Method to take the String Array with the Module Information as parameter. 3 downloadmoduleinfo 5 Module Information as returned from the DownloadableModuleListActivity. 6 / 7 p u b l i c synchronized void s t a r t ( S t r i n g [ ] downloadmoduleinfo ) { 8 t h i s. downloadmoduleinfo = downloadmoduleinfo ; 9 super. s t a r t ( ) ; 10 } Die Methode InstallAPK installiert das heruntergeladene APK-Paket indem der Android-Package- Installer über einen Intent gestartet wird. Die Methode benötigt als Übergabewert das StringArray, welches in der Message vom DownloadAPKThread mitgeschickt wird. Aus dem Downloadlink, welcher im StringArray enthalten ist, wird der Modul-APK-Name herausgelesen und dem Intent hinzugefügt. Zudem wird in dieser Methode der MD5-Hash des APK-Pakets berechnet. Mit der Methode addmodule wird das installierte Modul der Datenbank hinzugefügt. Sie wird mit dem Paketname als Übergabewert aufgerufen. Dieser wird dann überprüft, ob die Zeichenkette.aca. darin enthalten ist. Falls dies nicht der Fall ist, wird die Methode abgebrochen. Ansonsten wird die Info-XML-Datei aus dem Ressourcenordner des Moduls gelesen und die Informationen über das Modul, zusammen mit dem MD5-Hash des APK-Pakets aus der Methode InstallAPK, in der Datenbank abgelegt. zu diesen Informationen gehören der Modulname, die Modulversion, der Paketname, der Name der Hex-Datei, der Name des Icons, der MD5-Hash für das APK-Paket und die Hex-Datei, das Erscheinungsdatum und eine Beschreibung der Funktionen des Moduls. Danach wird die ACAMainActivity benachrichtigt, dass die Benutzeroberäche neu geladen werden muss. Über die Methode uninstallapk wird ein installiertes Modul, basierend auf dem Paketname über den Package-Installer deinstalliert. Der Übergabewert für diese Methode ist das StringArray module- Inf o, welches die Informationen über das enstprechende Module beinhaltet. Das Array muss die Struktur haben, wie sie von den Methoden getm oduleinf oby... aus der Klasse ModuleManager zurückgegeben wird. Im Gegensatz zu Methode uninstallapk entfernt die Methode removemodulefromdb das Modul nur aus der Datenbank und nicht vom System. Auch dies wird auf Grund des Paketnamens gemacht, 5 Nils Frey / Jannick Keller 29

32 jedoch ist der Übergabewert lediglich ein String der den Paketnamen enthaltet. Nach dem Entfernen wird ebenfalls die ACAMainActivity über eine Message dazu aufgeforder die Benutzeroberäche zu aktualisieren. showmoduledetail ist eine Methode, welche aufgerufen wird, wenn ein Modul ausgewählt wurde. Sie holt die Informationen des ausgewählten Moduls als StringArray aus der Klasse ModuleManager über die Methode getm oduleinf obylistp osition und startet die ModuleDetailActivity über einen Intent, welchem das StringArray mitgegeben wird. Über den ProgramModuleThread wird das ausgewählte Modul auf das DSP-Board programmiert. Darin wird dem DSPBoardCommunicationThread mitgeteilt, dass eine Programmierung des Flash- Speichers gestartet werden soll und der Paketname sowie der Hex-Dateiname mit übergeben. Danach wird über die Methode updatem oduleinf o der Klasse ModuleManager die aktuelle Systemzeit in Millisekunden in den Datenbankeintrag des ausgewählten Moduls gespeichert. Anschliessend wird die ACAMainActivity benachrichtigt, um die Benutzeroberäche neu zu laden. Der ProgramModuleThread benötigt ebenfalls das StringArray moduleinf o wie es von den getm oduleinf oby... Methoden zurückgegeben wird, wofür die start-methode des Thread überschrieben wurde. Auch hierfür wurde eine Thread-Starter-Methode erstellt. Die Methode sendmessagetoacamainactivity ist in zwei Varianten implementiert. Der einen wird ein Bundle übergeben, welches bereits alle Informationen der Message enthält, der anderen werden die Standardargumente für eine Message, intwhat, intarg1, intarg2 und Objectobj übergeben. Im Normalfall reichen die Standardargumente aus, wenn jedoch z.b. ein Messenger übermittelt werden soll, muss dieser in ein Bundle eingebettet werden. Der Vorteil der zweiten Implementierung ist, dass beim Aufruf die Informationen direkt mitgegeben werden können und nicht wie bei der ersten Implementierung zuerst ein Bundle erstellt werden muss. Der Nachteil ist, dass, wie erwähnt, gewisse Elemente nicht als Object übermittelt werden können und, dass die Anzahl der Argument begrenzt ist. Der Thread CheckMD5ForProgrammedAppThread liest den MD5-Hash des auf dem Flash programmierten Moduls und vergleichen ihn mit den in der Datenbank abgelegten MD5-Hashs. Hierbei handelt es ich um den MD5-Hash der Hex-Datei und nicht um den des APK-Paketes, somit kann das programmierte Modul beibehalten werden, wenn sich nur das Android-Modul ändert. Zuerst wird der Thread DSPBoardCommunicationThread aufgefordert den MD5-Hash aus dem Flash zu lesen. Wenn dieser gelesen wurde, wird die globale Variable md5readdone auf 1 gesetzt. CheckMD5ForProgrammedAppThread wartet in der Zwischenzeit auf diese Variable. Falls der MD5-Hash nicht gelesen werden konnte, wird die Variable auf 1 gesetzt und der Thread bricht ab. Falls ein MD5-Hash gelesen wurde, wird in der Datenbank nach einem passenden Eintrag gesucht und bei einem Treer ein Dialog angezeigt. Dieser teilt dem Benutzer mit, dass das entsprechende Modul programmiert ist, und fragt, ob es gestartet werden soll. Bei Ja wird es gestartet und bei Nein der Thread abgebrochen. Falls ein Modul gestartet werden soll, wird der Thread StartModuleThread ausgeführt. Dieser überprüft vorweg, ob eine Bluetoothverbindung besteht. Wenn keine Verbindung aufgebaut ist, wird ein Dialog mit der Information angezeigt, dass die Verbindung nicht besteht, und ob diese erstellt werden soll. Bei Ja wird der Benutzer zur Verbindungsansicht geführt, es muss jedoch unabängig von der Antwort das Modul manuell neu gestartet werden. Bei bestehender Verbindung geht deht der Thread StartModuleThread fast gleich vor wie der Thread CheckMD5ForProgrammedAppThread. Dies heisst, es wird überprüft, ob ein Modul bereits insalliert ist und ob es sich um das zu startende Modul handelt. Wenn es nicht dasselbe Modul ist wird nachgefragt, ob dieses wirklich überschrieben oder gestartet werden soll. Falls der Benutzer sich dazu entscheidet das programmierte Modul zu Nils Frey / Jannick Keller 30

33 überschreiben, wird der Thread ProgramModuleThread ausgeführt, ansonsten das entsprechende Modul gestartet. Die Methode setprogressdialog sendet eine Message an die Activity ACAMainActivity und fordert diese auf, einen neuen Progressdialog mit der mitgegebenen Nachricht zu starten oder den aktuellen zu schliessen. Der Progressdialog wird bei den Aufgaben, welche eine längere Zeit dauern und nicht durch Benutzereingaben gestört werden dürfen, angezeigt. Die Methode sendtodspboard bietet einen vereinfachten Zugri auf die write-methode der Klasse BluetoothManager. Dieser kann ein einfach Hex-String übergeben werden, welcher über die Methode hexstringt obytearray der Klasse ACAUtilities in ein Byte-Array umgewandelt und der write-methode übergeben wird. Für jeden Standardbefehl des Bootloaders und der Module ist eine Methode implementiert, welche über den entsprechenden Menüeintrag aus der Activity ACAMainActivity aufgerufen wird. Diese beauftragen den Thread DSPBoardCommunicationThread den entsprechenden Befehl an das DSP- Board zu senden. Desweiteren wird eine Handlerklasser erstellt, in welcher die Methode handlemessage überschrieben wird. Diese wird aufgerufen, sobald eine Message an den Handler oder einen damit verbundenen Messenger gesendet wird. Hier werden alle eingehenden Messages bearbeitet, was möglichst kurz gehalten wird, und meist aus einem einfachen Methodenaufruf besteht. Es wird an dieser Stelle nicht auf die einzelnen Messages eingegangen, hierfür muss direkt der Code konsultiert werden ACABluetoothManager Die Klasse ACABluetoothManager übernimmt das Ertsellen eine Bluetoothverbindung und hält diese aufrecht. Zudem kümmert sie sich um das Empfangen und Senden der Daten über Bluetooth. Zur Erstellung dieser Klasse wurde die Klasse BluetoothChatService aus dem Beispielcode BluetoothChat[9] kopiert und angepasst. Im Wesentlichen wurden folgende Funktionen übernommen. Um eine Verbindung aufzubauen, wird der Thread ConnectThread gestartet. Dieser verbindet sich als Client mit einer vordenierten UUID mit dem Bluetoothmodul. Dieses agiert bei dieser Verbindung als Server. Danach wird der Thread ConnectedThread gestartet. Dieser empfängt in einer Endlosschleife die Daten von einem InputStream und sendet diese über eine Message an den Service ACAMainService. In diesem Thread ist ebenfalls die Methode write implementiert, welche ein ByteArray über einen OutputStream an das Bluetoothgerät sendet. Über die Methode start werden alle laufenden Threads beendet und die Activity DeviceListActivity gestartet DeviceListActivity Die Activity DeviceListActivity aktiviert den Bluetootadapter und erstellt eine Liste aller gepaarten Geräte. Diese Liste wird dem Benutzer auf einem neuen Bildschirm angezeigt. Dieses hat das Layout wie in Abbildung 6.10 gezeigt wird. Es besteht aus drei TextView, zwei ListView und einem Button. Sichtbar ist standardmässig nur das eine TextView, ein LsitView und der Button. Wenn der Button Scan for devices betätigt wird, sucht die Activity nach verfügbaren Bluetoothgeräten und listet diese, von den gepaarten abgetrennt, ebenfalls auf. Dies ist in Abbildung 6.11 zu sehen. Hier sind jetzt alle TextView und ListView zu sehen, der Button ist jedoch ausgeblendet. Wenn ein Bluetoothgerät ausgewählt wurde, wird ein BluetoothDevice-Objekt für diese Gerät erstellt und über eine Message an den BluetoothManager gesendet. Nils Frey / Jannick Keller 31

34 Abbildung 6.10: Layoutansicht der DeviceListActivity Abbildung 6.11: Screenshot der DeviceListActivity nach einem scan DSPBoardCommunicationThread Der Thread DSPBoardCommunicationThread wird beim Programmstart gestartet und bleibt in der run-methode in einer whlie-schleife am laufen, bis er explizit gestoppt wird. Über die Methode send wird dem Thread ein Befehl übergeben. Je nach Befehl sind ein Paketname, eine Hex-Dateiname oder weitere zu sendende Daten nötig. Aufgrund des übergebenen Befehles sendet der Thread ein oder mehrere entsprechende Frames an das DSP-Board. Nach dem Senden wird in der Methode waitf orrxf rameready abgewartet bis ein gültiges Frame vom DSP-Board empfangen wurde. Wenn eine Sekunde lang keine Antwort erhalten wurde, wird der Befehl bis zu drei mal nachgesendet und Nils Frey / Jannick Keller 32

35 dann ein Timeout zurückgemeldet. Wenn ein gültiges Frame empfangen wurde, wird in der Methode checkreturnhexstring der erhaltene Hex-String analysiert. Es wird überprüft, ob der erhaltene Befehl mit dem gesendeten übereinstimmt und ob weitere Daten im Hex-String enthalten sind. Falls der erhaltene Befehl 00 ist, heisst dies, dass entweder in den Bootloader gewechselt wurde, oder der gesendete Befehl von diesem nicht erkannt wurde. Bei 10 wurde entweder in die Applikation gewechselt oder der Befehl wurde von dieser nicht erkannt. Die Methode checkreturnhexstring gibt die empfangenen Daten ohne den gesendeten Befehl an die run Methode zurück. Dort wird dann dem gesendeten Befehl entsprechend auf die Antwort reagiert. Für alle standard Bootloaderund Applikationsbefehle ist eine separate Verarbeitung implementiert. Für nicht-standard-befehle ist eine allgemeine Verarbeitung unter dem Befehl COMMAND_OTHERS implementiert. Für jeden Befehl ist eine Konstante erstellt, diese sind in Listing 6.12 aufgeführt. 1 / Listing 6.12: Liste der Konstanten des Threads DSPBoardCommunicationThread 2 Commands f o r the b o o t l o a d e r 3 / 4 p u b l i c s t a t i c f i n a l i n t COMMAND_BOOTLOADER_READ_VERSION = 1 ; 5 p u b l i c s t a t i c f i n a l i n t COMMAND_BOOTLOADER_ERASE_FLASH = 2 ; 6 p u b l i c s t a t i c f i n a l i n t COMMAND_BOOTLOADER_PROGRAMM_FLASH = 3 ; 7 p u b l i c s t a t i c f i n a l i n t COMMAND_BOOTLOADER_READ_CRC = 4 ; 8 p u b l i c s t a t i c f i n a l i n t COMMAND_BOOTLOADER_JUMP_TO_APPLICATION = 5 ; 9 p u b l i c s t a t i c f i n a l i n t COMMAND_BOOTLOADER_WRITE_MD5 = 6 ; 10 p u b l i c s t a t i c f i n a l i n t COMMAND_BOOTLOADER_READ_MD5 = 7 ; / 13 Commands f o r every a p p l i c a t i o n 14 / 15 p u b l i c s t a t i c f i n a l i n t COMMAND_APP_JUMP_TO_BOOTLOADER = 1 1 ; 16 p u b l i c s t a t i c f i n a l i n t COMMAND_APP_READ_MD5 = 1 2 ; 17 p u b l i c s t a t i c f i n a l i n t COMMAND_APP_RESET = 1 3 ; / 20 Command f o r user d e f i n e d commands 21 / 22 p u b l i c s t a t i c f i n a l i n t COMMAND_OTHERS = 2 0 ; DownloadableModuleListActivity Die Activity DownloadableModuleListActivity wird vom Service ACAMainService gestartet und erhält von diesem den Pfad zur XML-Datei modulelist.xml. Wie bereits erwähnt, enthält diese Datei Informationen über die zum Download stehenden Module und sieht wie in Listing 6.13 gezeigt aus. Es wurde der XML-Standard[10] für diese Liste gewählt, da die Verarbeitung in Java mit der jdom-bibliothek[3] sehr gut implementiert ist. Über die darin enthaltenen Klassen und Methoden können die Elemente und Argumente der XML-Datei direkt ausgewählt werden. Die Datei beginnt mit dem Root-Element modulelist, und jedes Modul muss ein eigenes Element module darstellen. Zudem muss jedes Modul die Argumente modulename, moduleversion und modulelink enthalten. Die Argumente moduledescription und releasedate sind für eine zukünftige Implementierung der Activity ModuleDetailActivity, zur Anzeige der Details vor dem Download, vorgemerkt. Die Datei kann beliebig viele module-elemente enthalten. Die aus der XML-Datei gelesenen Informationen werden in einen ArrayAdaper gespeichert und im ListView der Ansicht der DownloadableModule- ListActivity, wie sie das Layout in Abbildung 6.14 zeigt, angezeigt. Wenn ein Modul ausgewählt wurde, wird eine Message inklusive einem StringArray an den Service ACAMainService gesendet. Der StringArray enthält als Element 0 den Wert des Argumentes modulename und als Element 1 Nils Frey / Jannick Keller 33

36 den des Argumentes modulelink. Listing 6.13: modulelist.xml 1 <m o d u l e l i s t > 2 <module 3 modulename=" Testmodul LED" 4 moduleversion=" 0. 6 " 5 m o d u l e d e s c r i p t i o n="modul zum ein und a u s s c h a l t e n der LED" 6 r e l e a s e d a t e=" " 7 modulelink=" http : / / web. fhnw. ch/ t e c h n i k / p r o j e k t e / e i t / Fruehling2013 / FreyKel /APK/ TestmodulLED_v0. 6. apk"> 8 </module> 9 </m o d u l e l i s t > Abbildung 6.14: Layout zur Ansicht der Liste der zum Download stehenden Module ModuleDetailActivity Die Activity M oduledetailactivity zeigt eine Ansicht mit Detailinformationen zum ausgewählten Modul an. Diese Informaionen werden beim Aufruf der Activity über den Intent übermittelt und bestehen aus einem StringArray mit der Struktur, wie sie von den Methoden getm oduleinf oby... zurückgegeben wird. Abbildung 6.15 zeigt die Ansicht am Beispiel des Moduls Testmodul LED. Wenn der Start-Button gedrückt wird, wird eine Message zum Starten des Moduls an den Service ACAMainServiece gesendet. Nils Frey / Jannick Keller 34

37 Abbildung 6.15: Detailansicht des Moduls Testmodul LED ACAUtilities Die Klasse ACAUtilities stellt verschiedene statische Hilfsmethoden zur Vserfügung. Diese werden im Folgenden kurz beschrieben. In der Methode calculatecrc wird aus einem ByteArray der CRC-Code des Typs CRC-CCITT (XModem)[5] berechnet. Zurückgegeben wird ein ByteArray mit dem berechneten CRC-Code. Es wurde dieser Typ CRC gewählt, da dieser im Bootloader bereits implementiert war und er sich mit wenigen Zeilen in realisieren lässt. Die Methode zur Berechnung des MD5-Hash ist ebenfalls in dieser Klasse implementiert. Sie ist in zwei Ausführungen vorhanden, calculatem D5F rombytearray und calculatem D5F rominputstram. Die erste Variante berechnet den MD5-Hash aus einem ByteArray und gibt auch ein ByteArray zurück, die zweite verwendet als Parameter einen InputStream und gibt den MD5-Hash als String zurück. Aus dem InputStream wird innerhalb der Methode ein ByteArray-Buer geladen. Die Berechnung erfolgt in beiden Varianten auf dieselbe Weise, über die Java-Klasse MessageDigest. Bei der zweiten Ausführung wird am Ende zusätzlich noch mit der Methode bytearrayt ohexstring ein Hex-String aus dem ByteArray, welches den MD5-Hash enthält, erstellt. In der Methode bytearrayt ohexstring wird, wie der Name bereits sagt, aus einem ByteArray ein Hex-String erzeugt. Dazu wird jedes Byte in einen Integer gewandelt, mit 0xF F &-verknüpft und mit der statischen Methode tohexstring(intv al) der Klasse Integer in einen Hex-String umgewandelt. Falls der Integer-Wert des Bytes kleiner als 0x10 ist, wird noch eine 0 vorangestellt. Die Methode zum Esrstellen eines ByteArray aus einem anderen Datentyp ist ebenfalls in zwei Varianten vorhande. Um aus einem Integer ein ByteArray zu erstellen, wird in der Methode intt obytearray immer 8 Bit des Integer in ein Byte gecastet und einem ByteArray hinzugefügt. Damit das Array nur so gross ist wie dies für den eingegangen Wert notwendig ist, wird dieses nach einer Überprüfung der Grösse des Integer entsprechend erstellt. Für das Umwandeln eines Hex-Strings in ein ByteArray wurde die Methode hexstringt obytearray implementiert. In dieser werden immer zwei Zeichen des Nils Frey / Jannick Keller 35

38 Strings in ein Byte umgewandelt, indem jedes dieser Zeichen mit der Methode digit aus der Klasse Character in ein Nibbel gewandelt und das höherwertige um vier Bit nach links geschoben wird. Um ein Frame zu erstellen, welches vom Bootloader bzw. der dsv-anwendung interpretiert werden kann, wurde die Methodel buildt xf rame implementiert. Dieser kann der Befehl, sowie die zu sendenden Daten als Hex-String übergeben werden und daraus wird dann das Frame nach den Kriterien, wie es in Abschnitt 4 beschrieben ist, erstellt. Das Frame wird als Hex-String zurückgegeben. Zum Extrahieren der Befehle und Daten eines empfangenen Frames kann die Methode buildrxf rame verwendet werden. Diese extrahiert die Daten aus dem Frame und speichert diese in einem Objekt der Klasse TransferFrameab. Übergeben wird ein ByteArray und die Anzahl der empfangenen Bytes in diesem. Die Extraktion geschieht nach demselben Prinzip wie die gleichnamige Funktion im Bootloader (Abschnitt 5.1.4) ModuleManager Die Klasse ModulManager stelle ebenfalls statische Hilfsfunktionen zur Verfügung. Alle hier enthaltenen Methoden sind darauf ausgelegt, Informationen in der Modultabelle der Datenbank, mittels ContentResolver, zu Ver- und Bearbeiten. Die meisten Methoden sind mehrfach implementiert, einfach für unterschiedliche Übergabeparameter. Zum Entfernen eines Moduls aus der Datenbank gibt die Methode removem odulebyp ackagen ame, für welche, wie der Name schon sagt, der Paketname benötigt wird. Mit den Paketname wird über der Methode getm oduleidbyp ackagen ame die Datenbank-Id des Moduls ermittelt und dieses aus der Datenbank entfernt. Mit der Methode addmodule wird ein neuer Eintrag für ein Modul in der Datenbank erstellt. Dazu wird ein StringArray mit den Modulinformationen, wie es von den Methoden getm oduleinf oby... zurückgegeben wird, sowie ein String mit dem MD5-Hash des APK-Paketes benötigt. Die Methode getinstalledm odules liest Informationen aller in der Datenbank gespeicherten Module aus und speichert diese in einem ArrayAdapter. Zu diesen Informaionen gehören die Datenbank-Id, der Modulname, der Paketname des Moduls, sowie der Name des Modulicons. Zurückgegeben wird der ArrayAdapter. Die Methoden getm oduleinf oby... sammeln die Informationen eines bestimmten Moduls und geben diese in einem StringArray zurück. Diese Methode gibt es für folgende Übergabewerte: ListPosition, die Position in einer Liste, eines ListView oder eines GridView Id, die Datenbank-Id des Moduls MD5, der MD5-Hash der Hex-Datei Das zurückgegebene StringArray hat die Struktur, wie sie der Ausschnitt aus der API-Doc in Listing 6.16 zeigt. Bei der Id handelt es sich um die Datenbank-Id. Mit der Methode getdspm d5byp ackagen ame wird aufgrund des Paketnamen der MD5-Hash der Hex-Datei aus der Datenbank gelesen. Die Datenbank-Id eines Module kann entweder über den Paketnamen oder den MD5-Hasch des APK- Paketes mit der Methoden getm oduleidbyapkm d5 bzw. getm oduleidbyp ackagen ame ermittelt Nils Frey / Jannick Keller 36

39 1 / Listing 6.16: Ausschnitt aus der API-Doc zu den Methoden getm oduleinf oby... 3 Returns a StringArray with the f o l l o w i n g i n f o r m a t i o n : 4 0 = Id ; 5 1 = Module name ; 6 2 = Module v e r s i o n ; 7 3 = Package name ; 8 4 = Hex F i l e name ; 9 5 = Icon name ; 10 6 = Last used date ; 11 7 = r e l e a s e date ; 12 8 = d e s c r i p t i o n ; 13 9 = MD5 DSP (Hex F i l e ) ; 14 / werden. Der von den Methoden zurückgegeben Integer enthält die Datenbank-Id, falls genau ein Eintrag gefunden wurde. Wurde kein Eintrag gefunden, wird 1 zurückgegeben und 2 falls mehrere Einträge gefunden wurden. Um die in der Datenbank gespeicherten Informationen eines Moduls, wessen Datenbank-Id bekannt ist, zu verändern, kann die Methode updatem oduleinf o verwendet werden. Über die Methode getm odulen amebym D5 kann der Name eines Moduls aufgrund des MD5-Hash des APK-Paketes ermittelt werden. Die Methode getm oduleinf of romxm L liest die Informationen eines installierten Moduls aus der XML-Info-Datei, welche sich in dessen Ressourcenordner bendet. Die Struktur des zurückgegebenen StringArray ist dieselbe, wie sie von den Methoden getm oduleinf oby... zurückgegeben wir. Der einzige Unterschied ist, dass die Datenbake-Id 0 ist, da es sich nicht um einen Datenbankeintrag handelt. Die Struktur der XML-Info-Dateien wird im Anschnitt 6.3 beschrieben ACABroadcastReceiver Der ACABroadcastReceiver ist eine vom BroadcastReceiver abgeleitete klasse und wird bei entsprechenden im AndroidManifest festgelegten Broascast aufgerufen. In Listing 6.17 sind die Zeilen aufgeführt, die den ACABroadcastReceiver für die Broadcasts registriert, welche versendet werden, wenn ein Paket neu installiert, eines deinstalliert oder eines ersetzt wurde. Dies Zeile < dataandroid : scheme = package / > gibt zudem an, dass als Daten der Paketname verlangt wird. Bei einem Aufruf des ACABroadcastReceiver wird der Paketname bereits überprüft, ob diese die Zeichenkette.aca. enthält und nur wenn dem so ist wird eine entsprechende Message an den ACAMainService gesendet. Somit wird verhindert, dass dieser bei jeder Installation, Deinstallation oder Update eines beliebigen Pakets ausgeführt wird. Die ACA-Applikation muss jedoch schon einmal gestartet worden sein, dass der Broadcast empfangen werden kann. Dies ist vom Android-System so gegeben. Nils Frey / Jannick Keller 37

40 Listing 6.17: Resgistrierung des ACABroadcastReceiver im AndroidManifest 1 <r e c e i v e r android : name=". b r o a d c a s t r e c e i v e r. ACABroadcastReceiver " > 2 <i n t e n t f i l t e r > 3 <a c t i o n android : name=" android. i n t e n t. a c t i o n.package_added" /> 4 <a c t i o n android : name=" android. i n t e n t. a c t i o n.package_replaced" /> 5 <a c t i o n android : name=" android. i n t e n t. a c t i o n.package_removed" /> 6 7 <data android : scheme=" package " /> 8 </i n t e n t f i l t e r > 9 </ r e c e i v e r > Nils Frey / Jannick Keller 38

41 ACAContentProvider Ein ContentProvider ist ein Konstrukt, welches den Zugri auf strukturierte Daten verwaltet. Im Falle des ACAContentProvider wird der Zugri auf die ACA-Datenbank verwaltet. Es müssen folgende Methoden, entsprechend der zu verwaltenden Daten, implementiert werden: oncreate wird vom System aufgerufen, wenn der ContentProvider erstellt wird, query kann aufgerufen werden, um Daten abzufragen, insert wird verwendet, um neue Daten abzuspeichern, update aktualisiert die bereits vorhandenen Daten und delete löscht vorhanden Daten. Im ACAContentProvider werden die Anfragen, mit Hilfe des DatabaseHelpers (mehr dazu in Abschnitt ), an die Datenbank weitergeleitet. Die Methoden des ContentProvider werden nicht direkt, sondern über den ContentResolver aufgerufen. Mit der Methode getcontentresolver und der Angabe einer Authority im Methodenaufruf ruft das System die Methode im entsprechenden ContentProvider auf. Die Authority identiziert den ContentProvider und muss bei der Registrierung des ContentProvider im AndoirdManifest angegeben werden. Listing 6.18 zeigt die entsprechenden Zeilen. Mit dem Argument exported=false wird verhindert, das Prozesse von anderen Applikationen diesen ContentProvider verwenden können. 1 <p r o v i d e r Listing 6.18: Resgistrierung des ACAContentProvider im AndroidManifest 2 android : name=". c o n t e n t p r o v i d e r. ACAContentProvider" 3 android : a u t h o r i t i e s="ch. fhnw. a n d r o i d c o n t r o l l e d a u d i o p r o c e s s o r. c o n t e n t p r o v i d e r " 4 android : exported=" f a l s e " > 5 </provider > ACADatabaseHelper Die von der Klasse SQLiteOpenHelper abgeleitete Helferklasse ACADatabaseHelper übernimmt das Önen, falls die Datenbank existiert, das Erstellen, falls sie nicht existiert und das Upgraden dieser, falls notwendig. Zum Arbeiten mit der Datenbank kann die Methode getw ritabledatabase (zum Bearbeiten) oder getreadabledatabase (zum reinen Auslesen von Informationen) über das Objekt der Klasse ACADatabaseHelper aufgerufen werden. Zu diesem Zweck müssen die Methoden oncreate und onupgrade implementiert werden. Von hier aus werden die entsprechenden Methoden der Klassen für die einzelnen Tabellen in der Datenbank aufgerufen. Da zur Zeit nur eine Tabelle in der Datenbank gespeichert ist, werden nur die Methoden oncreate und onu pgrade der Klasse ModuleTable aufgerufen ModuleTable Es wird empfohlen für jede Tabelle in der Datenbank eine Klasse zu erstellen. Diese implementieren die Methoden oncreate und onupgrade, sowie Konstanten zum einfacheren Zugri auf die einzelnen Kolonnen der Tabelle. Zudem wird eine Konstante für den SQL-Erstellungsbefehl erstellt. Im Falle der Tabelle für die Module sieht dies aus wie in Listing 6.19 und Nils Frey / Jannick Keller 39

42 Listing 6.19: ModuleTable Klasse Teil 1 1 p u b l i c c l a s s ModulesTable { 2 p r i v a t e s t a t i c f i n a l S t r i n g TAG = " ModulesTable " ; 3 4 / 5 Constants f o r the Database t a b l e name and column names 6 / 7 p u b l i c s t a t i c f i n a l S t r i n g TABLE_MODULES = " modules " ; 8 p u b l i c s t a t i c f i n a l S t r i n g COLUMN_ID = "_id" ; 9 p u b l i c s t a t i c f i n a l S t r i n g COLUMN_MODULE_NAME = "modulename" ; 10 p u b l i c s t a t i c f i n a l S t r i n g COLUMN_MODULE_VERSION = " moduleversion " ; 11 p u b l i c s t a t i c f i n a l S t r i n g COLUMN_PACKAGE = " package " ; 12 p u b l i c s t a t i c f i n a l S t r i n g COLUMN_HEX_FILE_NAME = " hexfilename " ; 13 p u b l i c s t a t i c f i n a l S t r i n g COLUMN_ICON_NAME = "iconname" ; 14 p u b l i c s t a t i c f i n a l S t r i n g COLUMN_MD5_APK = "md5_apk" ; 15 p u b l i c s t a t i c f i n a l S t r i n g COLUMN_MD5_DSP = "md5_dsp" ; 16 p u b l i c s t a t i c f i n a l S t r i n g COLUMN_LAST_USED = " last_used " ; 17 p u b l i c s t a t i c f i n a l S t r i n g COLUMN_RELEASE_DATE = " r e l e a s e _ d a t e " ; 18 p u b l i c s t a t i c f i n a l S t r i n g COLUMN_DESCRIPTION = " d e s c r i p t i o n " ; / 21 Constant f o r the SQL command f o r c r e a t i n g the database 22 / 23 p r i v a t e s t a t i c f i n a l S t r i n g DATABASE_CREATE = " c r e a t e t a b l e " 24 + TABLE_MODULES + " ( " + COLUMN_ID 25 + " i n t e g e r primary key autoincrement, " + COLUMN_MODULE_NAME 26 + " t e x t not n ull, " + COLUMN_MODULE_VERSION + " t e x t not null, " 27 + COLUMN_PACKAGE + " t e x t not null, " + COLUMN_HEX_FILE_NAME 28 + " t e x t not n ull, " + COLUMN_ICON_NAME + " t e x t not null, " 29 + COLUMN_MD5_APK + " t e x t not n ull, " + COLUMN_MD5_DSP 30 + " t e x t not n ull, " + COLUMN_LAST_USED + " r e a l, " 31 + COLUMN_RELEASE_DATE + " t e x t not n u l l, " + COLUMN_DESCRIPTION 32 + " t e x t not n u l l " + " ) ; " ; Nils Frey / Jannick Keller 40

43 1 / Listing 6.20: ModuleTable Klasse Teil 2 2 This method g e t s c a l l e d when the database needs to be c r e a t e d. 3 I t e x e c u t e s the SQL command f o r c r e a t i n g the database. 4 database 6 SQLiteDatabase o b j e c t which i s needed to execute the SQL command. 7 / 8 p u b l i c s t a t i c void oncreate ( SQLiteDatabase database ) { 9 database. execsql (DATABASE_CREATE) ; 10 } / 13 This method g e t s c a l l e d when the database i s upgraded to a h i g h e r v e r s i o n. 14 I t d e l e t e s the old database and c r e a t e s a new one. 15 The Warning i s only shown i n the LogCat Window. 16 database 18 SQLiteDatabase o b j e c t which i s needed to execute the SQL command. 19 o l d V e r s i o n 21 Version number o f the old database. 22 newversion 24 Version number o f the new database that w i l l be c r e a t e d. 25 / 26 p u b l i c s t a t i c void onupgrade ( SQLiteDatabase database, i n t oldversion, 27 i n t newversion ) { 28 Log.w(TAG, " Upgrading database from v e r s i o n " 29 + o l d V e r s i o n + " to " + newversion 30 + ", which w i l l d e s t r o y a l l old data " ) ; 31 database. execsql ( "DROP TABLE IF EXISTS " + TABLE_MODULES) ; 32 oncreate ( database ) ; 33 } 34 } Nils Frey / Jannick Keller 41

44 TransferFrame Die Klasse TransferFrame wurde erstellt, um die Informationen des vom DSP-Board empfangenen Datenframe in einem Objekt abspeichern zu können. Listing 6.21 zeigt die darin abspeicherbaren Informationen. Zu jeder Variablen gibt es getter- und setter-methoden. Die getter-methode für die Daten gibt es in drei Ausführungen. Die erste gibt die gesamten gespeicherten Daten, die zweite gibt ein bestimmtes Byte und die dritte ein ByteArray einer bestimmten Länge von einem angegebenen Startindex aus. Für die Variable für die Länge der Daten ist eine zusätzliche Methode (incrementlength) implementiert, mit welcher die Länge um eins erhöht werden kann. Listing 6.21: Informaionsinhalt eines TransferFrame-Objektes 1 p r i v a t e byte [ ] data ; / ByteArray f o r the data / 2 p r i v a t e byte [ ] c r c = new byte [ 2 ] ; / ByteArray f o r the CRC code / 3 p r i v a t e i n t l e n = 0 ; / Length o f the data ByteArray / 4 p r i v a t e boolean i s V a l i d = f a l s e ; / Can be s e t to i n d i c a t e the v a l i d i t y o f the saved data / 5 p r i v a t e boolean isnew = f a l s e ; / Can be s e t to i n d i c a t e whether the save data i s " unused " / ModuleSelectArrayAdapter Die Klasse ModuleSelectArrayAdapter ist von der Klasse ArrayAdapter abgeleitet und wird verwendet um auf dem Modulauswahlbildschirm die Module mit Name (TextView) und Icon (Image- View) anzuzeigen. Ein Standard ArrayAdapter kann lediglich ein TextView einem GridView bzw. ListView hinzufügen. Um das Layout der Modulkacheln (Abbildung 6.6) dem GridView hinzuzufügen, muss die Methode getv iew des ArrayAdapter überschrieben werden, so dass diese das Layout anstelle eines TextView zurückgibt. Nils Frey / Jannick Keller 42

45 6.3 Module Beim Erstellen eines Android-Moduls muss auf einige Sachen geachtet werden. Diese werden in diesem Kapitel kurz erläutert. Als erstes muss darauf geachtet werden, dass beim Erstellen des Android-Projektes der Paketname mit der Zeichenkette.aca. gefolgt vom Modulname endet. Zum Beispiel lautet der Paketname des Moduls Testmodul LED ch.fhnw.aca.testmodulled Der Android Teil der Module bietet mit eine Modul-Activity die Benutzeroberäche zur Bedienung der dsv-anwendung auf dem DSP-Board. Im Hintergrund läuft ein Service, welcher sich um die Kommunikation mit dem Android-Grundgerüst kümmert. Beim Starten des Moduls vom Grundgerüst aus wird ein Messenger über den Start-Intent, unter dem Argument EX- TRA_MESSENGER, mitgegeben, damit der Service Messages zurück senden kann. Jede Message, die an den ACAMainService des gesendet wird, muss die Standardargumente what und arg1 beinhalten. Dafür sind die Konstanten, welche in Listing 6.22 gezeigt sind, zu implementieren. Dem Argument what muss der Wert der Konstanten MESSAGE_FROM_MODULE übergeben werden, dem Argument arg1 entweder MESSAGE_MODULE_TO_DSPBOARD oder MES- SAGE_MODULE_TO_ACAMAINSERVICE je nachdem, ob die gesendete Nachricht an das Grundgerüst oder das DSP-Board gerichtet ist. Um das Module bzw. die ganze ACA-Applikation zu beenden, wird der Message das Argument arg2 mit dem Wert der Konstanten MESSA- GE_MODULE_EXIT_MODULE oder MESSAGE_MODULE_EXIT_ACA übergeben. Um einen Hex-String dem DSP-Board zu schicken, muss der String in ein Bundle mit dem Argument EXTRA_MESSAGE_STRING geladen und der Message mitgegeben werden. Beim Erstellen des Modul-Services muss dem Grundgerüst ein eigener Messenger übergeben werden, wofür dem Standardargument arg2 der Message der Wert der Konstante MESSAGE_MODULE_MESSENGER und dem Standardargument obj der Messenger übergeben wird. 1 / Listing 6.22: Message-Konstanten die implementiert exakt implementiert werden müssen 2 P r i v a t e constant I n t e g e r that have to be implemented e x a c t l y t h i s way 3 / 4 p r i v a t e s t a t i c f i n a l i n t MESSAGE_FROM_MODULE = ; 5 p r i v a t e s t a t i c f i n a l i n t MESSAGE_MODULE_TO_DSPBOARD = ; 6 p r i v a t e s t a t i c f i n a l i n t MESSAGE_MODULE_TO_ACAMAINSERVICE = ; 7 p r i v a t e s t a t i c f i n a l i n t MESSAGE_MODULE_MESSENGER = ; 8 9 / 10 Public constant I n t e g e r that have to be implemented e x a c t l y t h i s way 11 / 12 p u b l i c s t a t i c f i n a l i n t MESSAGE_MODULE_EXIT_MODULE = ; 13 p u b l i c s t a t i c f i n a l i n t MESSAGE_MODULE_EXIT_ACA = ; / 16 Public constant S t r i n g s that have to be implemented e x a c t l y t h i s way 17 / 18 p u b l i c s t a t i c f i n a l S t r i n g EXTRA_MESSENGER = "MESSENGER" ; 19 p u b l i c s t a t i c f i n a l S t r i n g EXTRA_MESSAGE_STRING = "MESSAGE_STRING" ; Im AndroidManifest des Moduls muss dem Service ein IntentFilter zugewiesen werden, welcher als "action den Namen Paketname>.ACA_MODULE", sowie als category den Namen ändroid.intent.category.defaultënthält. Mit dem action-namen kann das Grundgerüst dann das Modul starten. Des weiteren muss eine Permission angegeben werden, da sonst jede Android-Applikation Nils Frey / Jannick Keller 43

46 das Modul starten kann. Da das Grundgerüst dieselbe Permission beantragen muss um auf das Modul zugreifen zu können, wird diese direkt vom Grundgerüst erstellt und muss folgendermassen lauten: ch.fhnw.androidcontrolledaudioprocessor.permission.android_controlled_audio- PROCESSOR. Listing 6.23 zeigt die Servicedeklaration des Moduls Filter Studio. 1 <s e r v i c e Listing 6.23: Servicedeklaration im AndroidManifest des Moduls Filter Studio 2 android : name=" F i l t e r S t u d i o S e r v i c e " 3 android : p e r m i s s i o n="ch. fhnw. a n d r o i d c o n t r o l l e d a u d i o p r o c e s s o r. p e r m i s s i o n. ANDROID_CONTROLLED_AUDIOPROCESSOR" > 4 <i n t e n t f i l t e r > 5 <a c t i o n android : name="ch. fhnw. aca. f i l t e r s t u d i o.aca_module" /> 6 7 <c a t e g o ry android : name=" android. i n t e n t. c a t e g o r y.default" /> 8 </i n t e n t f i l t e r > 9 </ s e r v i c e > Im raw-ordner des Resourcen-Ordners müssen mindestens die Hex-Datei des C Programmes, sowie die Info-XML-Datei des Moduls enthalten sein. Die Hex-Datei enthält den C-Code im IntelHex-Format und kann einen beliebigen Namen haben, sofern dieser den Android-Bestimmungen entspricht. Der Name der Info-XML-Datei muss aus dem letzten Teil des Paketnamens, der nach der Zeichenfolge.aca., gefolgt von _info.xml bestehen. Im Falle des oben erwähnten Moduls Testmodul LED ist dies testmodulled_info.xml. Die Info-XML-Datei muss die als Root-Element module beinhalten und darin die in Listing 6.24 gezeigten Argumente denieren. Diese werden vom Grundgerüst ausgelesen und im Datenbankeintrag zum Modul abgelegt und beim Starten des Moduls in der Detailansicht angezeigt. 1 <module Listing 6.24: Inhalt der Info-XML-Datei des Moduls Testmodul LED 2 modulename=" Testmodul LED" 3 moduleversion=" 0. 6 " 4 m o d u l e d e s c r i p t i o n="modul zum Ein und Ausschalten der LED" 5 hexfilename=" testmodulled_v1_3 " 6 moduleiconname=" testmodulled " 7 r e l e a s e d a t e=" "> 8 </module> Nils Frey / Jannick Keller 44

47 7 Filter Studio Das Filter Studio ist eine Beispielanwendung um aufzuzeigen, für welche Anwendungen sich der Android Controlled Audioprocessor eignet. Das Funktionsprinzip des Filter Studio ist einfach: Wie in Abbildung 7.1 dargestellt ist, können mit dem Filter Studio verschiedene Filter auf das Line-In-Signal des DSP-Boards angewendet werden. Das gelterte Signal wird anschliessend sowohl am Line-Out, sowie am Kopfhörer-Ausgang ausgegeben. Abbildung 7.1: Funktion des Filter Studio Das Filter Studio arbeitet mit einer Abtastfrequenz von 48 khz und es stehen je vier Tiefpass und Hochpass Filter mit Grenzfrequenzen von 500 Hz, 1 khz, 2 khz und 4 khz zur Verfügung, welche auf das Eingangssignal angewendet werden können. Zudem kann auch ein Bandpasslter eingesetzt werden, bei welchem der Benutzer zwischen den Bandbreiten 500 Hz, 1 khz, 2 khz und 4 khz auswählen, sowie auch die Mittenfrequenz des Filter selber festlegen kann. Für diese Anwendung wurden die Befehle in Tabelle 7.1 festgelegt, mit welchen das Android-Modul dem dsp Board mitteilen kann, welches Filter anzuwenden ist. Befehl Funktion 0x21 Audio OFF 0x22 Talkthrough 0x23 < F ilternr > Tiefpasslter 1 bis 4 0x024 < F ilternr > Hochpasslter 1 bis 4 0x25 < Bandbreite > < F M HB > < F M LB > Bandpasslter Tabelle 7.1: Übersicht der Befehle Der folgende Text behandelt die Implementierung der Algorithmen auf dem dspic, sowie den Aufbau und Funktion des Android User Interfaces. 7.1 dspic Die Software auf dem dspic muss hauptsächlich die folgenden drei Aufgaben übernehmen: Signlverarbeitung (Anwenden der verschiedenen Filter) Initialisierung des DSP-Boardes inklusive des Audiocodecs Kommunikation mit dem Android Gerät unterhalten Nils Frey / Jannick Keller 45

48 Wie diese drei Aufgabenbereiche in der dspic Software umgesetzt sind, wird in den nachfolgenden drei Unterkapiteln erläutert, wobei der Schwerpunkt bei der Signalverarbeitung liegt Signalverarbeitung Die Signalverarbeitung wird in der main Funktion innerhalb einer while Schleife abgearbeitet, bis die Anwendung beendet wird. Immer wenn neue Daten zum Verarbeiten anliegen, wird mit einem Switch Case entschieden, welches Filter angewendet wird. Für sämtliche Filter werden FIR Filter der Ordnung 150 verwendet. Die Filter sind mit Hilfe der dsp Bibliothek (digital signal processing Library) von Microchip implementiert worden. Die Filter wurden vorgängig mit Matlab und dem fdatool (Filter Design & Analysis Tool) designed und die Filterkoezienten wurden als Signed 16- bit Integers in C Header Dateien exportiert. Die Signalverarbeitung ist in dieser Anwendung auf eine Blockverarbeitung ausgelegt. Um aufzeigen zu können, wie die Daten in die Buer geladen werden und welche Buer für die Verarbeitung verwendet werden müssen, ist die Buerorganisation in Abbildung 7.2 dargestellt. Abbildung 7.2: Organisation der Input und Output Buer Für die A/D-Wandlung der Audiosignale ist der Audiocodec WM8731 zuständig. Dieser Wandelt in der verwendeten Konguration mit einer Abtastrate von 48 khz und einer Auösung von 16 Bit. Die gewandelten Daten werden über eine I2S Schnittstelle dem dspic gesendet. Dieser liest die Daten über einen seiner DMA Kanäle (Direct Memory Access) ein und unterteilt sie nach Abbildung 7.2 in einen linken und rechten InputBuer. Die vier Buer rxbuffera, rxbufferb, txbuffera und txbufferb werden in der DMA-Section des Data Memory des dspic alloziert. Über die I2S Schnittstelle werden die Daten in Blöcke von 256 Bytes gepackt und es werden immer zuerst die Nils Frey / Jannick Keller 46

49 Daten des linken Stereokanals gefolgt von den Daten des rechten Kanals gesendet. Um ein unterbrechungsfreies Empfangen und Senden der Daten gewärleisten zu können, werden immer wenn ein DMA Interrupt kommt (ein Empfangsbuer ist voll), die beiden Eingangsbuer und die Ausgangsbuer vertauscht, dass die Daten aus dem vollen Eingangsbuer in die zu verarbeitenden Buer geladen werden können und die verarbeiteten Daten in den leeren Ausgangsbuer geladen werden können. Die neu empfangenen Daten können somit auch wieder in einen leeren Buer geschrieben werden und der Buer zum Senden der Daten ist gefüllt. Diese Buerorganisation wird in der Datei DMA.c durchgeführt und für die Signalverarbeitung können immer die Buer lef tinputbuf f er, lef toutputbuf f er, rightinputbuf f er und rightoutputbuf f er verwendet werden. Für die Implementation eines FIR Filter mit Hilfe der dsp Bibliothek sind die im Codeausschnitt 7.3 dargestellten drei Elemente erforderlich. Mit den im Codeausschnitt gezeigten Zeilen wird das Tiefpasslter mit der Grenzfrequenz von 500 Hz realisiert. Listing 7.3: Implementierung eines FIR Tiefpass 1 // Deklarationen i n der Header Datei 2 #d e f i n e fir_lp_taps f r a c t i o n a l attribute ( ( space ( ymemory ), f a r ) ) f i r _ l p _ l e f t _ s t a t e [ fir_lp_taps ] ; 4 f r a c t i o n a l attribute ( ( space ( ymemory ), f a r ) ) f i r _ l p _ r i g h t _ s t a t e [ fir_lp_taps ] ; 5 6 FIRStruct f i r _ l p 1 l e f t _ s t r u c t ; 7 FIRStruct f i r _ l p 1 r i g h t _ s t r u c t ; 8 9 const f r a c t i o n a l f i r _ l p 1 _ c o e f f [ fir_lp_taps ] = { 2, 2, 1,..., 1, 2, 2 } ; // Einmalige I n i t i a l i s i e r u n g des S t r u c t und Delay 12 F I R S t r u c t I n i t (& f i r _ l p 1 l e f t _ s t r u c t, fir_lp_taps, f i r _ l p 1 _ c o e f f, builtin_psvpage ( f i r _ l p 1 _ c o e f f ), f i r _ l p _ l e f t _ s t a t e ) ; 13 FIRDelayInit(& f i r _ l p 1 l e f t _ s t r u c t ) ; 14 F I R S t r u c t I n i t (& f i r _ l p 1 r i g h t _ s t r u c t, fir_lp_taps, f i r _ l p 1 _ c o e f f, builtin_psvpage ( f i r _ l p 1 _ c o e f f ), f i r _ l p _ r i g h t _ s t a t e ) ; 15 FIRDelayInit(& f i r _ l p 1 r i g h t _ s t r u c t ) ; // Bei j e d e r F i l t e r u n g aufzurufende Funktionen 18 FIR (128, l e f t O u t p u t B u f f e r, l e f t I n p u t B u f f e r, &f i r _ l p 1 l e f t _ s t r u c t ) ; 19 FIR (128, rightoutputbuffer, r i g h t I n p u t B u f f e r, &f i r _ l p 1 r i g h t _ s t r u c t ) ; Weil die Verarbeitung in zwei Blöcken der Länge 128 anstatt einem Block der Länge 256 vorgesehen ist (linker und rechter Kanal werden separat verarbeitet), werden für eine Tiefpasslter zwei Filter benötigt. In einer Header Datei müssen für jedes Filter ein State, ein Stuct und Filterkoezienten deklariert werden. Damit die dsp Bibliothek die Filter ezient rechnen kann, müssen die Filter State im X Datenbereich des Datenmemory abgelegt werden und die Filterkoezienten im Y Datenbereich. Dadurch kann die dsp Bibliothek gleichzeitig auf die Koezienten und den State zugreifen und diese miteinander verrechnen. Der Filter State muss immer gleich gross sein, wie die Anzahl verwendeter Filterkoezienten. Da sämtliche verwendeten Filter dieselbe Anzahl Koezienten haben und nicht mehrere Filter gleichzeitig angewendet werden, können für sämtliche Filter dieselben Structs verwendet werden, was den benötigten Speicherbereich im Y Datenbereich stark reduziert. Die Strukur der Software ist so gestaltet, dass jedes Mal wenn vom Android Gerät ein Befehl kommt, dass ein neues Filter angewendet werden muss, eine Variable gesetzt wird, und darauf in der main Funktion vor der Anwendung der Filter, die entsprechenden Filter initialisiert werden. Für die Initialisierung müssen, wie im Listing 7.3 zu sehen ist, nur die korrekten Structs mit der Funktion F IRStructInit und die dazugehörigen Delays mit der Funktion F IRDelayInit initialisiert werden. Nils Frey / Jannick Keller 47

50 Im Hauptablauf werden durch Aufruf der Funktion F IR die Filter angewandt. Der Funktion müssen die zur verarbeitende Blockgrösse, der Zielbuer, der Quellbuer und das zu verwendende Filterstruct übergeben werden. Sämtliche Tiefpass- und Hochpasslter wurden mit dem fdatool von Matlab entworfen. Damit für alle Filter derselbe Filterstate verwendet werden kann, haben alle Filter die gleiche Anzahl Koezienten. Es wurden FIR Filter gewählt, da diese sehr einfach mit der dsp Bibliothek zu implementieren sind und wenn sie mit Windowing entworfen werden, einen linearen Phasengang aufweisen. Als Designmethode wurde, wie erwähnt, Windowing benutzt wobei zur Gewichtung der Koezienten ein Hamming Fenster verwendet wurde. Bei Filtern der Ordnung 150 resultieren 151 Achsensymmetrische Koezienten wobei sich der Mittlere Filterkoezient gerade auf der Symmetrieachse bendet. In der Abbildung 7.4 ist der Amplitudengang, sowie die normierte Impulsantwort des entworfenen Tiefpasslters mit der Grenzfrequenz 4 khz dargestellt. Weil für das Filter Studio nicht speziziert wurde um wie viel Dezibel das Sperrband dämpfen muss und auch keine exakten Anforderungen an die Steilheit der Flanken vorliegen, sondern lediglich der akustische Eekt der Filter zum tragen kommen soll, genügen die verwendeten Filter mit ihren 151 Koezienten. In Abbildung 7.4 ist zu erkennen, dass die Dämpfung im Sperrband > 55dB beträgt und auch die Flankensteilheit ist genügend steil, dass der Übergang akustisch kaum hörbar sein wird. Die Bandpasslter werden nicht wie die Tief- und Hochpasslter mit Matlab designed, sondern ihre Koezienten werden aus den Koezienten der Tiefpasslter berechnet. Die Berechnung der Koezienten erfolgt mit Hilfe der Formel 7.1 und ermöglicht es die Mittenfrequenz F m des Bandpasses frei zu wählen. b BP [n] = b T P [n] cos (2πf m nt ) (7.1) Diese Synthesemethode nutzt die Eigenschaft des Kosinus, dass dessen Fouriertransformation aus zwei positiven Diracstössen besteht. Eine Multiplikation der Filterkoezienten mit einem Kosinus entspricht der Faltung des Übertragungsfunktion mit dem Spektrum des Kosinus. Daraus folgt die Übertragungsfunktion eines Bandpasslter mit einer Bandbreite, welche doppelt so gross ist wie die Grenzfrequenz des zugrundeliegenden Tiefpass Filters. Die Mittenfrequenz des Bandpass wird dabei durch f m bestimmt. Dieser Ansatz ermöglicht es einerseits, mit relativ geringem Rechenaufwand Bandpasskoezienten zu berechnen, andererseits eignet er sich gut, da die Koezienten einmal, bei der Initialisierung des Filters gerechnet werden müssen und anschliessend kann der Bandpass genau gleich angewendet werden wie die Hoch- und Tiefpasslter. Das in Listing 7.5 erstellte Bandpasslter basiert auf dem Tiefpasslter 1, mit einer Grenzfrequenz von 500 Hz und hat somit eine Bandbreite von 1 khz. Die Mittenfrequenz ist in der globalen Variable F m abgelegt und wird vom Android Gerät mitgesendet, wenn dieses den Befehl für die Anwendung eines Bandpasslters schickt. Weil das Filter Studio nebst dem Anwenden von Filtern auch die Modi Stummschalten und Talkthrough unterstützen muss, ist bei jedem Befehl, welcher vom Android Gerät kommt, der Audiocodec umzukongurieren. Es werden drei verschiedene Kongurationen benötigt. Um den Ausgang auszuschalten, wird mit der Funktion W M 8731_M ute() der WM8731 so konguriert, dass der Audiocodec weder am Line-Out noch am Kopfhörerausgang irgendetwas ausgibt. Um einen Talkthrough realisieren zu können, müssen die Audiodaten nicht an den dspic und wieder zurückgesendet werden, sondern der Audiocodec wird so konguriert, dass er das Signal am Line-In intern an den Line-Out und Kopfhörerausgang weiterleitet. In diesem Fall ist auch keine A/D so- Nils Frey / Jannick Keller 48

51 Abbildung 7.4: Amplitudengang und Impulsantwort des Tiefpasslters 4 Listing 7.5: Implementierung eines FIR Tiefpass 1 f o r ( i = 1 ; i < ; i ++) { 2 fir_bp2_coeff [ i ] = f i r _ l p 1 _ c o e f f [ i ] cos ( 2. 0 PI Fm i / 48000) ; 3 } 4 F I R S t r u c t I n i t (& f i r _ b p 2 l e f t _ s t r u c t, fir_lp_taps, fir_bp2_coeff, COEFFS_IN_DATA, f i r _ l p _ l e f t _ s t a t e ) ; 5 FIRDelayInit(& f i r _ b p 2 l e f t _ s t r u c t ) ; 6 F I R S t r u c t I n i t (& f i r _ b p 2 r i g h t _ s t r u c t, fir_lp_taps, fir_bp2_coeff, COEFFS_IN_DATA, f i r _ l p _ r i g h t _ s t a t e ) ; 7 FIRDelayInit(& f i r _ b p 2 r i g h t _ s t r u c t ) ; Nils Frey / Jannick Keller 49

52 wie darauolgende D/A-Wandlung notwendig. Diese Konguration wird durch Aufruf der Funktion W M 8731_Codectalkthrough() erreicht. Für sämtliche Filter muss der Audiocodec mit der Funktion init_w M 8731() so konguriert werden, dass er das Eingangssignal A/D-Wandelt, über die I2S Schnittstelle an den dspic sendet, dieser die Daten verarbeitet, zurücksendet und der Codec die verarbeiteten Audiosignale dann D/A-Wandelt und ausgibt. Im Listing 7.5 ist der Codeausschnitt dargestellt, wo die Filterkoezienten des Bandpasslters gerechnet werden mit der anschliessenden Initialisierung der Filter Initialisierungen In dieser Anwendung müssen etliche Komponenten und Schnittstellen initialisiert werden. Dazu gehören der Takt, die I2C Schnittstelle, die I2S Schnittstelle, die Uart Schnittstelle, der DMA sowie der Audiocodec. Mit Ausnahme des Audiocodec, welcher bei jedem neuen Filter wieder neu initialisiert werden muss, werden all diese Initialisierungen einmalig beim Start dieser Anwendungen durchgeführt. Die Konguration des Audiocodec wird über die I2C Schnittstelle durchgeführt. Diese, sowie auch der Takt müssen also funktionieren um den WM8731 kongurieren zu können. Der Audiocodec wird vom dspic über eine I2C Schnittstelle konguriert, indem 10 Register beschrieben werden. Durch Beschreiben der ersten beiden Register (0 und 1) kann der linke und rechte Kanal des Line-In konguriert werden. Die nächsten beiden Register kongurieren den Kopfhörerausgang. Mit dem fünften und sechsten Register wird der analoge resp. digitale Teil des Audiopfades konguriert. Im register 6 können einzelne Komponenten des Codecs ausgeschaltet werden. Das Register 7 konguriert die I2S Schnittstelle und im Register 8 kann die Samplingfrequenz geändert werden. Mit Hilfe des Registers 9 kann die I2S Schnittstelle des Codecs ein- und ausgeschaltet werden. Welche Werte in die Register geschrieben werden müssen, um diese zu kongurieren kann im Datenblatt des Audiocodecs [12] nachgelesen werden. Um das Mapping von gewissen Funktionalitäten auf I/O-Pins durchführen zu können, muss das I/O Lock Enable bit gelöscht und anschliessend wieder gesetzt werden. Wenn die Initialisierung in mehreren Funktionsaufrufen verschachtelt durchgeführt wird, ist darauf zu achten, dass dieses Bit nur ganz zu Beginn der Initialisierungen gesetzt und ganz am Ende wieder gelöscht wird Kommunikation Die Kommunikation mit dem Android Gerät basiert auf demselben Framework vom Microchip Bootloader [6], welches auch beim Bootloader verwendet wurde. Es wurden allerdings auch zur Bootloaderversion einige entscheidende Änderungen vorgenommen. Da das Grundprinzip aber im Kapitel erklärt wird, wird hier nur noch auf die Änderungen zum Bootloader Framework hingewiesen. Im Bootloader Upgrade Mode wird die Kommunikation mit dem User Interface gewährleistet indem der Uart-Task und der Framework-Task andauernd hintereinander aufgerufen werden. Weil in dieser Anwendung nebst diesen Tasks noch die Filter angewendet werden müssen, könnte es zu Datenverlusten in der Kommunikation mit dem Android Gerät kommen während die Filterfunktion ausgeführt werden. Aus diesem Grund wird nur noch der Framework Task in der gleichen Schleife wie die Filteranwendungen ausgeführt. Der UartT ask aus dem Bootloader-Framework wurde in zwei Teile unterteilt: Auf den Uart Receive Pin wurde ein Interrupt eingerichtet und wenn dieser auslöst wird der Teil des ursprünglichen Uart Task ausgeführt, welcher für das Empfangen der reinkommenden Daten verantwortlich ist. Somit ist sichergestellt, dass einkommende Daten immer empfangen werden, auch wenn gerade die F IR Funktion aus der dsp Bibliothek ausgeführt wird. Im Listing 7.6 Nils Frey / Jannick Keller 50

53 wird die soeben beschrieben Interruptrutine gezeigt. Listing 7.6: Datenempfang in einer Interruptrutine 1 void attribute ( ( interrupt, no_auto_psv ) ) _U2RXInterrupt ( void ) { 2 unsigned char Rx ; 3 // Check any c h a r a c t e r i s r e c e i v e d. 4 i f ( GetChar(&Rx) ) { 5 // Pass the bytes to frame work. 6 BuildRxFrame(&Rx, 1) ; 7 } Derjenige Teil des ursprünglichen U artt ask, welcher für das Senden der Daten verantwortlich ist, wurde am Ende der Funktion HandleCommand eingefügt. Das ist die Funktion, welche die unterschiedlichen Befehle ausführt, die vom Android Gerät ankommen. Da diese Funktion die Rückgabewerte der Befehle in den Uart Transmitbuer schreibt und zudem die einzige Funktion ist, welche in den Transmitbuer schreibt, liegt nach dieser Funktion immer ein komplettes Transmitframe vor. 7.2 Android Die Android-Seitige Implementierung des Filter Studios besteht im Wesentlichen aus einer Activity (FilterStudioActivity), welche die Benutzeroberäche verwaltet und einem Service(FilterStudioService), welcher die Daten aufbereitet, und an das Grundgerüst sendet Benutzeroberäche Die Benutzeroberäche besteht aus drei Ansichten, je eine für die Hoch-, Tief- und Bandpässe, sowie einem Rahmen bei dem am oberen Rand der Haupt-Ein-Aus-Button und die Talkthrough-Auswahl angebracht sind. Die Abbildungen 7.7, 7.8 und 7.9 zeigen die Ansichten der Filter. Die Ansichten für die Hoch- und Tiefpässe sind, bis auf den Titel und die Grafen, identisch. Über die RadioButtons kann zwischen den vier verschiedenen Grenzfrequenzen ausgewählt werden und mit dem ToggleButton kann der Tief- bzw. Hochpass ein- und ausgeschaltet werden. Die Grafen, welche angezeigt werden, sind die in MatLab erzeugten Grafen zu den entsprechenden Filtern. Beim Bandpass sind auch vier RadioButtons angebracht, über welche die Bandbreite ausgewählt werden kann. Zudem kann über den horizontalen Slider oder das EditText-Feld die Mittelfrequenz in 1 Hz-Schritten eingestellt werden. Es kann durch einfaches Wischen nach links oder rechts zwischen den Ansichten hin und her gewechselt werden. Um dies zu realisieren, musste für jede Ansicht eine Klasse erstellt werden, welche die Klasse Fragment erweitert. In diesen werden dann wie in Activities die Layouts geladen und auf die Benutzereingaben reagiert, nur können diese exibler in der Ansicht angeordnet werden. Die Activity FilterStudioActivity sorgt dafür, dass die Fragments erstellt und an der richtigen Stelle eingefügt werden. Zudem läuft die Kommunikation zwischen den Fragments über die Activity. Sie verwaltet die Benutzereingaben vom Haupt-Ein-Aus-Button und der Talkthrough-CheckBox. Bei einer Benutzereingabe wird eine Nachricht an den Service und je nach Eingabe auch eine an die Activity gesendet. Bei den Hoch- und Tiefpässen wird einfach eine Message mit der entsprechenden Auswahl gesendet. Bei den Bandpässen wird dies auch gemacht jedoch noch mit der Information über die Position des Sliders. Nils Frey / Jannick Keller 51

54 Abbildung 7.7: Screenshot der Hochpassansicht Abbildung 7.8: Screenshot der Tiefpassansicht Nils Frey / Jannick Keller 52

55 Abbildung 7.9: Screenshot der Bandpassansicht Service Der Service FilterStudioService empfängt die Benutzerauswahlen von den Fragments und der Activity, verarbeitet diese weiter und sendet sie dann an das Grundgerüst. Für die Tief- und Hochpässe wird einfach aufgrund der RadioButton-Auswahl der entsprechende Befehls-Hex-String für das DSP-Board an das Grundgerüst gesendet. Bei den Bandpässen wird zusätzlich noch aufgrund der Position des Sliders die Mittelfrequenz berechnet und dem entsprechenden Befehls-Hex-String angehängt. Wenn der Talkthrough ausgewählt wird oder mit dem Haupt-Ein-Aus-Button ausgeschaltet wird, wird ebenfalls der entsprechenden Befehls-Hex-String an das Grundgerüst gesendet. Beim Einschalten über den Haupt-Ein-Aus-Button wird der Befehls-Hex-String des Zustandes gesendet, welcher vor dem Ausschalten aktiv war. Nils Frey / Jannick Keller 53

56 8 Zusammenfassung und Ausblick Beim diesem Projekt Android Controlled Audioprocessor hat es sich um ein äusserst vielseitiges und interessantes Projekt gehandelt. Softwareentwicklung auf Android sowie in C für einen Signalprozessor waren der Hauptbestandteil dieses Projektes, es beinhaltete aber auch Hardwareentwicklung und wir mussten uns mit Signalverarbeitung und der Kommunikation über eine Bluetooth Verbindung beschäftigen. Laut Aufgabenstellung waren konkret die folgenden Bestandteile zu realisieren: Bluetooth Modul Bootloader zum Laden der DSV-Software über Bluetooth Android Applikation zum Verwalten, Laden und Bedienen unterschiedlicher DSV-Anwendungen Mindestens eine DSP-Applikation (Ein Erweiterungsboard mit einfachen Bedienelementen und/oder einer Speichererweiterung) Als Bluetooth Modul haben wir das Modul RN-42 verwendet und steuern dies vom dspic über eine Uart Schnittstelle an. Dieses Modul funktioniert und erfüllt seine Aufgabe zuverlässig. Für die Imlementierung des Bootloaders haben wir auf einen bestehenden Bootloader von Microchip zurückgegrien und diesen so verkleinert und angepasst, dass er auf dem DSP-Board einsetzbar ist und über eine Uart Schnittstelle und das Bluetooth Modul mit dem Android Gerät Daten austauschen und eine neue DSV-Software ins Flash laden kann. Eine Android Applikation welche die Applikationen herunterladen, installieren, auf das DSP-Board laden und anschliessend starten kann, wurde auch erstellt. Diese Android Applikation unterhält die gesamte Kommunikation zwischen den DSP-Applikationen auf dem Android Gerät und dem laufenden Signalverarbeitungsprogramm auf dem dspic. Als erste DSP-Applikation wurde ein Filter Studio entwickelt, welches über ein übersichtliches User Interface verfügt und über anwendbare Sets von Hoch-, Tief- und Bandpassltern verfügt. Für die Realisierung weiterer DSP-Applikationen oder eines Erweiterungsboards war der zeitliche Rahmen des Projektes leider zu knapp. Bei dem entwickelten Android Controlled Audioprocessor handelt es sich allerdings noch nicht um ein Serie reifes Produkt sondern erst um einen Prototypen. Sowohl die Android Software als auch die Software auf dem dspic läuft noch nicht fehlerfrei und es kann bei der DSV-Applikation Filter Studio auch noch vorkommen, dass das ausgewähltes Filter nicht angewendet wird oder ein anderer Fehler auftritt. Es wäre sinnvoll, für die Optimierung und Überarbeitung der Software noch einige Zeit zu investieren, grundsätzlich erfüllen aber alle geschriebenen Programme (auf Android und dem dspic) ihre Funktion. Diese Projekt hat unserer Meinung nach aufgezeigt, dass ein Android Gerät für die Bedienung und das Laden von Software auf einen Signalprozessor gut geeignet ist und dies auch umgesetzt werden kann. Für eine Weiterführung dieses Projektes, was unserer Meinung nach zweifellos spannend und durchaus erfolgsversprechend ist, sollten einige Punkte betreend der aktuellen Hard- und Software beachtet werden, welche noch Fehlerhaft sind oder eine Überarbeitung erfordern. Ausserdem benden sich in der folgenden Liste weitere wichtige Hinweise, welche beachtet werden sollten wenn man mit dem ACA arbeitet: Die Resetschaltung des DSP-Boards funktioniert nicht einwandfrei. Es kann vorkommen, dass sich der dspic in einem Fehlerhaften Zustand bendet und ein drücken des Reset Tasters keine Auswirkungen hat. In diesem Fall kann nur durch einen Power-Down Reset durch Unterbrechung der Stromversorgung ausgeholfen werden. Ausserdem wird der Reset Eingang des RN-42 Moduls im Moment gar nicht verwendet. Nils Frey / Jannick Keller 54

57 Um aus dem DSP-Board ein fertiges Produkt zu mache ist eine Überarbeitung der Hardware erforderlich wobei wir empfehlen das Bluetooth Modul direkt auf der Grundplatine zu platzieren. Es sollte ausserdem darüber Nachgedacht werden den zweiten Erweiterungsport mit einer Spannung von 3.3 V anstatt 5 V zu versorgen. Die Line-In Klinkebuchse sollte nicht mit einem Kopfhörerausgang von einem Laptop oder Smartphone, usw. getrieben werden. Wie im Kapitel beschrieben, muss ein zusätzliches Kongurationsbit gesetzt werden, wenn der Debugger verwendet werden soll. Wenn das Filter Studio vor allem für die Filterung von Sprachsignalen eingesetzt wird, müsste wäre eine Herabsetzung der Taktfrequenz auf 32 khz oder eventuell sogar 8 khz sinnvoll, da dann steilere Filteranken bei gleicher Anzahl Koezienten erreicht werden könnten. Die Kommunikation zwischen dem DSP-Board und dem Android Gerät sollte durch beidseitige Optimierungen verbessert werden, da es noch zu Fehlern in der Übertragung kommt und die Übertragungsgeschwindigkeit nicht ausgenutzt wird. Die Klasse ModuleSelectArrayAdapter muss überarbeitet werden, da bei mehreren installierten Modulen alle Module mit dem Namen und dem Icon des Letzten erscheinen. Android-Seitig sollte noch mehr auf die Rückmeldungen des DSP-Boards eingegangen werden. Es sollte abgeklärt werden ob es sich lohnt eine Weiterleitung der empfangenen Daten an das Android Modul zu implementieren. Wenn die bis implementierten Funktionen sauber laufen und auch die soeben genannten Fehler behoben und Hinweise beachtet wurden, wäre es eine spannende und nützliche Weiterentwicklung eine Software zu entwickeln, welche es ermöglicht auf eine einfache und benutzerfreundliche Art neue DSV-Module zu erstellen. Abschliessend zu diesem Projekt können wir sagen, dass wir dieses Projekt äusserst spannend, sowie auch lehrreich fanden. Nach einer relativ aufwändigen Einarbeitungszeit konnten wir uns stark in der Materie vertiefen und vieles interessantes umsetzen. Dennoch haben wir die Grösse und den Aufwand, welchen dieses Projekt dank seiner Flexibilität und Vielseitigkeit mit sich bringt etwas unterschätzt und uns gerne noch ein bisschen länger mit diesem Projekt beschäftigt. Nils Frey / Jannick Keller 55

58 9 Bibliographie Literatur [1] Android Open Source Project - Android Developers. [On-line]. Available: android.com/index.html[august 13, 2013] [2] Bach Mike (2011, Dezember) Mobile Anwendungen mit Android. Deutschland:Addison-Wesley. [3] Galileo Computing (2011) :: Java ist auch eine Insel XML-Dateien mit JDOM verarbeiten [On-line]. Available: html[august 16, 2013] [4] Grid View Android Developers [On-line]. Available: topics/ui/layout/gridview.html[august 13, 2013] [5] Lammert Bies (2013, Februar) On-line CRC calculation and free library [On-line]. Available: 16, 2013] [6] Microchip Technology Inc (2011) dspic33e/pic24e Bootloader ReadMe. [On-line]. Available: 20Auxiliary%20Flash%20Bootloader.zip[August 5, 2013] [7] Roving Networks (2013, April) RN42/RN42N Class 2 Bluetooth Module. [On-line]. Available: [August 5, 2013] [8] Samples Android Developers - BluetoothChat [On-line]. Available: com/tools/samples/index.html[august 13, 2013] [9] Stack Overow Forum. [On-line]. Available: 13, 2013] [10] Wikipedia (2013, August) Extensible Markup Language [On-line]. Available: mja3b868c348f3f738e42cfdbea9cbc8f6[august 16, 2013] [11] Wikipedia (2013, June) Intel HEX. [On-line]. Available: Intel_HEX [August 8, 2013] [12] Wolfson Microelectronics (2012, October) Portable Internet Audio CODEC with Headphone Driver and Programmable Sample Rates. [On-line]. Available: documents/uploads/data_sheets/en/wm8731.pdf[august 14, 2013] [13] Xue Ming (2013, February) Designing bootloader for Microchip dspic33e/pic24e micro-controller (2). [On-line]. Available: designing-bootloader-for-microchip-dspic33epic24e-micro-controller-2/[august 8, 2013] Nils Frey / Jannick Keller 56

59 A Anhang Nils Frey / Jannick Keller 57

60 A.1 Aufgabenstellung B a c h e l o r T h e s i s ACA Android Controlled Audioprocessor Studierende: Nils Frey Jannick Keller Betreuender Dozent: Prof. Dr. Markus Hufschmid Experte: Dr. Jürg Stettbacher Dr. M. Hufschmid Frühlingssemester 2013 Nils Frey / Jannick Keller 58

61 Einleitung Basierend auf dem im P5 entwickelten DSP-Board soll ein flexibles und benutzerfreundliches System zur Verarbeitung von Audiosignalen entworfen und realisiert werden, welches für eine Vielzahl von Anwendungsbereiche eingesetzt werden kann: Hi-Fi Amateurfunk Messungen im Audiobereich Android Controlled Audioprocessor Die entsprechenden Signalverabeitungsprogramme sollen mit Hilfe eines Android-Tablets auf das DSP-Board geladen werden können. Anschliessend soll das Tablet auch als Benutzerschnittstelle dienen. Die Datenübertragung zwischen Tablet und DSP-Board soll über Bluetooth erfolgen. Android Tablet Stereo In Stereo Out BT- Modul DSP & Codec Expansion Board Für gewisse Anwendungen kann es sinnvoll sein, das DSP-Gerät um einfache Bedienelemente (Schalter, Encoder, ) oder um einen grösseren Speicherbereich zu erweitern. Der Entwurf eines entsprechenden Erweiterungs-Boards soll jedoch nur mit geringer Priorität verfolgt werden. Zielsetzung Ziel dieses Projekts ist es, ein funktionsfähiges System bestehend aus DSP-Board, Bluetooth- Übertragung und Android-Software zu entwerfen. Zusätzlich soll als Beispiel mindestens eine Signalverarbeitungs-Applikation realisiert werden. Gehen Sie im Detail wie folgt vor: 1. Konzeptentwurf Das Konzept soll eine möglichst flexible Nutzung des Systems erlauben. Gleichzeitig soll auf die Benutzerfreundlichkeit Wert gelegt werden. Bevor Sie das Konzept erstellen, sollten Sie verschiedene Anwendungsfälle untersuchen und daraus Anforderungen an das System ableiten. Beispiele von Anwendungsfällen könnten sein: Konfigurierbare Bandpass-, Tiefpass- und/oder Hochpassfilter für den Amateurfunkbereich. Ebenso adaptive Notch- oder Rauschunterdrückungsfilter. Oktave-Equalizer für Hi-Fi-Anwendungen. Effektgerät für Bühne/Studio/DJ. Adaptives Filter zur Optimierung von Lautsprecheranlagen. Audiomessgerät zur Ermittlung des Übertragungsverhaltens. 2 Nils Frey / Jannick Keller 59