7. Kommunikation mellan övervakningsenhet och målsystem
7.3 JTAG
Vid utveckling av mjukvara så är det i princip omöjligt att hålla den helt fri från buggar. Om man utvecklar mjukvara som är tänkt att exekvera på en PC så finns det ett antal olika verktyg man kan använda sig av däribland mjukvara för felsökning (eng. debugging). Med hjälp av felsökning kan man lättare lösa svårhittade buggar i koden då man kan följa exekveringen rad för rad. Felsökning av mjukvara är svårare att utföra om den inte exekveras lokalt utan istället på ett inbyggt system. För att lösa detta har JTAG implementerats som ett av kommunikationssätten i övervakningsenheten. Genom JTAG möjliggörs framförallt två funktioner: att felsöka målsystemet samt att ladda in ett nytt program.
JTAG-standarden (IEEE 1149.1) utvecklades under 1980-talet av Joint Test Action Group (därav JTAG) och blev färdigt år 1990. Ett antal förbättringar av den ursprungliga versionen gjordes och den senaste versionen, som fortfarande används idag, blev klar 1994 [19]. JTAG används främst i stor skala inom industrin när det gäller testning av komplexa konstruktioner inom elektronik för att hitta brister under tillverkningsprocessen. Under åren har det dock insetts vikten av användningsområden utanför produktionen. JTAG kan numera användas inom design, felsökning och till underhåll av elektronik. På så sätt är det lättare att motivera implementationen av JTAG då den kan användas i flera stadier under produktens livscykel [20]. Med hjälp av JTAG fås det tillgång till systemets interna delar såsom processor, RAM och dess olika periferienheter. Detta är en viktig egenskap som gör det möjligt för utvecklare att få full obegränsad kontroll över systemet och dess information på hårdvaru-nivå. [21]
Konceptet bakom användning av JTAG är relativt enkel. I komponenten som ska testas, t.ex. processorn, så måste speciella kretsar för test placeras vid varje pinne. Test-kretsen har förmågan att antingen kontrollera händelseförloppet i komponenten eller endast övervaka den. Till varje test-krets finns även ytterligare logik som berättar när test-kretsen ska utföra tester och när den ska låta komponenten bete sig som vanligt när JTAG inte används. Användningen av dessa test-kretsar innebär att de kan få specifika saker att hända i system eller delsystem samt se vad resultatet blev utan att behöva veta något om komponenterna eller hur de fungerar. Detta gör JTAG till en testmetod som är helt oberoende av den bakomliggande komplexiteten hos komponenterna som testas. [22] Till JTAG finns ett standardiserat språk definierat kallat BSDL (Boundary-Scan Description Language). Med hjälp av detta språk kan tillverkare av diverse komponenter beskriva vilka testmöjligheter som finns för deras respektive komponenter. Eftersom ansvaret att beskriva testmöjligheterna fallit på tillverkarna av komponenterna så har standardiseringen av språket varit viktigt då det har hjälpt till att förebygga problem orsakade av inkorrekt användning av språket. Dessa beskrivningar finns till en mängd olika komponenter och är en av anledningarna till att JTAG används så pass flitigt. [22]
34
7.3.1 Felsökningsmjukvara
Kommunikationssättet via JTAG kräver två olika mjukvaror för att fungera, vilka är OpenOCD och GNU gdb.
OpenOCD (Open On-Chip-Debugging) är en mjukvara, byggd på öppen källkod, som möjliggör felsökning (eng. debugging) av inbyggda system. Felsökningen sker genom att OpenOCD kommunicerar med processorn på målsystemet för att både extrahera samt påverka data. För att kommunicera med målsystemet måste någon form av protokoll användas. OpenOCD stödjer både JTAG samt SWD (Serial Wire Debug) protokoll, varav det sistnämnda används till nyare ARM processorer. Vid felsökning ansluts ofta någon form av adapter med stöd för ett eller flera protokoll. I projektet används dock ingen adapter utan anslutningen sker via GPIO-pinnarna istället. [23] I den nyaste versionen av OpenOCD finns nämligen en ”bit-banging” drivrutin som har funktionen att sköta kommunikationen via GPIO- pinnarna. Bit-banging innebär att det inte finns någon dedikerad hårdvara som sköter kommunikationen utan allt sköts istället av mjukvara. Denna nya version av OpenOCD finns inte att hämta från Raspberry Pis mjukvarubibliotek utan källkoden fick hämtas och kompileras manuellt för att sedan installeras.
GNU gdb (The GNU Project Debugger) är en felsökningsmjukvara, byggd på öppen källkod, som används som standard i Linux-miljö. GNU gdb innehåller funktioner som möjliggör att man kan se vad som händer medan ett program exekverar eller vad programmet höll på med vid eventuell krasch. Det finns möjlighet att definiera speciella villkor när programmet ska stoppa och det finns även stöd för att ändra olika ting under exekvering, såsom t.ex. innehåll i variabler. GNU gdb stödjer ett antal olika programmeringsspråk däribland C, C++ och Pascal. [24]
Kommunikationssättet via JTAG fungerar på så sätt att användaren först måste ansluta till övervakningsenheten via fjärrstyrningen för att starta OpenOCD på övervakningsenheten. På PC:n måste GNU gdb finnas installerat vilket används till att ansluta till OpenOCD på övervakningsenheten via internet. OpenOCD har inbyggt stöd för att kunna fjärrstyras av GNU gdb via ett inbyggt protokoll kallat gdbserver [25]. GNU gdb används för att skicka kommando från PC:n till OpenOCD som tolkar dessa på övervakningsenheten. OpenOCD kommunicerar därefter med målsystemet via JTAG för att verkställa det kommando som togs emot från GNU gdb. OpenOCD tar sedan emot information, som representerar resultatet av kommandot, från målsystemet som skickas tillbaka till GNU gdb som presenterar denna för användaren. På detta vis kan man utföra fjärrfelsökning av målsystemet via OpenOCD som fungerar som en mellanhand mellan målsystemet och GNU gdb på PC:n. I bilaga 2 förklaras det i detalj hur man utför felsökning på målsystemet
35
7.3.2 Koppling
Målsystemet som JTAG testats mot är en Arduino Due. Denna enkortsdator valdes då den har alla de nödvändiga pinnarna tillgängliga men även för att OpenOCD har stöd för den genom drivrutiner som är nödvändiga för kommunikationen. Tester har endast utförts på Arduino Due men fungerar troligtvis även på andra målsystem men det krävs då att OpenOCD har drivrutiner för målsystemet samt att nedan beskrivna anslutningsmöjligheter finns. För att kunna ansluta via JTAG krävs det att följande signaler finns tillgängliga på målsystemet: [21]
TDI (Test Data Input) tar emot insignaler i form av en bitström från målsystemet TDO (Test Data Output) ger utsignaler i form av en bitström till målsystemet
TCK (Test ClocK) tillhandahåller en synkron klocksignal som målsystemet använder sig av för timing av signalerna.
TMS (Test Mode Selection) signal som bestämmer i vilket läge som målsystemet ska arbeta. TRST (Test ReSeT) används för att återställa JTAG anslutningen
GND (Ground) referenskälla för jord VCC (Voltage Supply) spänningskälla
På Arduino Due finns en JTAG-header med 5*2 pinnar, varav två används, där signalerna TDI och TDO ansluts. Utöver detta finns en debugg-header med fyra pinnar där resten av de nödvändiga pinnarna ansluts. I figur 14 visas ett kretsschema på hur JTAG- kommunikationen är kopplad.
36
8. Målsystem
I detta avsnitt beskrivs enkortsdatorn Arduino som valts ut som målsystem där kommunikationssystemet har testats mot. Några av fördelarna med Arduino förklaras, varför det valdes som målsystem samt hur det fungerar tillsammans med dess periferienheter.
I projektet har en Arduino Uno valts som primärt målsystem. Arduino är en familj av olika prototypplattformar som bygger på helt öppen mjukvara och hårdvara. Arduino har många olika användningsområden och riktar sig både till nybörjare och erfarna användare som vill utveckla och skapa interaktiva och kreativa föremål [26]. Arduino Uno bygger på mikrokontrollern ATmega328 som arbetar i 16 MHz, innehåller 32 KB flash-minne och 2 KB SRAM [27].
Några av fördelarna med Arduino är:
Arduino Uno är en relativt billig plattform jämfört med andra plattformar, baserade på mikrokontrollers, på marknaden idag. En Arduino kostar ungefär 240 kronor ink. moms (våren 2013).
Arduinos utvecklingsmiljö har stöd för de största operativsystemen däribland Windows, Macintosh OSX och Linux.
Arduinos utvecklingsmiljö, baserat på Java, och programmeringsspråk, baserat på C/C++ bibliotek kallat Wiring, bygger på öppen källkod.
De olika mikrokontrollerna och kretsschemat för Arduino bygger på öppen hårdvara vilket innebär att erfarna kretsdesigners kan ändra och förbättra hårdvaran.
Anledningen till att Arduino Uno valdes som målsystem är att det går snabbt att skriva enkla program då det finns färdiga bibliotek med kod. Plattformen innehåller även de nödvändiga delarna för seriekommunikation och avläsning/påverkan av digitala signaler. Arduinon är ett målsystem endast avsedd för test där resten av systemet testas mot. Då programmeringen av Arduinon inte krävde mycket tid så kunde desto mer tid läggas på att utveckla övervakningsenheten och webbgränssnittet istället. En Arduino Uno valdes som målsystem för att testa seriekommunikationen samt avläsning/påverkan av digitala signaler. För JTAG hade dock Arduino Uno inte de nödvändiga anslutningarna så därför användes en Arduino Due till detta ändamål. Arduino Due är en nyare och kraftfullare version av Arduino Uno som endast användes för att testa JTAG-kommunikationen.
37
Det är tänkt att målsystemet ska avge någon form av mätvärden som ska skickas till övervakningsenheten. Därför är en temperatursensor (LM35) inkopplad till Arduino Uno som vid jämna intervall läser av temperaturen för att sedan skicka iväg värdet. Som tidigare nämnts har användare möjlighet att ställa in olika inställningar i webbgränssnittet. En av dessa inställningar bestämmer om temperaturen ska avläsas i Fahrenheit eller Celsius. Det finns tre inställningar till genom vilka man kan slå av och på tre stycken LED-lampor som är inkopplade till Arduinon. Både temperaturkonverteringen och LED-lamporna fungerar som feedback för att säkerställa att inställningarna utförs på målsystemet. Arduinon har ett antal hybrida GPIO-pinnar som är kopplade till övervakningsenheten och som både kan bete sig som in eller utgångar. För att kunna styra om dessa ska vara höga eller låga så har en uppsättning knappar kopplats in. Knapparna fungerar som en switch och vid varje knapptryck inverteras pinnens läge.
I figur 15 visas ett kretsschema på hur Arduinon är ihopkopplade med dess periferienheter.
38
9. Prototypkostnad
I projektet har det arbetats med att få en billig och bra lösning till övervakningsenheten. Komponenterna som använts i systemet beskrivs och sammanfattas i en tabell för att få den slutgiltiga kostnaden för övervakningsenheten.
Under arbetet med prototypen har det arbetats med att försöka hitta en så bra och billig lösning som möjligt. Detta då syftet med projektet var att göra en kostnadseffektiv övervakningsenhet. Efter tidigare beskrivet utredningsarbete visade det sig att Raspberry Pi var den plattform som var mest prisvärd för ändamålet (se kapitel 5; Jämförelse av enkortsdatorer).
Eftersom Raspberry Pi är en relativt ny enkortsdator så är processorn baserad på en spänning på 3,3 V för att vara energisnål. På grund av detta använder vi oss av två stycken nivåomvandlare för att systemet även skall vara kompatibelt med målsystem baserade på 5 V. Detta gör att kostnaden för prototypen ökar något, men samtidigt så minskar energiförbrukningen.
För att kunna använda Raspberry Pi behövs även en strömförsörjning i form av en strömadapter 230 V till 5 V 1 A USB som är kopplad via en USB A-hane till mikro B hane- sladd. Dessutom krävs även ett SD-kort där operativsystemet och annan mjukvara lagras, detta ingår inte i priset av Raspberry Pi utan måste köpas separat. För att förenkla kopplingen till målsystemet används även ett anslutningskort som kallas BreadPi med en flatkabel som gör att man enkelt kan koppla Raspberry Pis GPIO-pinnar till ett brödbord. För kommunikationen med användargränssnittet och databasen behövs även en TP kabel för att koppla upp Raspberry Pi mot nätverket. I tabell 11 visas en kalkyl över nödvändig hårdvara för systemet.
Kostnadskalkyl för prototyp
Komponenter Pris
Raspberry Pi 320 kr
Nätverks kabel (0,5m) 25 kr
SD-kort till Raspberry Pi 140 kr
Nivåomvandlare RS-232 22 kr
Batterieliminator USB 5V 1A 79 kr USB-kabel A-hane - micro B 5p hane 33 kr
Nivåomvandlare 8 kanaler 79 kr
BreadPi anslutningskort ink kabel 69 kr
767 kr
39
10. Test av system
I detta kapitel redogörs det hur testerna av de olika delarna i systemet har utförts för att verifiera att de fungerar som specificerat. Tester har utförts för att se att de olika funktionerna i webbgränssnittet samt kommunikationen med databasen fungerar . Det har också utförts tester för att kontrollera att de olika kommunikationssätten mellan målsystemet och övervakningsenheten fungerar. Ett program kallat “Serial Monitor” följer med Arduinos mjukvara vilket användes i kommunikationstesterna. Programmet skriver ut all inkommande och utgående trafik från serieporten. Programmet är användbart i testsyfte då man kan se all kommunikation som skickas mellan Arduinon och övervakningsenheten samt att det även går att kommunicera med Arduinon via en PC.
10.1 Test av RS-232
Genom webbgränssnittet har man, som tidigare nämnts, möjlighet att ändra inställningar hos målsystemet. En av inställningarna styr formatet på temperaturvärdena som Arduinon kontinuerligt ger ifrån sig. Formatet kan antingen avges i Fahrenheit eller i Celsius vilket är ett sätt att se att inställningarna verkligen utförs på Arduinon. För att testa att flera inställningar kan ställas in samtidigt så finns där tre inställningar till som styr var sin LED- lampa. LED-lamporna kan antingen slås på eller av vilket är ett annat sätt att ge feedback under testerna för att visa att inställningarna fungerar. Ändringar av inställningarna fungerar på så sätt att kodord skickas via seriekommunikationen från övervakningsenheten till Arduinon. För att verifiera att rätt kodord skickas eller att informationen kommer fram intakt så övervakades samtidigt kommunikationen genom Serial Monitor, vilket är ett program som följer med Arduino som skriver ut all inkommande och utgående trafik från serieporten. Genom testerna visade sig systemet ha ett antal buggar eller brister. Följande brister hittades och korrigerades under testerna:
Genom serieporten tas varje tecken emot ett och ett vilket innebär att kodorden måste sättas ihop till hela kodord. Detta var i början ett problem då det var oklart hur det skulle göras.
För många kodord skickades för snabbt från övervakningsenheten till Arduinon vilket gjorde att serieportens buffert blev överfull vilket resulterade i att alla kodord inte kunde tas emot.