Kommunikation med extern, avancerad GPS-utrustning via mobil …680409/FULLTEXT01.pdf · 2013. 12. 18. · Kommunikation med extern, avancerad GPS-utrustning via mobil enhet JOEL

Kommunikation med extern, avancerad GPS-utrustning via mobil enhet

J O E L P E T T E R S S O N

Examensarbete Stockholm, Sverige 2013

Kommunikation med extern, avancerad GPS-utrustning via mobil enhet

J O E L P E T T E R S S O N

DD221X, Examensarbete i datalogi om 30 högskolepoäng Programmet för datateknik 270 högskolepoäng

Masterprogrammet i datalogi 120 högskolepoäng Kungliga Tekniska Högskolan år 2013 Handledare på CSC var Jeanette Hellgren Kotaleski Examinator var Anders Lansner TRITA-CSC-E 2013:014 ISRN-KTH/CSC/E--13/014--SE ISSN-1653-5715 Kungliga tekniska högskolan Skolan för datavetenskap och kommunikation KTH CSC 100 44 Stockholm URL: www.kth.se/csc

Referat

Syftet med detta projekt är att undersöka möjligheten attkommunicera med en militär GPS-mottagare via serieports-gränssnittet RS-232 från en mobil enhet. Målet är att en-dast använda existerande hårdvara som inte kräver att en-hetens fasta programvara eller operativsystem byts ut. Smart-telefoner och pekplattor har blivit allt vanligare och de er-bjuder i regel högre grad av bärbarhet och bättre batteri-tid än traditionella bärbara datorer, samtidigt som derasberäkningskapacitet är likvärdig. De två största systemenpå marknaden idag är Android och iOS. Jag valde där-för att undersöka deras möjligheter att anslutas till kring-utrustning genom RS-232. Under utredningen framkom tvålösningar som implementerades: ett Apple-godkänt tillbehörför RS-232 till iOS och en generisk serieportsadapter till enAndroid-enhet med USB-värdstöd. Båda lösningarna visadesig fungera och resulterade i en prototyp-applikation för varoch en av plattformarna. Jag drar slutsatsen att de är funk-tionellt ekvivalenta, men bedömer att Android-lösningen ärnågot mer framtidssäker än iOS-lösningen. Detta projektvisar att både Android- och iOS-enheter kan kommuniceramed militära GPS-mottagare och all annan kringutrustningsom har stöd för RS-232.

Abstract

Communication with external, advanced

GPS equipment through mobile device

The objective of this project is to examine the possibil-ity to communicate with a military GPS receiver over theRS-232 serial port interface from a mobile device. Only ex-isting hardware is considered that does not require replace-ment of the firmware or operating system of the device.Smartphones and tablets have been introduced to the mar-ket generally offering higher portability and better batterylifetime than traditional laptop computers, and they havethe same magnitude of processing power. The most usedmobile device platforms today are Android and iOS. I there-fore chose to investigate their possibilities to be connectedto peripherals using RS-232. During the investigation twosolutions were found and implemented: an Apple-approvedRS-232 accessory for iOS and a generic serial port adapteron a USB host enabled device running Android. Both ap-proaches appeared to function and resulted in a prototypeapplication for each one of them. I conclude that they arefunctionally equivalent, however, I asses the Android solu-tion to be a bit more future-proof than the iOS solution.This project shows that both Android and iOS devices canbe used to communicate with military GPS receivers andwith any other peripheral supporting RS-232.

Innehåll

1 Inledning 11.1 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Problemformulering . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Teoretisk referensram 42.1 Seriell datakommunikation . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.1 RS-232 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.1.2 USB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 iOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Metod 11

4 iOS-enhet med Apple-godkänt serieportstillbehör 134.1 Grundläggande hårdvarutest . . . . . . . . . . . . . . . . . . . . . . 144.2 Mottagande av data från GPS-mottagaren via RS-232 . . . . . . . . 144.3 Integrering av existerande programvarubibliotek . . . . . . . . . . . . 17

4.3.1 Separerad interaktion mellan Objective-C och C++ . . . . . 174.4 Verifiering av sändning och mottagande av data från GPS-mottagaren 23

5 Android-enhet med serieportsadapter 265.1 Utforskning av USB host API och serieportsadaptern . . . . . . . . . 27

5.1.1 USB host API . . . . . . . . . . . . . . . . . . . . . . . . . . 275.1.2 Serieportsadaptern . . . . . . . . . . . . . . . . . . . . . . . . 285.1.3 Resulterande programvarubibliotek – UsbSerial . . . . . . . . 29

5.2 Integrering av ICDlib med Android NDK . . . . . . . . . . . . . . . 305.2.1 Android NDK . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.2.2 Java Native Interface (JNI) . . . . . . . . . . . . . . . . . . . 345.2.3 Ihopkoppling med UsbSerial . . . . . . . . . . . . . . . . . . . 37

6 Slutsats 40

Litteraturförteckning 42

Bilagor 46

A Detaljerad information om USB-serieportsadaptern 46

Kapitel 1

Inledning

I det här inledande kapitlet ger jag en kortfattad bakgrund till projektet, formulerarproblemet och presenterar aktuella avgränsningar.

1.1 Bakgrund

Datakonsultföretaget Sjöland & Thyselius har under flera år arbetat med uppdragåt kunder inom försvarssektorn. Bland dem kan nämnas Försvarets materielverk,Försvarsmakten och Totalförsvarets forskningsinstitut. [36] Under dessa år har före-taget bland annat arbetat med den militära GPS-utrustningen Defense AdvancedGPS Receiver (DAGR) – en komplett, handhållen GPS-mottagare med möjlighetatt utnyttja den militära GPS-tjänsten Precise Positioning Service, vilken medgerhögre precision och robusthet än vad som tillåts av den civila motsvarigheten Stan-dard Positioning Service [17].

GPS-mottagaren har ett serieportsgränssnitt som stöder kommunikation över pro-tokollen ICD-GPS-153 och NMEA 0183. Det senare är mer begränsat i vad dettillåter för informationsutbyte och hur det kan göras. NMEA 0183 är till exempelenkelriktat från en sändande enhet till en eller flera lyssnande medan kommunikatio-nen i ICD-GPS-153 är dubbelriktad. Genom ICD-GPS-153-protokollet är det liksomNMEA 0183 möjligt att erhålla positions-, navigerings- och tidsinformation, mendet går även att konfigurera GPS-mottagaren, initiera självdiagnostiksrutiner ochutföra många andra uppgifter som kan vara aktuella för en militär GPS-mottagare.DAGR är inte nödvändigtvis ensam om att följa ICD-GPS-153-protokollet. Det kandärmed finnas GPS-utrustning med helt andra egenskaper där det enda de två hargemensamt är serieportsgränssnittet med stöd för samma protokoll. Som exempelkan nämnas en svart låda-mottagare, det vill säga en GPS-mottagare som helt sak-nar användargränssnitt, eller har ett mycket begränsat sådant med endast ett fåtalfunktionsknappar för inmatning och enkla indikeringslampor för utdata.

Tidigare arbete med GPS-mottagaren på Sjöland & Thyselius har resulterat i ettprogramvarubibliotek skrivet i C++ tillgängligt för persondatorer med antingen

1

KAPITEL 1. INLEDNING

Microsoft Windows eller POSIX-kompatibla operativsystem som kan användas vidapplikationsutveckling för att underlätta kommunikationen över ICD-GPS-153. Bib-lioteket förutsätter tillgång till en fysisk serieport på datorn eller en virtuell serieportvia en serieportsadapter, företrädesvis ansluten via USB.

Syftet med mitt projekt är att undersöka möjligheten att ansluta GPS-mottagarentill mobila enheter som i regel saknar serieportsgränssnitt och inbyggt stöd för se-rieportsadaptrar, men som i gengäld ofta har hög mobilitet och god batteritid ijämförelse med exempelvis bärbara persondatorer. Det är två intressanta aspekterdå GPS-utrustningen i ett tänkbart scenario kan sitta fastmonterad ute på ett for-don – till exempel en båt eller stridsvagn – dit det inte är rimligt att ta med vanligapersondatorer eller där det kanske saknas laddningsmöjligheter. Det kan röra sigom en svart låda-mottagare som beskrevs tidigare, eller en GPS-mottagare som ärsvårtillgängligt placerad. I ett sådant fall är det önskvärt att kunna skicka ut entekniker som med minimal utrustning kan genomföra systemkontroller, konfigureraeller diagnostisera mottagaren. Målet är att slutligen ha en eller flera prototypersom på ett konceptuellt plan visar vad som är möjligt och vilka begränsningar detfinns.

Även om mycket tid ägnades åt att kartlägga tänkbar hårdvara i form av olikamobila enheter och adaptrar för serieportsanslutningen visade sig den största delenav problemet ligga i att utveckla programkod till de mobila enheterna för att styraadaptrarna. Projektet handleddes hos uppdragsgivaren Sjöland & Thyselius av NilsHöglund som genom ett stort engagemang bidrog med värdefull kunskap inom detaktuella området.

1.2 Problemformulering

I föregående avsnitt beskrevs i stora drag att ICD-GPS-153 är ett protokoll för GPS-relaterad kommunikation genom seriell dataöverföring, vilket kan vara intressant attanvända på mobila enheter som ansluts till kompatibel GPS-utrustning. Med mobilenhet avses här en smarttelefon eller pekplatta. Detta projekt utgår från följandefrågeställningar:

• Vilka möjligheter finns det att kommunicera med ICD-GPS-153-kompatibelserieportsutrustad GPS-mottagare från en mobil enhet?

Vidare finns det en rad olika plattformar för mobila enheter, vilket ger upphov tillfrågan:

• Vilken lösning är lämpligast och mest praktiskt gångbar utifrån det tänktaanvändningsområdet?

Förutsättningarna ger att tillförlitlighet är av högsta prioritet. I det ingår attdataöverföringen bör ske med minimal risk för störningar. Dessutom bör säker-heten hos de mobila enheterna finnas i åtanke då de kan komma att hantera känsliginformation.

2

1.3. AVGRÄNSNINGAR

1.3 Avgränsningar

Jag gjorde vissa begränsningar i mitt urval av tänkbara lösningar, bland annat medhänsyn till de ovan givna förutsättningarna. Först och främst uteslöt jag trådlösagränssnitt för dataöverföringen mellan GPS-mottagaren och den mobila enheten,dels för att jag såg det som en naturlig avgränsning ur ett användningspraktisktperspektiv och dels för att minimera risken för störningar i en eventuell färdiglösning. Vidare betraktade jag marknadsläget för mobil- och pekplattor vid valet avvilka mobila enheter jag skulle begränsa mig till. De två överlägset största systemendå som också hade en positiv trend var Android och iOS [13, 24], vilket framgår avFigur 1.1.

100 %

90 %

80 %

70 %

60 %

50 %

40 %

30 %

20 %

10 %

0 %2009 2010 2011 2012

Övriga

Windows

BlackberryApple

Android

Figur 1.1. Marknadsandelar för mobilplattformar, från första kvartalet 2009 till andra kvartalet2012. Grafik: Gartner, IDC, Strategy Analytics, BI intelligence estimates, and company filings.

Resultatet av detta projekt är tänkt att på längre sikt kunna leda till en lösningsom ska användas i praktiken. Av det skälet behövde jag ta hänsyn till graden avtillgänglighet hos den hårdvara som jag lät ingå. Den skulle finnas tillgänglig attköpa i det skick som den sedan kom att användas i lösningen, vilket innebar att jaguteslöt all hårdvara som till exempel krävde lödning av komponenter. Det var inteaktuellt att modifiera medföljande operativsystem eller fast programvara, dels dådet riskerar att öppna säkerhetsluckor och dels för att lösningens framtidssäkerhetminskar och stödet från tillverkaren vanligtvis upphör.

3

Kapitel 2

Teoretisk referensram

Detta kapitel ger en kort, teoretisk bakgrund där nyckelkoncept i projektet presen-teras och tidigare, relaterat arbete diskuteras.

2.1 Seriell datakommunikation

Utmärkande för seriell datakommunikation, vilket den aktuella GPS-utrustningenanvänder, är att data överförs en bit i taget till skillnad från den parallella motsvarig-heten där flera bitar överförs åt gången. Det finns en rad olika standarder för sådanseriell datakommunikation, däribland RS-232 och USB, vilka båda har varit cen-trala i det här projektet. Här följer nu först en kort genomgång av RS-232 innan engrundläggande förklaring av USB ges.

2.1.1 RS-232

RS-232 används som samlingsnamn för en serie av standarder för seriella, binäradata- och kontrollsignaler där den senaste versionen heter TIA-232-F: Interfacebetween Data Terminal Equipment and Data Circuit-Terminating Equipment Em-ploying Serial Binary Data Interchange. I den definieras signalernas namn, funktionoch deras elektriska egenskaper samt mekaniska detaljer kring gränssnittet så somplacering av polerna för de olika kanalerna. [11]

Standarden beskriver 25 kanaler, men endast två av dem var av intresse för dethär projektet – TX- och RX-kanalerna (för Transmission respektive Reception) somtransporterar data åt var sitt håll. RS-232 tillåter således full duplex, men de anslut-na enheterna behöver förstås ändå vara överens om när var och en av dem ska skickadata. Det åstadkoms genom flödeskontroll som antingen kan skötas genom hårdvaramed hjälp av kontrollkanalerna i standarden eller i mjukvara genom fördefinieradekoder som exempelvis kan indikera att ena sidan är redo att ta emot ny data. Hurdata skickas i de olika kanalerna är fritt att specificeras för varje tillämpning – pro-tokollen som används inom ramen för RS-232 är alltså applikationsspecifika. Detfinns dock vissa protokoll som har blivit industristandard, exempelvis NMEA 0183

4

2.1. SERIELL DATAKOMMUNIKATION

som specificerar parametrarna för dataöverföringen och formatet på den data somöverförs. Parametrarna för överföring är här vanligtvis 4800 bps, 8-N-1, vilket angeratt ord om totalt 10 bitar ska skickas i en hastighet av 4800 bitar per sekund. Ettsådant 10-bitarsord består då av en – för RS-232 obligatorisk – startbit, följd av 8databitar och 1 stoppbit, utan någon paritetsbit (N). Konverteringen från parallelltformat till seriellt format för överföring av en bit i sänder hanteras i hårdvara aven UART1. Formatet för NMEA 0183-data är vanlig, ASCII-kodad text som utgörfördefinierade meningar.

2.1.2 USB

Medan RS-232 har funnits sedan 1962 då den ursprungliga standarden definierades[34] är USB ett modernare gränssnitt för vilket den första specifikationen, USB 1.0,släpptes år 1996 [10]. De existerande gränssnitten för kringutrustning – bland demRS-232 – hade då börjat bli begränsande faktorer i kommunikationen med nya,snabbare datorer och var dessutom svåra att utvidga. Det drev på utvecklingenav ett nytt gränssnitt för seriell datakommunikation, vilket kom att bli USB. Densenaste versionen, USB 3.0, tillåter överföringshastigheter upp till 5 Gbps jämförtmed 20 kbps för RS-232 och upp till 127 anslutna enheter per buss att ställa irelation till en ansluten enhet per serieport för RS-232.

Vid användning av USB ingår en värd (eng. host) och en eller flera enheter (eng.devices) samt de hubbar och det kablage som behövs för att ansluta enheterna tillvärden. Värden och enheterna kopplas samman i ett stjärnformat nätverk uppdelati olika nivåer där varje ansluten hubb bildar en ny nivå, vilket illustreras i Figur 2.1.På den lägsta nivån hos värden, i mitten av nätverket, finns en rothubb (eng. roothub) som tillsammans med tillhörande styrenhet upptäcker när enheter ansluts ellerkopplas från. Det är värdens ansvar att tilldela varje enhet en unik adress när denansluts och sedan hålla reda på den i en lista över tillgängliga enheter till dess attenheten kopplas från. Värden ansvarar också för att hantera dataflödet i nätverketgenom att fördela bandbredd till var och en av de anslutna enheterna. Överföringav data till värden sker på värdens begäran genom ett igenkänningstecken (eng.token) och enheter är i de flesta fall skyldiga att antingen svara med önskad dataeller meddela att det inte finns någon data tillgänglig. Åt andra hållet – när värdensänder data till en enhet måste enheten svara med antingen en positiv eller negativbekräftelse. [10]

USB-enheter har en eller flera slutpunkter (eng. endpoints) som används vid dataöver-föring. Dessa består av buffertar för mottagen data eller data som är redo att sändas.Varje slutpunkt har ett identifierande nummer och en bestämd riktning – in eller ut– sett från värdens synvinkel. En logisk anslutning kallad pipe upprättas till värdenför var och en av slutpunkterna på en enhet då den kopplas in. Förutom nummeroch riktning är varje slutpunkt även förknippad med en viss typ av överföring. Detfinns fyra olika typer, alla med sina egna egenskaper och syften:

1Universal Asynchronous Receiver/Transmitter

5

KAPITEL 2. TEORETISK REFERENSRAM

Figur 2.1. Exempel på USB-topologi. Här framgår det hur USB-värdens rot-hubb utgör den förstanivån i nätverket. Schemat indikerar också gränsen för antalet hubbar kopplade i serie. Enheter kanfinnas på vilken nivå som helst under rothubben, men kan inte ansluta till varandra. All datatrafikgår in till respektive ut från USB-värden.

Control Används i regel för identifiering och konfiguration av enheter. Alla USB-enheter har en speciell slutpunkt, Endpoint 0, för Control-överföringar somförst och främst används vid den inledande konfigurationen.

Bulk Är avsedd för större mängder data som inte är brådskande. Värden prioriterarde andra typerna av överföringar först, men om bussen hos värden i övrigt ärledig är Bulk-överföringar de snabbaste.

Interrupt Är till för periodiska överföringar, eller överföringar som behöver garanti-er för hur stora de maximala fördröjningarna får vara. Tangentbord och mössanvänder Interrupt-överföringar för att indikera tangenttryckningar och mus-rörelser.

Isochronous Kan utlova en specifik hastighet, men är också den enda överförings-typen som saknar felkorrigering. Isochronous-överföringar passar därför braför exempelvis strömning av bild och ljud där hastigheten är kritisk och en-staka fel godtagbara.

6

2.2. ANDROID

Så här långt har jag beskrivit att kringutrustning med USB-gränssnitt endast kanagera enheter, men genom ett tillägg till USB 2.0-standarden kallat On-The-Go(OTG) är det möjligt att bygga kringutrustning som kan alternera mellan att ageravärd och enhet. OTG-utrustning som agerar värd skiljer sig något från en konven-tionell värd i några avseenden – en OTG-värd

• behöver endast ha stöd för den mellersta av tre hastigheter (full speed)

• behöver inte stödja externa hubbar

• behöver bara leverera 8 mA till anslutna enheter jämfört med 500 mA (eller100 mA vid batteridrift av värden).

Däremot måste OTG-utrustning kunna fungera som enhet och dessutom ha stödför två protokoll som tillåter den att förhandla om värdrollen och strömtillförseln– Host Negotiation Protocol respektive Session Request Protocol. Tillverkare avOTG-utrustning är dessutom tvungna att tillhandahålla en lista över vilken kring-utrustning (eng. Targeted Peripheral List) tillverkaren framgångsrikt har testat sinprodukt ihop med. [10]

2.2 Android

Android är en mjukvarustack för mobila enheter och består av ett operativsystem,mellanprogram (eng. middleware), användargränssnitt och applikationer. Bakomprojektet står Open Handset Alliance med Google Inc., T-Mobile, HTC, Qual-comm och Motorola i spetsen. [2] Den processorarkitektur som Android huvud-sakligen utvecklas för är ARM [12], men det pågår även arbete med att porteraAndroid till x86 [35], vilket exempelvis utnyttjas i [14] för att köra virtuella Android-smarttelefoner på en x86-baserad server som sedan styrs från fysiska smarttelefoneröver IP.

Applikationerna i Android programmeras i första hand med Java med hjälp av An-droid SDK2 – en samling utvecklingsverktyg där det ingår avlusare, programvaru-bibliotek, emulatorer och dokumentation. Sedan juni 2009 finns numera även offi-ciellt stöd för att kompilera program skrivna i C och C++ till maskinkod för ARM-och x86-processorer genom Android NDK3 [27]. Flera undersökningar [12, 27, 29]har påvisat prestandavinster för applikationer som använder maskinkod jämförtmed motsvarande implementation i Java. Men trots att Android bygger på envariant av Linux-kärnan finns det betydande skillnader mot konventionella Linux-distributioner, vilket kan innebära svårigheter vid framförallt portering av exi-sterande C/C++-kod till Android [23].

I ett tidigare projekt [37] som delade några av ambitionerna med det här projektet –att ansluta Android-enheter till omvärlden – användes IOIO, vilket är ett kretskort

2Software Development Kit3Native Development Kit

7


som ansluts via USB och erbjuder en rad gränssnitt mot extern hårdvara, däri-bland ett seriellt sådant via en UART. Författarna menade att de då existerandelösningarna för att ansluta Android-enheter till omvärlden var dyra, komplicerade,fysiskt stora, gav låg bandbredd eller krävde att operativsystemet byttes ut, vilketde ansåg inte gälla IOIO. UART-hårdvaran styrs liksom allt annat på kretskortetfrån Android-enheten genom ett programmeringsgränssnitt för applikationer i Javaoch är abstraherad till in- och utströmmar i form av klasserna InputStream respek-tive OutputStream. Kretskortet behöver dock extern strömförsörjning genom 5-15 Vlikström och saknar färdiginkopplade kontaktdon för exempelvis RS-232.

I implementationen av ett litet, portabelt mätsystem för luftföroreningar beståendeav smarttelefon och serieportsutrustad föroreningssensor presenteras ett liknandeangreppssätt [21]. Figur 2.2 visar hur smarttelefonen ansluts till sensorn via en typav serieportsadapter och programvarubiblioteket android-serial-api används för attkommunicera på serieporten genom in- och utströmmar i Java. Skillnaden mot pro-jektet ovan ligger huvudsakligen i att här byts operativsystemet ut för att aktiveraUSB-värdläge istället för att ansluta extra hårdvara som agerar USB-värd. I bå-da projekten används trådbundna gränssnitt och i [21] påstås strömförbrukningendärmed vara halverad i jämförelse med trådlösa gränssnitt.

Figur 2.2. En smarttelefon med Android ansluten till en föroreningssensor via en serieportsadaptermen extern strömförsörjning via ett batteripaket. Bilden är hämtad direkt från [21].

Det finns också projekt som använder trådlös kommunikation så som Bluetooth,till exempel [9] där en lösning föreslås som tillåter standardiserad kommunikationmellan medicinska apparater genom en billig plattform baserad på öppen källkod

8

2.3. IOS

kallad Medical Device Dongle (MDD). I Figur 2.3 framgår hur en mobil enhet medAndroid ansluts trådlöst till en serieportsutrustad apparat via MDD-plattformen.Den enda principiella skillnaden mot IOIO-projektet [37] är den trådlösa kommu-nikationen.

Figur 2.3. En medicinsk apparat (Nellcor Pulse Oximeter) ansluten via dess serieportsgränssnitttill MDD-kretskortet som kommunicerar trådlöst med Android-telefonen genom Bluetooth. Bildenär hämtad direkt från [9].

Generellt för liknande projekt som utförts tidigare gäller att de av en eller fleraanledningar ligger utanför de ramar som begränsar lösningsmängden för det härprojektet. I de projekten [9, 21, 37] som beskrivs ovan används till exempel externutrustning som kräver modifikation av hårdvaran, ett operativsystem som ersätterdet ursprungliga respektive trådlös kommunikation.

2.3 iOS

iOS är ett operativsystem som körs på iPhone, iPod touch och iPad [8]. Det släpptesav Apple i en första version tillsammans med introduktionen av iPhone år 2007 [7].iOS är en optimerad, men fullständig version av Apple:s operativsystem OS Xför deras Macintosh-datorer [22] och är således baserad på det POSIX-kompatiblaoperativsystemet Darwin, vilket gör iOS till en del av Unix-familjen [33]. Vid köpav en iOS-produkt som enkelanvändare följer operativsystemet med, men enbart föranvändning – köparen äger således inte sin kopia av operativsystemet [5]. Vidarefår den medföljande iOS-mjukvaran ej kopieras eller dekompileras och är bundentill användning på den införskaffade produkten från Apple.

För att skapa applikationer till iOS är tredjepartsutvecklare hänvisade till den in-

9


tegrerade utvecklingsmiljön Xcode som rymmer de nödvändiga verktygen för attskriva och kompilera program samt köra dem i en simulator med mera [8]. App-likationerna skrivs i språket Objective-C, vilket är en utökning av ANSI C där nysyntax har introducerats för att tillåta objektorienterade konstruktioner. I Xcodefinns även stöd för språket Objective-C++ genom kompilatorprojekten GCC ochLLVM med Clang. Det är en variant av Objective-C som bygger på C++ iställetför C [32], men det finns ingen officiellt dokumenterad standard för språket [18].Vissa kompatibilitetsproblem med C++ kan uppstå i C och även Objective-C, tillexempel är class ett reserverat nyckelord i C++ medan det är en giltig identifierarei C och Objective-C.

I iOS 3 introducerades External Accessory framework, vilket låter tredjepartsutveck-lare ta fram egna tillbehör till Apple-produkter. Det krävs dock en speciell licensför ändamålet som ger tillgång till teknisk dokumentation och support. Därutövermåste en eventuellt framtagen produkt godkännas av Apple innan den kan börjasäljas. [1] Ett företag som har genomgått den processen är Redpark som nu säljer sinkabel RS-232 Serial Cable (härefter kallad seriekabeln), vilken var det första – ochenligt återförsäljaren fortfarande är det enda – Apple-godkända iOS-tillbehöret förRS-232 [31]. Tillbehöret levereras med ett färdigkompilerat bibliotek och tillhörandehuvudfil, vilken deklarerar det protokoll i Objective-C som biblioteket implementer-ar [1]. För mer detaljer kring hur seriekabeln kan användas för att ansluta iPhoneoch iPad till ett externt kretskort likt IOIO hänvisas den intresserade till [1].

10

Kapitel 3

Metod

Det finns flera sätt att utreda problemet, det vill säga att undersöka vilka möj-ligheter det finns att kommunicera med GPS-utrustningen från mobila enheter. Ettsätt är att genom enbart textstudier ta reda på exakt vilken hårdvara som har stödför vilka gränssnitt och utifrån det resonera sig fram till vilka möjligheter det finns.Det tillvägagångssättet kan tyckas vara attraherande då det borde resultera i enheltäckande, detaljerad lista över mobila enheter och deras respektive tillräckligheti fråga om att kommunicera med serieportsutrustning och speciellt ICD-GPS-153-kompatibel sådan. En uppenbar brist är dock att instuderingsmaterialet blir heltavgörande för resultatets bärighet; om exempelvis några specifikationer för en hård-varukomponent är felaktigt angivna faller potentiellt samtliga resultat där kompo-nenten ingår. Då tycks det mer pålitligt att låta inläsning ge en god uppfattningom möjliga lösningar och därefter försöka implementera ett fåtal av dem för attverifiera deras giltighet.

Problemet med att kommunicera med GPS-utrustningen består av två delar: enhårdvaru- och en mjukvarudel. Först handlar det om att hitta ett sätt på vilket enmobil enhet kan utföra godtycklig kommunikation över RS-232 och därefter åter-står problemet att implementera stöd för ICD-GPS-153-protokollet på enheten. Denförsta delen löstes inledningsvis genom att utifrån förutsättningarna och de däravmedförda begränsningarna välja plattformar att undersöka. Här låg en inläsningtill grund för urvalet som baserades i stor grad på marknadsläget för var och enav de olika plattformarna för mobila enheter. Motiveringen till det är att en störremarknadsandel rimligen medför fler användare och därmed större intresse för plat-tformen. Dessutom är det mer troligt att vem som än är intresserad av en lösningredan äger den mobila enheten och således endast behöver komplettera med utrust-ning för att ansluta den till sin externa hårdvara via RS-232.

Jag fann att Android och iOS var de två största plattformarna på marknaden vilketgjorde att jag beslutade att gå vidare med just dem. Jag behövde då utreda ex-akt vilken enhet som undersökningen skulle grundas på för var och en av de tvåplattformarna. I fallet med iOS fanns det redan en iPad 1 tillgänglig på företaget,

11

KAPITEL 3. METOD

vilken syntes vara fullt tillräcklig för undersökningen. Att det inte var den senastemodellen var inget bekymmer då den fortfarande körde en relativt ny version aviOS som erbjuder abstraktion av den underliggande hårdvaran så att en modernaresådan ej borde vara något problem. Dessutom är rimligt att tro att nya versionerav iPad är bakåtkompatibla med gamla applikationer.

På Android-sidan krävdes desto mer övervägande då variationen av hårdvara ochtillgängliga utgångar är större än i fallet med iOS-enheter. Det fanns heller ingenredan tillgänglig enhet hos företaget, varför jag kunde välja fritt bland de mobilaAndroid-enheterna på marknaden. Här valde jag att införskaffa pekplattan AcerIconia Tab A200 då den är utrustad med både en micro-USB-port och en full-stor USB-port, vilket tillåter den att fungera både som USB-enhet och USB-värd,vilket maximerade möjligheten att undersöka olika typer av lösningar för Android-enheter. Baserat på projektets avgränsningar valde jag att undersöka lösningen meden serieportsadapter som ansluts till den fullstora USB-porten. Det begränsar dockinte omfattningen av resultaten i detta projekt då mobila enheter som saknar full-stor USB-port med USB-värdstöd ofta har stöd för USB On-The-Go (OTG) istället.Med hjälp av en adapter kan deras micro-USB-port då konverteras till en fullstorUSB-port och OTG-protokollet tillåter sådana enheter att agera USB-värd.

Den andra delen av problemet bestod alltså i att ta fram mjukvara som kunde utnyt-tja gränssnitten för RS-232 på de utvalda plattformarna. Problemet kan ses som isin tur uppdelat i ytterligare två delproblem: RS-232-kommunikation och ICD-GPS-153-implementation. I iOS var det första problemets lösning ganska given i och medatt Redpark tillhandahöll implementationen av läsning och skrivning på serieportenhos Serial Cable genom det SDK som följde med, men den behövde ändå bekräftas.För Android var det inte lika självklart, men den huvudsakliga idén var att utveck-la en drivrutin i användarland (eng. user space) med hjälp av USB Host API1. Pådet andra delproblemet fanns ett par olika lösningar på de båda plattformarna ioch med det redan existerande programvarubiblioteket, ICDlib, för ICD-GPS-153-kommunikation. Den första tanken var att portera biblioteket till Objective-C ochJava för iOS respektive Android, men det skulle antagligen ta lång tid på grund avICD-GPS-153-protokollets omfattning, vare sig ICDlib användes som mall eller tvånya bibliotek designades från grunden. Därför började jag undersöka hur den redanexisterande programkoden bättre kunde utnyttjas, vilket resulterade i att jag fannsätt att bygga koden för båda plattformarna.

1Android USB Host API tillhandahåller Java-metoder för att utföra uppgifter som USB-värdarförväntas kunna göra, till exempel kan data överföras via metoden bulkTransfer().

12

Kapitel 4

iOS-enhet med Apple-godkänt

serieportstillbehör

Först ut att undersökas av de två valda lösningarna var den som baserades påen iOS-enhet och tillbehöret Redpark Serial Cable. Det här kapitlet redogör förundersökningen och de resultat som den ledde till. En detaljerad specifikation avkomponenterna ges i Tabell 4.1 och Tabell 4.2.

Apple iPad Wi-Fi

Allmänt Utgivningsdatum Mars, 2010.

Operativsystem iOS 4 (ursprungligt)

iOS 5.0.1 (använt i undersökningen)

iOS 5.1 (tillgänglig uppgradering)

Dimensioner Mått (B × H × D) 242,8 × 189,7 × 13,4 mm

Vikt 680 g

Lagring Arbetsminne 256 MB DDR RAM

Internt lagringsutrymme 16 GB

Minneskortplats Ingen

Hårdvara Kretsuppsättning Apple A4

CPU 1 GHz Cortex-A8

GPU PowerVR SGX535

Battery Li-Po

Anslutningar WLAN Wi-Fi 802.11 a/b/g/n

USB USB (v2.0) via iPad CCK-adapter

Tabell 4.1. Egenskaper för Apple iPad Wi-Fi [20].

13

KAPITEL 4. IOS-ENHET MED APPLE-GODKÄNT SERIEPORTSTILLBEHÖR

Redpark Serial Cable (C2-DB9)

Kompatibilitet iPhone (4S, 4, 3GS), iPod Touch (4G), iPad (alla modeller).

Operativsystemkrav iOS 4.3.x eller senare.

Kontaktdon Apple 30-polig (A), DB-9 (B)

Kabellängd 1 m

Hastighet Upp till 57,6 kbps.

Tabell 4.2. Egenskaper för Redpark Serial Cable (C2-DB9)

4.1 Grundläggande hårdvarutest

Det allra första som gjordes i undersökningen var att kontrollera att seriekabeln frånRedpark verkligen fungerade som avsett, det vill säga att iOS-applikationer på blandannat iPad kunde skicka och ta emot data via RS-232-gränssnittet. Testet utfördesgenom att utnyttja en medföljande loopback-adapter och källkod för tillhörandetestapplikation. Applikationen använde det medföljande SDK:t för att skriva enfördefinierad sekvens av tecken på serieporten och samtidigt läsa lika många teckenoch kontrollera att det var samma data som hade skickats.

Testet slutfördes framgångsrikt med seriekabeln ansluten till iPad:en vid upprepadetillfällen. En så kallad break-out-box användes dessutom för att kontrollera att dataverkligen gick ut på serieporten via TX-kanalen för att sedan återvända i RX-kanalen, vilket det gjorde baserat på avläsning av indikeringslampor.

4.2 Mottagande av data från GPS-mottagaren viaRS-232

Nästa steg var att ersätta loopback-adaptern med GPS-mottagaren och skriva en nyapplikation, liknande testapplikationen, men som endast registrerade inkommandedata, det vill säga läste från serieportens RX-kanal. Applikationen kom att beståav en textvy som uppdaterades med ny data allt eftersom den lästs in från se-rieporten. Den utgjordes i det skedet huvudsakligen av delegaten ICDAppDelegate,vyhanteraren ICDViewController och Redparks SDK, enligt Figur 4.1. Koden somhanterade att läsa data och uppdatera textvyn visas i sin helhet i Programkod 4.1(med de ICD-GPS-153-specifika delarna utbytta mot påhittade värden). Funk-tionen utgör ICDViewController:s implementation av readBytesAvailable: urRscMgrDelegate-protokollet i Redpark SDK. Den körs då seriekabeln har registr-erat inkommande data som är tillgänglig att läsas genom funktionen read:Length.I programkoden framgår hur det angivna antalet inkomna bytes, length, placeras ibufferten availableBytes. Varje byte i bufferten kontrolleras sedan om den inled-er ett nytt meddelande. I så fall infogas en radbrytning på lämplig position i den

14

4.2. MOTTAGANDE AV DATA FRÅN GPS-MOTTAGAREN VIA RS-232

textsträng som innehåller samtlig inkommen data. Det är sedan den strängen somvisas upp i applikationens textvy.

Programkod 4.1. Utdrag ur applikationen som visade inkommen serieportsdata.

− (void ) readBytesAva i lab le : ( UInt32 ) l ength {stat ic int s t a t e = 0 ;UInt8 ava i l ab l eByt e s [ l ength ] ;[ rscMgr read : ava i l ab l eByt e s Length : l ength ] ;

NSMutableString ∗ byte sS t r ing = [ [ NSMutableString a l l o c ]i n i tWithSt r ing : packetTextView . t ext ] ;

for ( int i = 0 ; i < length ; ++i ) {i f ( s t a t e == 0) {

s t a t e = ava i l ab l eByt e s [ i ] == 0xAA ? 1 : 0 ;} else i f ( s t a t e == 1) {

i f ( ava i l ab l eByt e s [ i ] == 0xBB {s t a t e = 2 ;

} else i f ( ava i l ab l eByt e s [ i ] == 0xAA {s t a t e = 1 ;

} else {s t a t e = 0 ;

}}

[ by t e sS t r ing appendFormat :@"%02X␣ " , ava i l ab l eByt e s [ i ] ] ;

i f ( s t a t e == 2) {[ by t e sS t r ing i n s e r t S t r i n g :@" \n " atIndex : by t e sS t r ing .

l ength − 6 ] ;s t a t e = 0 ;

}}

[ packetTextView setText : by t e sS t r ing ] ;}

Utifrån den data som visades upp i applikationen gick det att med hjälp av speci-fikationen för ICD-GPS-153-protokollet manuellt verifiera de enskilda meddelande-na. De var alla av samma typ, skickades ut med jämna mellanrum och samtligainnehöll korrekta kontrollsummor. I och med den här verifieringen av mottagnameddelanden var halva delproblemet att kommunicera med extern hårdvara viaRS-232 var löst – det återstod dock att undersöka möjligheten att skicka data tillGPS-mottagaren.

Om det var rättframt att bekräfta läsningsdelen var det svårare att kontrollera huru-vida sändning till GPS-mottagaren hade lyckats. Där fanns inte samma möjlighetstudera inkommande data i en konsoll. Istället behövdes till exempel ett medde-

15


lande konstrueras och överföras sådant att det skulle ge en synbar reaktion hosGPS-mottagaren. Tanken var att sätta samman ett meddelande som skulle upp-mana GPS-mottagaren att skicka en ny typ av meddelande i retur, vilket skulleupptäckas i textvyn i form av annorlunda mottagen data. Beslutet blev dock attvänta med att kontrollera att data överfördes korrekt till GPS-mottagaren, efter attbreak-out-boxen bekräftat aktivitet på TX-kanalen, till förmån för implementationav ICD-GPS-153-protokollet. Med en sådan på plats skulle uppgiften att konstrueraönskat meddelande för sändning vara enklare än utan.

Figur 4.1. Klassdiagram över iOS-applikationen som utvecklades för att läsa data från serieportensRX-kanal och visa den i en textvy.

16

4.3. INTEGRERING AV EXISTERANDE PROGRAMVARUBIBLIOTEK

4.3 Integrering av existerande programvarubibliotek

Som tidigare nämnts fanns det redan ett programvarubibliotek, ICDlib, tillgäng-ligt för ICD-GPS-153 skrivet i C++ avsett för Microsoft Windows och POSIX-kompatibla operativsystem. Ett applikationsprogram interagerar med ICDlib genomklassen ICDClient och erhåller resultat i form av ClientLibMessage-objekt. Föru-tom en samling statiska nyttofunktioner för avkodning av data i ClientLibMessage-objekten är de två klasserna de enda in- och utgångspunkterna till och från bib-lioteket. Det visade sig vara praktiskt eftersom det tillät ett lager mellan RedparkSerial och ICDlib att relativt enkelt skjutas in, dels för att ge ICDlib tillgång tillseriekabeln och dels för att skapa ett gränssnitt mellan ICDlib (C++) och RedparkSerial (Objective-C).

I Figur 4.2 presenteras några av de centrala komponenterna i den slutliga lösning-en och deras kopplingar till varandra. Det som har skett sedan den första, ovanbeskrivna testapplikationen är till att börja med att koden för ICDlib har inklud-erats där ICDClient och IOCoordinator är de två intressantaste klasserna för dethär projektet. ICDClient låter applikationsprogrammet bland annat begära ön-skade meddelanden från GPS-mottagaren medan IOCoordinator, precis som nam-net antyder, koordinerar kommunikationen mellan biblioteket och GPS-mottagaren.ICDlib justerades på vissa punkter så att IOCoordinator skulle få tillgång till se-rieporten via Serial Cable; bland annat öppnades en väg från ICDClientWrapper intill funktionen newData() i gränssnittet SerialPortUser, vilket implementeras avFrameHandler, genom ICDClient::newSerialPortData(). Dessutom lades med-lemsvariabeln serialPort till i IOCoordinator som pekar på ett RscMgrAdapter-objekt, vilket ger IOCoordinator tillgång till funktionerna i RscMgr genom ettC++-gränssnitt. Vidare har den ensamma vyhanteraren bytts ut mot två nya var-av endast den initiala, ICDMessageLogViewController, visas då det är den somstår för att periodvis fråga biblioteket efter nyinkomna meddelanden och lista demmedan den andra, ICDMessageViewController, endast har ansvar för att ge endetaljerad vy för ett enskilt meddelande.

4.3.1 Separerad interaktion mellan Objective-C och C++

Låt oss nu för en stund återgå till lagret mellan ICDlib och Redpark Serial. Förde-len med ett sådant lager jämfört med att blanda Objective-C med C++ i form avObjective-C++ är bland annat att biblioteket – ICDlib i det här fallet – kan återan-vändas i andra Objective-C-projekt utan att de behöver konverteras till Objective-C++. Dessutom minimeras risken för att problem uppstår med inkompatibilitetmellan Objective-C och C++ [38]. Vidare är det rimligt att hålla användandet avObjective-C++ till ett minimum med anledning av att det som tidigare påpekatsinte finns någon officiellt dokumenterad standard för språket.

Det huvudsakliga problemet i att skapa ett lager enligt ovan är att hålla huvudfiler-na rena från C++ i det fall då en Objective-C-klass behöver inkludera en C++-klass

17


Figur 4.2. Klassdiagram över delar av det slutliga resultatet. Klasser med skuggad bakgrund haren tillhörande huvudfil i ren C++.

18


(eller vice versa). Om så inte sker måste den inkluderande klassen konverteras tillObjective-C++, vilket i Xcode sker genom att byta filändelse till .mm. Då körs kom-pilatorn i ett läge där den är beredd på språkkonstruktioner från både Objective-Coch C++ så att den kan tolka det inkluderade innehållet; en Objective-C-kompilatorsom stöter på en inkluderad C++-klass kommer annars att reagera på syntaxen ochtroligen avsluta med ett felmeddelande i likhet med: “Unknown type name ’class’;did you mean ’Class’?” [26]

Det finns en rad olika tillvägagångssätt för att komma runt problemet ovan, alltifrånatt bygga ett rent C-gränssnitt till att använda (void*)-pekare och preprocess-makron [25]. I och med Apple:s användning av den LLVM-baserade kompilatornClang för iOS-utveckling finns ytterligare ett alternativ – instansvariabler i klas-sutökningar (eng. class extensions). En Objective-C-klass kan därigenom innehållainstansvariabler av typer definierade som C++-klasser utan att de klassernas dekla-rationer behöver inkluderas i huvudfilen för Objective C-klassen. På så sätt förblirhuvudfilen ren från C++ samtidigt som klassen kan hålla C++-referenser. Genomdetta tillvägagångssätt undviks de bekymmer som övriga lösningar medför så somatt typsäkerheten går förlorad vid användandet av (void*)-pekare.

Låt oss studera ICDClientWrapper i Figur 4.2 som exempel på en Objective-C-klass med behov att inkludera en C++-klass, ICDClient. Kom ihåg att målet äratt hålla huvudfilen ICDClientWrapper.h (Programkod 4.2) ren från C++ och alltsåendast innehålla Objective-C. Lösningen innebär att i huvudfilens @interface-delenbart deklarera funktioner motsvarande dem i ICDClient som önskas lindas in iObjective-C. De C++-specifika delarna, till exempel ICDClient-pekaren, deklarerassedan i en klassutökning i implementationsfilen ICDClientWrapper.mm Program-kod 4.3. När sedan exempelvis requestMessage: sänds till ICDClientWrapper an-vänder den sin instans av ICDClient för att utföra requestMessage(). EftersomICDClientWrapper inte får innehålla C++ kan dock viss konvertering krävas avargumenten till requestMessage: innan requestMessage() anropas.

Programkod 4.2. Huvudfilen ICDClientWrapper.h i förkortad version med förklarande kom-mentarer.

/∗ Al la importerade h u v u d f i l e r nedan är f r i a f r ån C++. ∗/#import <Foundation/Foundation . h>#import " ClientLibMessageWrapper . h "#import "RscMgr . h "

@interface ICDClientWrapper : NSObject <RscMgrDelegate>

/∗ Inga i n s t a n s v a r i a b l e r av typer som implementerats i C++ kand e k l a r e r a s här . ∗/

+ ( ICDClientWrapper ∗) sharedICDClientWrapper ;

/∗ . . . ∗/

19


/∗ Implementationen av den här funk t ionen kr ä ver å tkomst t i l l enin s t an s av C++−k l a s s e n ICDClient . ∗/

− ( int ) requestMessage : ( int )messagenumber ;

/∗ . . . ∗/

@end

Programkod 4.3. Implementationsfilen ICDClientWrapper.mm i förkortad version med förk-larande kommentarer.

/∗ Importerar h u v u d f i l e r f ö r Ob jec t i ve −C . . . ∗/#import " ICDClientWrapper . h "/∗ . . . och i n k l u d e r a r h u v u d f i l e r f ö r C++. ∗/#include " ICDClient . h "#include " RscMgrAdapter . hh "

/∗ ICDClientWrapper ut ö kas med pekare t i l l k l a s s e r som ärimplementerade i C++. ∗/

@interface ICDClientWrapper ( ) {@private

ICDClient∗ i c dC l i e n t ;RscMgrAdapter∗ rscMgrAdapter ;

}@end

@implementation ICDClientWrapper

/∗ S ing l e t on − re turnerar in s t an s av ICDClientWrapper . ∗/+ ( ICDClientWrapper ∗) sharedICDClientWrapper {

stat ic ICDClientWrapper∗ icdClientWrapper = n i l ;

stat ic dispatch_once_t onceToken ;dispatch_once(&onceToken , ^{

icdClientWrapper = [ [ s e l f a l l o c ] i n i t ] ;}) ;

return icdClientWrapper ;}

/∗ Skapar i n s t a n s e r av i n l i n d a d e C++−k l a s s e r . ∗/− ( id ) i n i t {

s e l f = [ super i n i t ] ;i f ( s e l f ) {

rscMgrAdapter = new RscMgrAdapter ;i c dC l i e n t = new ICDClient ;

rscMgrAdapter−>setDe l ega t e ( ( __bridge void ∗) s e l f ) ;i cdC l i en t−>s e t S e r i a lP o r t ( rscMgrAdapter ) ;

}

20


return s e l f ;}

/∗ Frig ör minnet som a l l o k e r a d e s i i n i t i a l i s e r i n g e n ovan . ∗/− (void ) d e a l l o c {

[ s e l f stop ] ;d e l e t e i c dC l i e n t ;d e l e t e rscMgrAdapter ;

}

/∗ Vidarebe fordra f ö r f r ågan t i l l den i n l i n d a d e ins tansen avICDClient . ∗/

− ( int ) requestMessage : ( int )messagenumber {return i cdC l i en t−>requestMessage (messagenumber ) ;

}

/∗ ICDClientWrapper är d e l e g a t å t RscMgr så denna funk t i onanropas då ny s e r i e p o r t s d a t a mo t t a g i t s . Den s k i c k a s in iICDlib f ö r behand l ing . ∗/

− (void ) readBytesAva i lab le : ( UInt32 ) l ength {uint8_t ∗ bu f f e r = new uint8_t [ l ength ] ;rscMgrAdapter−>read ( bu f f e r , l ength ) ;i cdC l i en t−>newSerialPortData ( bu f f e r , l ength ) ;d e l e t e [ ] b u f f e r ;

}

@end

För det omvända problemet med en C++-klass som behöver åtkomst till Objective-C-klasser finns dessvärre ingen språkkonstruktion motsvarande klassutökningar atttillgå [26]. Men istället kan idiomet PImpl (Pointer to Implementation) – även kallathandle classes [16] – utnyttjas för att linda in Objective-C-koden. Applicerat pådet studerade problemet innebär det att en ofullständig typ, RscMgrAdapterImpl,deklareras genom att infoga struct RscMgrAdapterImpl; i huvudfilen (Programkod 4.4).I RscMgrAdapter.hh deklareras sedan en pekare till den ofullständiga typen vars im-plementation håller i ett RscMgr-objekt. Huvudfilen RscMgrAdapter.hh är såledesren från Objective-C samtidigt som implementationsfilen RscMgrAdapter.mm (Program-kod 4.5) kan skrivas i Objective-C++ och därmed via RscMgrAdapterImpl-pekarenfå tillgång till RscMgr.

Programkod 4.4. Huvudfilen RscMgrAdapter.hh i en förkortad version med förklarande kom-mentarer.

#include " S e r i a lPo r t . hh "#include " r edpa rkSe r i a l . h "

/∗ Framå t d e k l a r a t i o n av typen RscMgrAdapterImpl ( här en o f u l l s t ändig C−s t r u c t ) . ∗/

struct RscMgrAdapterImpl ;

21


c l a s s RscMgrAdapter : pub l i c S e r i a lPo r t {/∗ Pekare t i l l den ovan framå t d e k l a r e r a d e typen . ∗/RscMgrAdapterImpl∗ impl ;

pub l i c :

/∗ . . . ∗/

void s e tDe l ega t e (void∗ de l e ga t e ) ;

/∗ Del av de t gr ä n s s n i t t som är t i l l g ä n g l i g t f ö r RscMgr . ∗/v i r t u a l int wr i t e ( uint8_t ∗ data , uint32_t length ) ;

} ;

Programkod 4.5. Implementationsfilen RscMgrAdapter.mm i en förkortad version med förk-larande kommentarer.

#include " RscMgrAdapter . hh "#import "RscMgr . h "

/∗ De f in i e ra den fram t i l l s nu o f u l l s t ä ndiga typenRscMgrAdapterImpl . ∗/

struct RscMgrAdapterImpl {RscMgr∗ rscMgr ;

} ;

/∗ Lå t impl peka på en ny in s t an s av RscMgrAdapterImpl samt skapaObjec t i ve −C−o b j e k t e t som l i n d a s in . ∗/

RscMgrAdapter : : RscMgrAdapter ( ) : impl (new RscMgrAdapterImpl ) {impl−>rscMgr = [ [ RscMgr a l l o c ] i n i t ] ;

}

/∗ Frig ör minnet som a l l o k e r a d e s ovan då i n s t a n s e r av den härk l a s s e n de s t rue ra s . ∗/

RscMgrAdapter : : ~ RscMgrAdapter ( ) {d e l e t e impl ;

}

void RscMgrAdapter : : s e tDe l ega t e (void ∗ de l e ga t e ) {[ impl−>rscMgr s e tDe l ega t e : ( __bridge id ) d e l e ga t e ] ;

}

/∗ Vidarebe fordra f ö r f r ågan om a t t s k r i v a data på s e r i e p o r t e nt i l l de t i n l i n d a d e Objec t i ve −C−o b j e k t e t . ∗/

int RscMgrAdapter : : wr i t e ( uint8_t ∗ data , uint32_t length ) {return [ impl−>rscMgr wr i t e : data Length : l ength ] ;

}

22

4.4. VERIFIERING AV SÄNDNING OCH MOTTAGANDE AV DATA FRÅNGPS-MOTTAGAREN

4.4 Verifiering av sändning och mottagande av data frånGPS-mottagaren

Med ICDlib på plats i applikationen var det möjligt att utvärdera om sändningoch mottagning av data till GPS-mottagaren fungerade genom att skicka och taemot meddelanden enligt ICD-GPS-153-protokollet. Då Serial Cable kopplades inbeställdes i funktionen cableConnected: prenumeration på ett särskilt meddelandemed positionsdata. Med jämna mellanrum började därefter det efterfrågade medde-landet visas i applikationens lista över mottagna meddelanden (se Figur 4.3), vilkettroliggjorde att GPS-mottagaren korrekt hade tagit emot, förstått och bifallit för-frågan. I syfte att kontrollera giltigheten hos datan i det mottagna meddelandetutlästes GPS-koordinaterna i applikationen och visades i en vy med detaljer kringenskilda meddelanden (se Figur 4.4). I det efterfrågade meddelandet fanns föru-tom positionen angiven även en flagga som indikerade huruvida koordinaterna vargiltiga eller ej, det vill säga om GPS-mottagaren hade fixerat tillräckligt mångasatelliter eller ej, vilket indikerades med grön respektive röd bakgrundsfärg i vyn.Då ett meddelande med påstått giltig position tagits emot jämfördes de koordina-terna med dem som visades på GPS-mottagarens skärm. De stämde överens medvarandra och pekade dessutom ut korrekt position vid kontroll mot en karta.

23


Figur 4.3. Lista över mottagna meddelanden. Meddelandenas verkliga id-nummer har ersatts medsymbolerna A och B.

24

4.4. VERIFIERING AV SÄNDNING OCH MOTTAGANDE AV DATA FRÅNGPS-MOTTAGAREN

Figur 4.4. Detaljerad vy för enskilt mottaget meddelande. ICD-GPS-153-specifika detaljer hardolts. Värdena för latitud (1,035795) och longitud (0.314880) är angivna i radianer.

25

Kapitel 5

Android-enhet med serieportsadapter

Efter att lösningsmetoden med en iOS-enhet och seriekabeln från föregående kapi-tel visat sig framgångsrik var det dags att undersöka möjligheten att använda enAndroid-enhet tillsammans med en serieportsadapter för att kommunicera medGPS-mottagaren. Jämfört med lösningen för iOS där serieportskommunikationenvar väl förberedd för den mobila enheten av seriekabelns tillverkare, krävdes enstörre insats på Android-sidan för att reda ut den delen av problemet. I det härkapitlet redogör jag för undersökningen och de resultat som den ledde till. Denhårdvara som användes presenteras i Tabell 5.1 och Tabell 5.2.

Acer Iconia Tab A200

Allmänt Utgivningsdatum Januari, 2012.

Operativsystem Android 4.0 (Ice Cream Sandwich)

Dimensioner Mått (B × H × D) 260 × 175 × 12,4 mm

Vikt 700 g

Lagring Arbetsminne 1 GB DDR2 RAM

Internt lagringsutrymme 16 GB

Minneskortplats microSD, upp till 32 GB

Hårdvara Kretsuppsättning Nvidia Tegra 2 T20

CPU Dual-core 1 GHz Cortex-A9

GPU ULP GeForce

Battery Li-Po 3260 mAh

Anslutningar WLAN Wi-Fi 802.11 b/g/n, Wi-Fi hotspot

USB microUSB (v2.0), USB (v2.0), USB OTG-stöd

Tabell 5.1. Egenskaper för Acer Iconia Tab A200 [19].

26

5.1. UTFORSKNING AV USB HOST API OCH SERIEPORTSADAPTERN

Seriell adapter RS-232 DB9ha till USB 2.0

Extern anslutning RS-232

Kontaktdon USB A (A), DB-9 (B)

Kabellängd 0,7 m

Operativsystemstöd Windows XP, Vista, 7, Mac OS och Linux.

Tillverkare Deltaco

Artikelnummer UC-232C9

Vendor ID 040316

Product ID 600116

Tabell 5.2. Egenskaper för serieportsadaptern. [15]

5.1 Utforskning av USB host API ochserieportsadaptern

Det här avsnittet beskriver hur USB host API, ett programmeringsgränssnitt förapplikationer i Android, användes för att skapa ett programvarubibliotek i Javamotsvarande en drivrutin för serieportsadaptern, men utan krav på administratörs-rättigheter, vilket sedan kunde användas för att enkelt skicka och ta emot data mel-lan en applikation på Android-enheten och extern hårdvara ansluten via adaptern.Bibliotekets yttre gränssnitt med metoder för att läsa och skriva data lagrad ibuffertar påminner om hur Redpark Serial-biblioteket var utformat.

5.1.1 USB host API

De aktuella klasserna för USB host API finns i paketet android.hardware.usb iAndroid från och med version 3.1 då gränssnittet introducerades [4]. Nedan följeren kort genomgång av de ingående klasserna och deras användningsområde inomdet här projektet.

UsbManager Tillåter applikationen att räkna upp (eng. enumerate) och kommu-nicera med USB-enheter. Användes för att hitta serieportsadaptern som enUSB-enhet och öppna den för läsning och skrivning av data.

UsbDevice Representerar en ansluten USB-enhet och låter applikationen kommaåt information kring USB-enhetens förmågor. Användes bland annat för attpeka ut adaptern då referenser till den behövde skickas runt i applikationen,till exempel från den aktivitet där användaren får välja USB-enhet till bib-lioteket som behöver veta för vilken USB-enhet det ska agera drivrutin för.

UsbInterface Representerar ett gränssnitt hos en USB-enhet, vilket tillhandahålleren funktionalitet, exempelvis videoöverföringen hos en videokamera som där-

27

KAPITEL 5. ANDROID-ENHET MED SERIEPORTSADAPTER

utöver kan ha ett annat gränssnitt för att styra den [11]. Användes endast föratt komma åt adapterns slutpunkter.

UsbEndpoint Representerar en slutpunkt hos en USB-enhet och är associeradmed ett specifikt gränssnitt. Användes för att specificera vilken slutpunktpå adaptern respektive överföring skulle gå till – antingen slutpunkten föringående Bulk-överföringar eller för utgående diton.

UsbDeviceConnection Tillhandahåller metoder för de olika överföringstyperna,dock begränsat till Control- och Bulk-överföringar. Användes för att skicka ochta emot data från adaptern. En UsbDeviceConnection-instans erhölls genomopenDevice()-metoden i UsbManager.

5.1.2 Serieportsadaptern

I syfte att verifiera att metoderna i klasserna ovan fungerade jämfördes deras re-turnerade värden med utdatan från kommandot lsusb -v -d 0403:6001 på enpersondator med Ubuntu installerat1 och serieportsadaptern ansluten. Se Bilaga Aför utdatan i sin helhet. Samtliga tester gav positivt resultat; serieportsadapternfanns med i listan över uppräknade enheter som UsbManager.getDeviceList()

returnerade, antalet gränssnitt (ett) som UsbDevice.getInterfaceCount() angavstämde, gränssnittet påstods korrekt av UsbInterface.getEndpointCount() om-fatta två slutpunkter och båda åt var sitt håll med Bulk som överföringstyp, enligtUsbEndpoint.getDirection() och UsbEndpoint.getType().

Efter kontrollen av de grundläggande metoderna i USB host API var det läge attta reda på hur data skulle skickas och tas emot via serieportsadaptern. De tvåslutpunkterna åt var sitt håll gav en ledtråd, men i ett test där serieportsadapternanvändes med loopback-adaptern och Bulk-överföringar i båda riktningar gjordessamtidigt överensstämde inte den skickade datan med den mottagna. Det föranleddeen närmare studie av USB-trafiken som genererades av tillverkarens egna Windows-drivrutiner samt genomgång av källkoden för tillverkarens Linux-drivrutiner. Stu-dien av USB-trafiken förbereddes genom att en virtuell maskin med Windows 7 in-stallerades i Ubuntu2 på samma persondator som användes innan, och i den virtuel-la Windows-miljön installerades version 2.08.24 av tillverkarens VCP-drivrutiner3.Sedan startades loggning av USB-trafik med Wireshark i Ubuntu, varpå adapternanslöts för att aktivera drivrutinernas initiering av den och kommandot echo A >COM3 kördes för att tvinga fram en dataöverföring på adapterns virtuella COM-port.

Delstudien ovan resulterade i följande iakttagelser. Serieportsadapterns uppbyggnadur ett USB-enhetsperspektiv såg ut som framgår av Figur 5.1; den hade tre olikaslutpunkter för de olika uppgifterna den ska klara av. Slutpunkt 0 är, som tidigare

1Ubuntu 12.04.1 med Linux 3.2.0 x86_64.2Programvaran för virtualisering som användes i Ubuntu var Oracle VirtualBox.3Virtual COM Port innebär att serieportsadaptern ser ut som en vanlig COM-port i systemet.

28

5.1. UTFORSKNING AV USB HOST API OCH SERIEPORTSADAPTERN

påpekats, obligatorisk för en USB-enhet och avsedd för konfiguration av densamma.Förutom de generella USB-kommandona, gjordes bland annat även återställning avadaptern och inställning av överföringshastigheten genom Control-överföringar tillslutpunkt 0. De två andra slutpunkterna var avsedda för att transportera serielldata till och från USB-värden med Bulk-överföringar. Överföringen av data frånUSB-värden till TX-kanalen på serieporten skedde genom att de råa bytes somskulle skickas skrevs direkt på slutpunkt 2 samlade i en array. Vid läsning av datafrån serieportens RX-kanal erhöll USB-värden inte bara de bytes som hade tagitsemot av adaptern, utan varje överföring innehöll även två inledande bytes somindikerade modem- och linjestatusen för serieporten. Även då ingen data fanns attta emot i RX-kanalen skickade adaptern regelbundet meddelanden till USB-värdenmed enbart dessa två status-bytes.

Figur 5.1. Serieportsadaptern uppbyggnad som USB-enhet med tre slutpunkter – 0:an är denobligatoriska slutpunkten för Control-överföringar avsedd för konfiguration av enheten, 1:an trans-porterar seriell data in till USB-värden och 2:an transporterar seriell data ut från USB-värden.

5.1.3 Resulterande programvarubibliotek – UsbSerial

USB host API utgjorde tillsammans med kunskapen om serieportsadapterns USB-egenskaper nyckeln för att låta Android-enheter kommunicera med extern hårdvaravia RS-232. För att ta det ett steg längre mot en fullständig lösning implementer-ades ett programvarubibliotek som på en konceptuell nivå paketerade de två kom-ponenterna, det vill säga introducerade ytterligare ett lager ovanpå USB host APIför serieportskommunikation, men enbart skapat för och testat med den aktuellaadaptern.

Programvarubiblioteket, UsbSerial, som kommer att byggas på lite längre fram,beskrivs strukturellt av Figur 5.2. Där visas programmeringsgränssnittet mot tilläm-pande applikationer i form av den abstrakta fabriksklassen UsbSerialPortAdapter

som tillhandahåller instansierade implementationer av dess gränssnitt, vilket defi-nieras av de abstrakta metoderna open() (Programkod 5.1), close() (Program-kod 5.2), read() (Programkod 5.3) och write() (Programkod 5.4). Vilken imple-mentation som returneras beror på serieportsadapterns tillverkar- och produkt-id. I

29


det här projektet implementerades stöd endast för den undersökta adaptern.

Figur 5.2. Klassdiagram över UsbSerial i ett tidigt stadium.

5.2 Integrering av ICDlib med Android NDK

I föregående avsnitt redogjorde jag för det första delproblemet, dess analys ochlösningen på hur extern hårdvara kan anslutas till en Android-enhet och kommu-niceras med genom en serieportsadapter styrd med hjälp av biblioteket UsbSerialbyggt på USB host API. I det här avsnittet beskrivs det återstående problemet,hur stöd för ICD-GPS-153-protokollet skulle implementeras. Antingen kunde detexisterande biblioteket, ICDlib, porteras till Java eller korskompilerades koden föratt köras på ARM-processorer. För det senare finns det officiellt stöd från Androidi och med Android NDK, vilket gör det till en attraktiv lösning eftersom det in-nebär att beprövad kod återanvänds och bidrar till att snabbt ge en fullständigICD-GPS-153-implementation.

5.2.1 Android NDK

Android NDK (Native Development Kit) består av en uppsättning verktyg, vil-ka tillåter att delar av en applikation implementeras i C, C++ eller liknandemaskinkodskompilerande språk. Just återanvändning av existerande bibliotek angessom exempel på användningsområde. Bland verktygen finns en kompilator anpassadför att generera ARM-kompatibla binärer och bibliotek med tillhörande huvudfil-

30

5.2. INTEGRERING AV ICDLIB MED ANDROID NDK

Programkod 5.1. Implementationen av open() för FTDI-kretskortet.

pub l i c void open ( ) {/∗ Referenser t i l l gr ä n s s n i t t e t samt s l u t p u n k t 1 och 2 . ∗/mInter face = mDevice . g e t I n t e r f a c e (0 ) ;mEndpointIn = mInter face . getEndpoint (0 ) ;mEndpointOut = mInter face . getEndpoint (1 ) ;

/∗ Fö rbered s k r i v n i n g t i l l och l ä sning f r ån adaptern . ∗/mDeviceConnection = mUsbManager . openDevice (mDevice ) ;mDeviceConnection . c l a im In t e r f a c e ( mInter face , t rue ) ;

/∗ N o l l s t ä l l s e r i e p o r t s a d a p t e r n . ∗/mDeviceConnection . c on t r o lTran s f e r (

FtdiConstants .FTDI_SIO_RESET_REQUEST_TYPE,FtdiConstants .FTDI_SIO_RESET_REQUEST,FtdiConstants .FTDI_SIO_RESET_SIO, FtdiConstants .PIT_SIOA,

nul l ,0 , TIMEOUT) ;

/∗ Sänk " l a t e n c y t imer " t i l l 10 f r ån 16 ms f ö r a t t minska f ö rdrö jn ingar . ∗/

int latencyTimer = 10 ;mDeviceConnection . c on t r o lTran s f e r (

FtdiConstants .FTDI_SIO_SET_LATENCY_TIMER_REQUEST_TYPE,FtdiConstants .FTDI_SIO_SET_LATENCY_TIMER_REQUEST,

latencyTimer ,FtdiConstants .PIT_SIOA, nul l , 0 , TIMEOUT) ;

/∗ St ä l l in symbo lha s t i ghe t en 9600. Vä rde t på baudDiv isorkommer f r ån en av ly s snad s e s s i o n med adapternso r i g i n a l d r i v r u t i n e r . ∗/

int baudDivisor = 0x4138 ;mDeviceConnection . c on t r o lTran s f e r (

FtdiConstants .FTDI_SIO_SET_BAUDRATE_REQUEST_TYPE,FtdiConstants .FTDI_SIO_SET_BAUDRATE_REQUEST, baudDivisor ,FtdiConstants .PIT_SIOA, nul l , 0 , TIMEOUT) ;

}

31


Programkod 5.2. Implementationen av close() för FTDI-kretskortet.

pub l i c void c l o s e ( ) {/∗ S l äpp ensamrä t t e n t i l l enheten och f r i g ö r a l l o k e r a d e

r e s u r s e r . ∗/mDeviceConnection . r e l e a s e I n t e r f a c e ( mInter face ) ;mDeviceConnection . c l o s e ( ) ;

}

Programkod 5.3. Implementationen av read() för FTDI-kretskortet med felhantering utelämnad.

pub l i c int read ( byte [ ] bu f f e r , int l en ) {/∗ Mottagen data f ö reg å s av t v å b y t e s f ö r s t a t u s i n d i k e r i n g .

∗/byte [ ] r e c e i v eBu f f e r = new byte [ l en + 2 ] ;

/∗ Begär data ö v e r f ö r ing f r ån s e r i e p o r t s a d a p t e r n . ∗/int r e s u l t = mDeviceConnection . bu lkTrans fe r (mEndpointIn ,

r e c e i v eBu f f e r , r e c e i v eBu f f e r . length , TIMEOUT) ;

/∗ Anta l e t b y t e s med v e r k l i g , inkommande s e r i e p o r t s d a t a . ∗/int numBytesToCopy = Math .max(0 , r e s u l t − 2) ;

i f (numBytesToCopy > 0) {/∗ Placera s e r i e p o r t s d a t a n i den angivna b u f f e r t e n . ∗/System . arraycopy ( r e c e i v eBu f f e r , 2 , bu f f e r , 0 ,

numBytesToCopy ) ;}

/∗ Returnera a n t a l e t l ä s t a b y t e s . ∗/return numBytesToCopy ;

}

er som kommer stödjas i alla framtida versioner av Android. För detaljer kringtillämpning av Android NDK hänvisas läsaren till den officiella dokumentationenpå Androids webbplats för utvecklare. [3]

Följande steg tillät ICDlib att kompileras till maskinkod som sedan kunde anropasfrån en vanlig Android-applikation i formen av ett bibliotek. Filerna tillhörandeICDlib placerades i katalogen jni i projektets källkodsträd. Därefter skapades tvåMakefile-fragment i samma katalog – Android.mk och Application.mk. De bådainkluderas under byggprocessen av Android NDK och är avsedda att låta använ-daren anpassa olika parametrar för det aktuella projektet. De enda parametrar sombehövde anges för att bygga ICDlib var namnet på modulen, vilka källkodsfiler somingick, extra kompileringsflaggor (så som avlusningsflaggan -g) och val av exekver-ingsbibliotek för C++. Det senare var nödvändigt då funktionalitet som behövdes

32


Programkod 5.4. Implementationen av write() för FTDI-kretskortet med felhantering utelämnad.

pub l i c int wr i t e ( byte [ ] data , int l en ) {/∗ Skicka den angivna s e r i e p o r t s d a t a n . ∗/int writtenDataLen = mDeviceConnection . bu lkTrans fe r (

mEndpointOut , data , len , TIMEOUT) ;

/∗ Returnera a n t a l e t s k i c kade b y t e s . ∗/return writtenDataLen ;

}

i ICDlib saknades i det förvalda exekveringsbiblioteket för C++ i Android. Lösn-ingen var att använda STLport – en alternativ implementation som innehöll allnödvändig funktionalitet. Valet specificerades genom variabeln APP_STL i Applica-tion.mk. I Android NDK, Revision 8b som användes i detta projekt är följandevärden giltiga:

system Anger att det förvalda minimala inbyggda exekveringsbiblioteket ska an-vändas. Det saknar fullt stöd för C++-standardbiblioteket; i Android 1.5 finnstill exempel endast huvudfilerna cstddef, new, utility och stl_pair.h tillgäng-liga. Vidare saknas även stöd för hantering av exekveringsfel genom C++-undantag (eng. exceptions) och typinformation under exekvering (eng. run-time type information (RTTI)). Det senare tillåter (förutsatt att RTTI ärtillgängligt) bland annat dynamiska typkonverteringar till en ärvande klassfrån föräldraklassen genom dynamic_cast<>.

gabi++_static Anger att exekveringsbiblioteket GAbi++ ska länkas statiskt.Det är liksom det inbyggda biblioteket minimalistiskt och är begränsat tillsamma uppsättning av huvudfiler. Skillnaden är att GAbi++ har stöd förRTTI.

gabi++_shared Samma som ovan, men GAbi++ länkas dynamiskt istället förstatiskt. Detta alternativ ska användas då en Android-applikation innehållerflera delade (eng. shared) biblioteksmoduler för att undvika problem som an-nars kan uppstå då ett biblioteks kod inkluderas flera gånger i den slutligabinären, vilket sker då ett statiskt bibliotek länkas av fler än en modul.

stlport_static Anger att exekveringsbiblioteket STLport ska länkas statiskt. Dethar fullt stöd för C++-standardbiblioteket och inkluderar en egen version avGAbi++ för att även stödja RTTI, men saknar stöd för C++-undantag.

stlport_shared Samma som ovan, men STLport länkas dynamiskt.

gnustl_static Anger att exekveringsbiblioteket GNU STL ska länkas statiskt. Deterbjuder mest funktionalitet av de tillgängliga valen, inklusive stöd för C++-undantag, typinformation under exekvering och fullt stöd för standardbib-lioteket.

33


Utifrån den informationen hade det naturliga valet kanske fallit på biblioteket GNUSTL med anledning av dess breda utbud av funktionalitet. Det är dock licensieratunder GPLv3 och således inkompatibelt med proprietära ICDlib. Därmed valdesSTLport, vilket visade sig vara tillräckligt för att ICDlib skulle kunna byggas ochköras.

5.2.2 Java Native Interface (JNI)

För att anropa kod i bibliotek som byggts med Android NDK är standardförfarandetatt utnyttja Java Native Interface (JNI). Gränssnittet tillåter dubbelriktad kom-munikation mellan maskinkod och en virtuell Java-maskin (JVM). Maskinkod somanropar en virtuell Java-maskin kan komma åt statiska fält och instansvariablersåväl som metoder hos objekt och klasser samt hantera arrayer, skapa nya objekt,kasta och fånga undantag etc. Åt andra hållet kan Java-kod anropa maskinkodgenom metoder som markerats med nyckelordet native, vilka sedan implementer-ats i maskinkodskompilerande språk, vanligen C eller C++. På maskinkodssidanfinns en pekare till funktionstabellen för JNI tillgänglig per tråd och den användsför att utföra operationer i den virtuella Java-maskinen. Exempelvis kan en sådanpekare av typ JNIEnv* kallad jniEnv användas för att ta reda på längden av en ar-ray döpt till jArray på det här viset: int length = jniEnv−>GetArrayLength(jArray).[28]

I det här projektet utnyttjades JNI för att skapa Java-klasser med native-metoderför ICDClient och PackUnpack – den senare med nyttofunktioner för att avkodaolika typer av data i ICD-GPS-153-meddelanden. I Programkod 5.5 visas delar avICDClient.java som exempel på hur en sådan klass kan se ut. Denna implementer-ades sedan i C/C++ med hjälp av JNI-funktioner som framgår av det utdrag somvisas i Programkod 5.6.

Programkod 5.5. Förkortad version av ICDClient.java med förklarande kommentarer som visarhur nyckelordet native används i JNI-sammanhang.

/∗ Paketnamnet används senare som en komponent i funktionsnamneni maskinkoden . ∗/

package se . s t . i cdgps . i c d l i b ;

/∗ En van l i g , p u b l i k Java−k l a s s . . . ∗/pub l i c c l a s s I cdC l i en t {

/∗ . . . med en v a n l i g kons t ruk t o r . ∗/pub l i c I cdC l i en t ( UsbSer ia lPortAdapter usbSer ia lPortAdapter ) {

/∗ Java−kod kan anropa egna metoder implementerade imaskinkod som v i l k e n annan metod som h e l s t . ∗/

i n i t ( ) ;}

/∗ En p r i v a t metod markerad med " na t i v e " f ö r a t t i nd i k e r a a t tdess implementat ion b e s t å r av maskinkod . Ett e x t ra

34


nycke lord , " synchronized " , används ocks å f ö r a t t s ä k e r s t äl l a a t t metoden kö rs atomä r t . ∗/

pr i va t e synchron ized nat ive void i n i t ( ) ;

/∗ En p u b l i k metod som ocks å implementeras i maskinkod . ∗/pub l i c nat ive int sendDataTransferMessages ( Cl ientLibMessage [ ]

data ) ;

}

Programkod 5.6. Förkortad version av C/C++-delarna av Java-klassen IcdClient med förk-larande kommentarer.

#include " se_st_icdgps_icd l ib_IcdCl ient . h "#include <cstd io>#include <j n i . h>#include " ICDClient . h "#include " Cl ientLibMessage . h "

/∗ Modulg loba l pekare t i l l en in s t an s av ICDClient i ICDlib . ∗/stat ic ICDClient∗ i c dC l i e n t = NULL;

/∗ Funkt ionss i gna turen här i n d i k e r a r a t t de t ä r en implementat ionav metoden " i n i t ( ) " i k l a s s e n " I c d C l i e n t " i p a k e t e t " se . s t .

i cdgp s . i c d l i b " . ∗/JNIEXPORT void JNICALL Java_se_st_icdgps_icdl ib_IcdCl ient_init (

JNIEnv∗ env , j o b j e c t obj ) {i f ( i c dC l i e n t == NULL) {

i cdC l i e n t = new ICDClient ;}

}

/∗ Utö ver de t v å argument som JNI−f unk t i o ne r a l l t i d anropas medta s här även emot en array med Java−o b j e k t . ∗/

JNIEXPORT j i n t JNICALLJava_se_st_icdgps_icdl ib_IcdClient_sendDataTransferMessages (JNIEnv∗ env , j o b j e c t obj , j ob j e c tArray jmessages ) {/∗ Dek lara t ion av v a n l i g a C++−v a r i a b l e r . ∗/std : : vector<ClientLibMessage> messages ;enum ClientLibMessageType type ;uint8_t ∗ value ;unsigned int valueLen ;int messageId ;

/∗ JNIEnv−pekaren används här f ö r a t t hämta Java−in format ion .∗/

j c l a s s c l sC l i entL ibMessage = env−>FindClass ( " se . s t . i cdgps .i c d l i b . Cl ientLibMessage " ) ;

jmethodID getTypeValueMethod = env−>GetMethodID(c l sCl i entL ibMessage , " getTypeValue " , " ( ) I " ) ;

35


jmethodID getValueMethod = env−>GetMethodID(c l sCl i entL ibMessage , " getValue " , " ( ) [B" ) ;

jmethodID getMessageIdMethod = env−>GetMethodID(c l sCl i entL ibMessage , " getMessageId " , " ( ) I " ) ;

j s i z e jmessagesCount = env−>GetArrayLength ( jmessages ) ;

/∗ Skapa ClientLibMessage−o b j e k t f ö r a l l a meddelanden som skask i ckas , och p l ace ra dem i C++−behå l l a r e n s t d : : v e c t o r . ∗/

for ( int i = 0 ; i < jmessagesCount ; ++i ) {/∗ Det mö j l i g a a n t a l e t samt id iga l o k a l a Java−r e f e r e n s e r ä

r begr ä nsat , v i l k e t r i s k e r a r ö v e r s t i g a s då sådanaskapas i n u t i i t e r a t i o n e r som här . PushLocalFrame används f ö r a t t skapa en ram som begr ä nsar deras l i v s l ängd. ∗/

env−>PushLocalFrame (3) ;

/∗ Skapa l o k a l r e f e r e n s t i l l o b j e k t e t på i : e p l a t s e n iarrayen jmessages . ∗/

j o b j e c t jc lm = env−>GetObjectArrayElement ( jmessages , i ) ;

/∗ Anropa en metod på o b j e k t e t och konver te ra de tre turnerade vä rde t i form av en Java−enum t i l lmotsvarande enum i C++. ∗/

j i n t clmType = env−>CallIntMethod ( jclm ,getTypeValueMethod ) ;

type = sta t i c_cas t <ClientLibMessageType >(clmType ) ;

/∗ Hämta datainneh å l l e t i meddelandet i form av en byte−

array samt l ä s ut l ängden av arrayen . ∗/jbyteArray j va l u e = ( jbyteArray ) env−>CallObjectMethod (

jclm , getValueMethod ) ;jbyte ∗ va lue jbp = env−>GetByteArrayElements ( jva lue , NULL)

;va lue = ( uint8_t ∗) va lue jbp ;valueLen = env−>GetArrayLength ( j va l u e ) ;

/∗ Skapa C++−o b j e k t e t som senare ska s k i c k a s t i l l GPS−mottagaren . ∗/

ClientLibMessage clm ( type , value , valueLen ) ;clm . messageId = env−>CallIntMethod ( jclm ,

getMessageIdMethod ) ;

messages . push_back ( clm ) ;

/∗ Frig ör r e s u r s e r som anvä nts f ö r a t t hå l l a datainneh ål l e t . ∗/

env−>ReleaseByteArrayElements ( jva lue , valuejbp , JNI_ABORT) ;

36


/∗ Avs lu ta den t i d i g a r e påbö r jade ramen f ör l o k a l ar e f e r e n s e r . ∗/

env−>PopLocalFrame (NULL) ;}

/∗ Använd ICDClient i ICDlib f ö r a t t s k i c k a i v ägdatameddelandet . ∗/

return i cdC l i en t−>sendDataTransferMessages ( messages ) ;}

Utöver ICDClient och PackUnpack skapades även ett Java-gränssnitt för ICDlib-klassen ClientLibMessage som enbart agerade datahållare för meddelanden. Denanvändes för att transportera meddelanden från maskin- till Java-kod genom attdet i maskinkoden skapades ett nytt Java-objekt av typen ClientLibMessage somfylldes på med aktuell data och sedan skickades som referens till Java-koden därdet var aktuellt.

5.2.3 Ihopkoppling med UsbSerial

Därmed var ICDlib på plats och tillgängligt via ett Java-gränssnitt, men det åter-stod att koppla ihop det med UsbSerial för att det skulle kunna kommunicera medGPS-mottagaren. Ett första försök byggde på metoden getFileDescriptor() iklassen UsbDeviceConnection, vilken enligt dokumentationen skulle returnera denursprungliga filidentifieraren i syfte att skickas vidare till maskinkod för användningdär. Dessvärre misslyckades försöket då anrop till read() i unistd.h returnerade 0,det vill säga att ingen data hade lästs, trots att aktivitet på på serieporten indik-erats av externa verktyg, och ingen igenkännlig data hade sparats i den angivnabufferten. Ingen närmare undersökning gjordes för att bestämma felkällan då detprimära målet ju var att hitta ett fungerande tillvägagångssätt och det fanns flerakandiderande sådana. En trolig förklaring är dock att read()-operationen vidarebe-fordrades av operativsystemet till underliggande drivrutin för den aktuella enheten(serieportsadaptern), vilken saknade drivrutin och därför resulterade i uteblivenläsning och ett tomt returvärde.

På tur stod en lösning baserad på inter-processkommunikation genom sockets, vilkenvisade sig vara fullt funktionsduglig. Figur 5.3 visar hur biblioteket UsbSerial ut-ökades med bland annat klassen LocalServerSocketThread som i korta drag till-gängliggör TX- och RX-kanalerna på serieporten i form av en lokal socket. Inkom-mande data från serieportens RX-kanal registreras av ReceiveSerialPortData-

Worker som meddelar samtliga registrerade lyssnare av typen SerialPortData-

Listener, vilket i den aktuella konfigurationen endast är LocalServerSocket-

Thread-instansen. Denna instans sänder genast ut den mottagna datan på en lokalsocket som ICDlib är ansluten till och därmed erhåller datan. Åt andra hållet, närICDlib skriver något på samma lokala socket upptäcker LocalServerSocketThread

37


detta och använder UsbSerialPortAdapter för att skicka datan via serieportensTX-kanal.

En stor fördel med användandet av sockets var att det enda som behövde ändras iICDlib var initialiseringen av filidentifieraren som användes i biblioteket vid läsningoch skrivning av serieportsdata. Istället för att anropa open() med serieportensenhetsnamn i operativsystemet anropades först socket() för att skapa en lämpligfilidentifierare och sedan connect() med namnet på den socket som beskrevs ovan.Allt annat kunde lämnas orört till skillnad från lösningen för iOS där fler delar avICDlib behövde modifieras.

38


Figur 5.3. Klassdiagram över utökningen av UsbSerial med lokal socket samt psuedokod för hurICDlib ansluter till densamma.

39

Kapitel 6

Slutsats

Det här projektet visar att att det finns flera möjligheter att kommunicera medextern hårdvara via RS-232 från mobila enheter. Följande två valdes ut för imple-mentation i syfte att kontrollera deras funktion:

• iOS-enhet i form av iPad 1 med iOS 5.0.1 och Apple-godkänt tillbehör förRS-232.

• Android-enhet i form av Acer Iconia Tab A200 med Android 4.0 och generellRS-232-adapter.

Därmed inkluderade lösningarna de två största plattformarna för mobila enheter påmarknaden idag och båda fungerade tillfredsställande utan några märkbara prob-lem vid kommunikation med GPS-mottagaren. Vidare finns det förutsättningar förfullt utvecklat stöd av protokollet ICD-GPS-153 genom att företagets existerandeprogramvarubibliotek ICDlib kunde integreras i båda lösningarna. Integreringenkrävde förvisso en del anpassning av koden till respektive plattform, men denna börrimligen vara möjlig att göra portabel genom att till exempel använda preprocess-makron.

Projektet har således lagt grunden för en fullskalig produkt som kan kommunicerafritt med GPS-mottagaren inom ramen för ICD-GPS-153-protokollet, om företagetväljer att ta fram en sådan. För att nå dit återstår dock bland annat att

• implementera vissa JNI-bindningar som saknas

• bygga ut stödet för serieportsadaptrar med annat kretskort än det från FTDIför att öka kompatibiliteten med tillgänglig hårdvara

• utveckla användargränssnittet så att alla tillgängliga funktioner i biblioteketgörs åtkomliga för användaren

Frågan om vilken lösning som är lämpligast för det tänkta användningsscenari-ot besvarar jag med att påstå att det inte föreligger någon funktionsmässig skill-nad dem emellan – det vill säga att båda hanterar kommunikationen likvärdigt i

40

dagsläget. Istället är det mer intressant att betrakta lösningarnas framtidsutsikter;vilka risker finns det att de slutar fungera eller blir omöjliga att implementera iframtiden?

Betänk först den använda hårdvaran, till att börja med Redpark Serial Cable föriOS och en generell serieportsadapter för Android. Där står det ganska klart attberoendet av Redpark är riskabelt i jämförelse med att kunna använda en generellserieportsadapter. Å andra sidan finns det inga garantier för vilken hårdvara somkommer att användas i Android-enheter framöver. Risken här ligger i att USB-host-stöd är absolut nödvändigt, men alltså inte garanterat. Dock anser jag dethögst troligt att även framtida mobila enheter med Android kommer att kunnaagera USB-värd då det innebär en konkurrensfördel på marknaden – eller sett urett annat perspektiv: det är en klar nackdel att inte erbjuda USB-host-stöd.

Betraktande integreringen av ICDlib bygger den i fallet med iOS på stöd för Objective-C++ i Xcode, men sannolikheten att det skulle försvinna är låg eftersom det ingåri både GCC och Clang, och för att Clang anger som ett av sina huvudsakliga målatt stödja Objective-C++ [30]. Dessutom är till och med vissa delar av exekver-ingsmiljön för Objective-C skrivna i Objective-C++ [6]. Lösningen för Android för-litar sig endast på officiellt stödda verktyg och tillvägagångssätt så som USB hostAPI och Android NDK.

Sammantaget ger resonemanget fördel för Android-lösningen på grund av en upp-skattningsvis något större framtidssäkerhet. Dessutom anser jag att om det någongång i framtiden släpps en robust mobil enhet som gör den särskilt lämplig i dentänkta tillämpningen så är det troligare att den har USB-värdstöd och kör Androidän att den tillverkats av Apple och kör iOS. Det baserar jag på designen av Apple:stidigare släppta produkter och licensen för iOS som begränsar dess användning tillApple-produkter i motsats till öppenheten hos Android.

41

Litteraturförteckning

[1] A. Allan. iOS Sensor Apps with Arduino: Wiring the iPhone and iPad intothe Internet of Things. Oreilly & Associates Incorporated, 2011.

[2] Open Handset Alliance. Industry Leaders Announce Open Platform for Mo-bile Devices. http://www.openhandsetalliance.com/press_110507.html, 5november 2007. Hämtat 2012-09-23.

[3] Android. Android NDK | Android Developers. http://developer.android.

com/tools/sdk/ndk/index.html. Hämtat 2012-10-06.

[4] Android. USB Host | Android Developers. http://developer.android.com/

guide/topics/connectivity/usb/host.html. Hämtat 2012-10-04.

[5] Apple. Hardware & Software Product Agreements. http://www.apple.com/

legal/sla/. Hämtat 2012-09-26.

[6] Apple. Source Browser (objc4). http://www.opensource.apple.com/

source/objc4/objc4-532/runtime/. Hämtat 2012-10-07.

[7] Apple. Apple Reinvents the Phone with iPhone [Pressrelease]. http://www.apple.com/pr/library/2007/01/

09Apple-Reinvents-the-Phone-with-iPhone.html, 9 januari 2007. Hämtat2012-09-26.

[8] Apple. iOS Developer Library. http://developer.apple.com/library/ios/,2012. Hämtat 2012-09-26.

[9] Philip Asare, Danyang Cong, Santosh G. Vattam, BaekGyu Kim, Andrew King,Oleg Sokolsky, Insup Lee, Shan Lin, and Margaret Mullen-Fortino. The med-ical device dongle: an open-source standards-based platform for interoperablemedical device connectivity. In Proceedings of the 2nd ACM SIGHIT Interna-tional Health Informatics Symposium, IHI ’12, pages 667–672, New York, NY,USA, 2012. ACM.

[10] J. Axelson. USB complete: Everything you need to develop custom USB pe-ripherals. Lakeview Research LLC, fourth edition, 2005.

42

LITTERATURFÖRTECKNING

[11] J. Axelson. Serial Port Complete Second Edition: COM Ports, USB VirtualCOM Ports, and Ports for Embedded Systems. Lakeview Research LLC, 2007.

[12] L. Batyuk, A.D. Schmidt, H.G. Schmidt, A. Camtepe, and S. Albayrak. Devel-oping and benchmarking native linux applications on android. In MobileWire-less Middleware, Operating Systems, and Applications, volume 7, pages 381–392. Springer, 2009.

[13] Henry Blodget. Apple’s iPhone Has Staged A MonsterComeback, Android Is Now Dead In The Water. http://

articles.businessinsider.com/2012-03-30/tech/31258390_1_

tablet-market-smartphone-market-iphone, 30 mars 2012. Hämtat2012-10-07.

[14] E.Y. Chen and M. Itoh. Virtual smartphone over IP. In World of WirelessMobile and Multimedia Networks (WoWMoM), 2010 IEEE International Sym-posium on a, pages 1–6. IEEE, 2010.

[15] Deltaco. Deltaco - The Missing Link - Produkter - Standard - Datorkomponen-ter - CPU - Intel - (UC-232C9). http://www.deltaco.se/products/items/

itemid/(UC-232C9)/index.aspx. Hämtat 2012-10-04.

[16] B. Eckel. Thinking in C++: Introduction to Standard C++, Volume One (2ndEdition) (Vol 1). Prentice Hall, 2000.

[17] A. El-Rabbany. Introduction to GPS: the global positioning system. ArtechHouse Publishers, 2002.

[18] Free Software Foundation, Inc. GNU compilers manual. http://gcc.gnu.

org/onlinedocs/gcc/Standards.html, 2010. Hämtat 2012-09-27.

[19] GSMArena.com. Acer Iconia Tab A200 - Full phone specifications. http://

www.gsmarena.com/acer_iconia_tab_a200-4450.php. Hämtat 2012-10-01.

[20] GSMArena.com. Apple iPad Wi-Fi - Full phone specifications. http://www.

gsmarena.com/apple_ipad_wi_fi-3828.php. Hämtat 2012-10-01.

[21] D. Hasenfratz, O. Saukh, S. Sturzenegger, and L. Thiele. Participatory airpollution monitoring using smartphones. Mobile Sensing, 2012.

[22] Karen Haslam. Macworld Expo: Optimised OS X sits on ’versatile’ flash. http:

//www.macworld.co.uk/ipad-iphone/news/?newsid=16927, 12 januari 2007.Hämtat 2012-09-26.

[23] D.A. Heger. Mobile Devices-An Introduction to the Android Operating Envi-ronment Design, Architecture, and Performance Implications. DHTechnologies(DHT), retrieved March, 1, 2012.

43


[24] International Data Corporation (IDC). Android- and iOS-Powered Smart-phones Expand Their Share of the Market in the First Quarter, Accord-ing to IDC [Press Release]. http://www.idc.com/getdoc.jsp?containerId=

prUS23503312, 24 maj 2012. Hämtat 2012-10-07.

[25] Phillip Jordan. Strategies for Using C++ in Objective-C Projects (andvice versa). http://philjordan.eu/article/strategies-for-using-c+

+-in-objective-c-projects, 2 november 2010. Hämtat 2012-10-03.

[26] Phillip Jordan. Mixing Objective-C, C++ and Objective-C++: an Up-dated Summary. http://philjordan.eu/article/mixing-objective-c-c+

+-and-objective-c++, 15 maj 2012. Hämtat 2012-10-03.

[27] S. Lee and J.W. Jeon. Evaluating performance of Android platform using nativeC for embedded systems. In Control Automation and Systems (ICCAS), 2010International Conference on, pages 1160–1163. IEEE, 2010.

[28] S. Liang. The Java Native Interface: Programmer’s Guide and Specification.Addison-Wesley, 1999.

[29] C.M. Lin, J.H. Lin, C.R. Dow, and C.M. Wen. Benchmark dalvik and nativecode for android system. In Innovations in Bio-inspired Computing and Ap-plications (IBICA), 2011 Second International Conference on, pages 320–323.IEEE, 2011.

[30] LLVM. clang: a C language family frontend for LLVM. http://clang.llvm.

org/. Hämtat 2012-10-07.

[31] MakerSHED. Redpark TTL Cable for iOS. http://www.makershed.com/

Redpark_TTL_Cable_for_iOS_p/msrp03.htm. Hämtat 2012-09-27.

[32] Next Computer Inc. NeXTSTEP Object-Oriented Programming and the Objec-tive C Language, Release 3 (NeXTSTEP Developer’s Library). Addison WesleyPublishing Company, 1993.

[33] Matthew Russell. What Is Darwin (and How It Powers Mac OSX). http://macdevcenter.com/pub/a/mac/2005/09/27/what-is-darwin.

html, 27 september 2005. Hämtat 2012-09-26.

[34] D. Semiconductor. Fundamentals of RS-232 serial communications. Technicalreport, Application Note, 2000.

[35] Agam Shah. Google’s Android 4.0 ported to x86 processors.http://www.computerworld.com/s/article/9222323/Google_s_Android_

4.0_ported_to_x86_processors, 1 december 2011. Hämtat 2012-09-24.

[36] Sjöland & Thyselius. Försvar. http://www.st.se/branscher/forsvar. Häm-tat 2012-09-12.

44


[37] H.K. Teng, C.M. Lin, K.C. Lang, Y.L. Chu, and S.J. Chen. An Implementationfor Connecting Android Powered Device to External World. In Innovations inBio-inspired Computing and Applications (IBICA), 2011 Second InternationalConference on, pages 303–305. IEEE, 2011.

[38] David R. Tribble. Incompatibilities Between ISO C and ISO C++. http:

//david.tribble.com/text/cdiffs.htm, 5 augusti 2001. Hämtat 2012-10-02.

45

Bilaga A

Detaljerad information om

USB-serieportsadaptern

Bus 005 Device 003: ID 0403:6001 Future Technology Devices International,

Ltd FT232 USB-Serial (UART) IC

Device Descriptor:

bLength 18

bDescriptorType 1

bcdUSB 2.00

bDeviceClass 0 (Defined at Interface level)

bDeviceSubClass 0

bDeviceProtocol 0

bMaxPacketSize0 8

idVendor 0x0403 Future Technology Devices International, Ltd

idProduct 0x6001 FT232 USB-Serial (UART) IC

bcdDevice 6.00

iManufacturer 1

iProduct 2

iSerial 3

bNumConfigurations 1

Configuration Descriptor:

bLength 9

bDescriptorType 2

wTotalLength 32

bNumInterfaces 1

bConfigurationValue 1

iConfiguration 0

bmAttributes 0xa0

(Bus Powered)

Remote Wakeup

MaxPower 44mA

46

Interface Descriptor:

bLength 9

bDescriptorType 4

bInterfaceNumber 0

bAlternateSetting 0

bNumEndpoints 2

bInterfaceClass 255 Vendor Specific Class

bInterfaceSubClass 255 Vendor Specific Subclass

bInterfaceProtocol 255 Vendor Specific Protocol

iInterface 2

Endpoint Descriptor:

bLength 7

bDescriptorType 5

bEndpointAddress 0x81 EP 1 IN

bmAttributes 2

Transfer Type Bulk

Synch Type None

Usage Type Data

wMaxPacketSize 0x0040 1x 64 bytes

bInterval 0

Endpoint Descriptor:

bLength 7

bDescriptorType 5

bEndpointAddress 0x02 EP 2 OUT

bmAttributes 2

Transfer Type Bulk

Synch Type None

Usage Type Data

wMaxPacketSize 0x0040 1x 64 bytes

bInterval 0

47

TRITA-CSC-E 2013:014 ISRN-KTH/CSC/E--13/014-SE

ISSN-1653-5715

www.kth.se

Documents

Kommunikation med extern, avancerad GPS-utrustning via mobil …680409/FULLTEXT01.pdf · 2013. 12. 18. · Kommunikation med extern, avancerad GPS-utrustning via mobil enhet JOEL