Jämförelse av off-the-shelf-hårdvara för realtidsapplikationer

Institutionen för systemteknik

Department of Electrical Engineering

Examensarbete

Jämförelse av o

ff-the-shelf-hårdvara för

realtidsapplikationer

Examensarbete utfört i Elektroniksystem vid Tekniska högskolan vid Linköpings universitet

av

Christoffer Ring och Hampus Engström LiTH-ISY-EX-ET--13/0409--SE

Linköping 2013

Department of Electrical Engineering Linköpings tekniska högskola

Linköpings universitet Linköpings universitet

Jämförelse av o

ff-the-shelf-hårdvara för

realtidsapplikationer

Examensarbete utfört i Elektroniksystem

vid Tekniska högskolan vid Linköpings universitet

av

Christoffer Ring och Hampus Engström LiTH-ISY-EX-ET--13/0409--SE

Handledare: Kent Palmkvist

isy_{, Linköpings universitet}

Daniel Sjöö

Etteplan

Examinator: Kent Palmkvist

isy, Linköpings universitet

Avdelning, Institution Division, Department

Avdelningen för Elektroniksystem Department of Electrical Engineering SE-581 83 Linköping Datum Date 2013-09-06 Språk Language Engelska/English Svenska/Swedish   Rapporttyp Report category Licentiatavhandling Examensarbete C-uppsats D-uppsats Övrig rapport  

URL för elektronisk version

http://www.ep.liu.se

ISBN — ISRN

LiTH-ISY-EX-ET--13/0409--SE

Serietitel och serienummer Title of series, numbering

ISSN —

Titel Title

Jämförelse av off-the-shelf-hårdvara för realtidsapplikationer Comparison of off-the-shelf hardware for real-time applications

Författare Author

Christoffer Ring och Hampus Engström

Sammanfattning Abstract

Vid implementering av realtidsapplikationer krävs det att man kan använda hårdvaran på ett deterministiskt vis. En realtidsapplikation ställer stora krav på körtider och hur appli-kationen schemaläggs. Det är därför av största vikt att kontrollera om de uppfyller dessa krav. I detta examensarbete har tre system för realtidsapplikationer jämförts och en analys av framförallt sina beräkningsförmågor och hur pass deterministiskt de uppför sig gällande körtider har gjorts. Även andra aspekter så som utvecklingsmiljöer för mjukvara, tillbehör och effektförbrukning har jämförts.

When implementing real-time applications it is required that the hardware can be used in a deterministic way. Real-time applications sets high demands on execution times and how it is scheduled. It is therefore of most importance to verify that these demands can be fulfilled. In this bachelor thesis three systems for real-time applications have been compared and an analysis of chiefly their computer performance and how deterministic they behave in terms of execution times have been made. Also other aspects as development environments for software, accessories and power consumption have been compared.

Nyckelord

Sammanfattning

Vid implementering av realtidsapplikationer krävs det att man kan använda hård-varan på ett deterministiskt vis. En realtidsapplikation ställer stora krav på kör-tider och hur applikationen schemaläggs. Det är därför av största vikt att kon-trollera om de uppfyller dessa krav. I detta examensarbete har tre system för realtidsapplikationer jämförts och en analys av framförallt sina beräkningsför-mågor och hur pass deterministiskt de uppför sig gällande körtider har gjorts. Även andra aspekter så som utvecklingsmiljöer för mjukvara, tillbehör och effekt-förbrukning har jämförts.

Abstract

When implementing real-time applications it is required that the hardware can be used in a deterministic way. Real-time applications sets high demands on exe-cution times and how it is scheduled. It is therefore of most importance to verify that these demands can be fulfilled. In this bachelor thesis three systems for real-time applications have been compared and an analysis of chiefly their computer performance and how deterministic they behave in terms of execution times have been made. Also other aspects as development environments for software, acces-sories and power consumption have been compared.

Tack

Ett stort tack till Etteplan i Linköping för möjligheten att utföra detta examens-arbete. Vi vill speciellt tacka vår handledare Daniel Sjöö för all hjälp samt Eri-ca Dahlberg för all stöttning under arbetets gång. Tack till vår examinator Kent Palmkvist för handledning.

Linköping, Juni 2013 Christoffer Ring och Hampus Engström

Innehåll

Figurer x Notation xiii 1 Inledning 1 1.1 Företagsbeskrivning . . . 1 1.2 Bakgrund . . . 1 1.3 Syfte . . . 1 1.4 Metod . . . 2 1.5 Disposition . . . 2 2 Hårdvara 3 2.1 Altera DE0 . . . 3 2.2 Arduino Uno . . . 4 2.3 Raspberry Pi . . . 5 3 Mjukvara 7 3.1 Altera DE0 . . . 7

3.1.1 Quartus II Web Edition & ModelSim-Altera . . . 7

3.2 Arduino Uno . . . 8 3.2.1 Arduino IDE . . . 8 3.2.2 Atmel Studio 6 . . . 8 3.3 Raspberry Pi . . . 8 3.3.1 Operativsystem . . . 9 4 Teori 11 4.1 Realtidsapplikationer . . . 11 4.2 DSP . . . 11 4.2.1 Digitala filter . . . 12

4.3 Exempelapplikation: FIR-filter på ljudström . . . 12

4.4 Exempelapplikation: Kantdetektering . . . 13

4.4.1 Sobeloperator . . . 13

5 Analys 15

5.1 Responstid . . . 15

5.1.1 Testuppställning . . . 15

5.1.2 Resultat . . . 16

5.2 Förmåga att parallellt utföra uppgifter . . . 17

5.2.1 Altera DE0 . . . 17 5.2.2 Arduino Uno . . . 17 5.2.3 Raspberry Pi Raspbian . . . 17 5.2.4 Raspberry Pi Xenomai . . . 17 5.3 Effektförbrukning . . . 18 5.4 Kantdetektering . . . 19 5.4.1 Testuppställning . . . 19 5.4.2 Resultat . . . 20 5.5 FIR-filter . . . 21 5.5.1 Funktionsbeskrivning . . . 21 5.5.2 Resultat . . . 22 6 Slutsats 25 6.1 Altera DE0 . . . 25 6.2 Arduino Uno . . . 25 6.3 Raspberry Pi . . . 25

A Mätvärden responstid Altera DE0 29 B Xenomai latenstest 31 Litteraturförteckning 33

Figurer

2.1 Altera DE0 . . . 3 2.2 Arduino Uno . . . 4 2.3 Raspberry Pi . . . 5

4.1 Före och efter sobeloperatorn[11] . . . 13

5.1 Raspberry Pi histogram över responstider . . . 16

5.2 Illustration av FIFO-minnet . . . 19

5.3 Flödeschema för kantdetektering . . . 19

FIGURER xi

5.4 Testbänk för kantdetektering . . . 20

5.5 Testbänk för FIR-filtret . . . 22

A.1 Fördröjning mätkablar . . . 29

A.2 Fördröjning OR-grind . . . 30

Notation

Förkortningar

Förkortning Betydelse

IDE Integrated Development Environment ICSP In Circuit Serial Programmer

GPIO General Purpose Input/Output

EEPROM Electrically Erasable Programmable Read-Only Memo-ry

USB Universal Serial Bus

RISC Reduced Instruction Set Computer RAM Random Access Memory

SoC System on Chip

PWM Pulse Width Modulation CPU Central Processing Unit GPU Graphics Processing Unit ADC Analog Digital Converter DAC Digital Analog Converter

PLL Phase Locked Loop IP-block Intellectual Property block

FIFO First In First Out FIR Finite Impulse Response IIR Infinite Impulse Response FPGA Field-Programmable Gate Array WCET Worst-case execution time

DSP Digital signal processing

1

Inledning

I detta kapitel ges en kortare beskrivning utav företaget, bakgrund och syfte med arbetet samt rapportens disposition.

1.1

Företagsbeskrivning

Arbetet har utförts på Etteplan i Linköping. Etteplan är ursprungligen ett finskt konsultbolag som idag har kontor i Sverige, Kina, Nederländerna och Finland. I Sverige finns 14 av deras 39 kontor. Deras kompetensområden är huvudsakligen inom utveckling av elektronik och inbyggda system, automation och elkonstruk-tion, mekanikkonstruktion och teknikinformationstjänster[8].

1.2

Bakgrund

Vid utveckling av prototyper eller system som ska tillverkas i ett fåtal exemplar vill man fokusera på att implementera applikationen och minimera den tid som krävs för hårdvaruutveckling. Därför är det av intresse att använda sig utav off-the-shelf-hårdvara som gör det möjligt att hoppa över utvecklingssteg som design och tillverkning av kort och snabbare komma igång med själva implementering-en.

1.3

Syfte

Syftet med arbetet är att undersöka och jämföra tre olika systems förmåga att lösa realtidsuppgifter. Systemen ska jämföras generellt i form av dess olika para-metrar så som responstid och energiförbrukning. Dessutom ska deras prestanda

2 1 Inledning

jämföras genom att låta dem lösa givna problem och därefter utvärdera deras prestation.

1.4

Metod

Arbetet bestod i början till stor del av efterforskning om tillgängliga system, re-altidssystem och olika exempelapplikationer. När hårdvara och exempelapplika-tioner var valda gick mycket tid till implementeringen av dessa på de olika sy-stemen. Avslutningsvis har arbetet bestått av mätningar, analys och rapportskriv-ning.

1.5

Disposition

Rapporten är uppdelad i sex kapitel där det första är ett inledande kapitel som beskriver arbetet. I kapitel två behandlas den hårdvara som använts i arbetet följt av kapitel tre som går igenom mjukvaran och utvecklingsmiljöer. Teorin om re-altidsapplikationer och de exempelapplikationer som implementerats behandlas i kapitel fyra. Kapitel fem jämför de olika systemen och kapitel sex innehåller avslutande kommentarer.

2

Hårdvara

Detta kapitel beskriver de tre utvecklingskort som har utvärderats. Vid valet av hårdvara har vi fokuserat på att välja system som är vanligt förekommande vid re-altidsapplikationer men som också skiljer sig markant i form av arkitektur. Detta ledde till att valet föll på ett enklare mikrokontrollerbaserat system, en enkorts-dator samt ett FPGA-baserat system. Dessa system skiljer sig på många punkter och täcker ett stort spann av användningsområden.

2.1

Altera DE0

Figur 2.1:Altera DE0

4 2 Hårdvara

Altera DE0 är ett utvecklingskort för FPGA:n Cyclone III EP3C16F484C6. FP-GA:n har 15408 logikelement, 516096 bitar RAM, 4 PLLs och 346 GPIO-pinnar. På kortet finns en USB-blaster för programmering, 24 och 50 MHz klocka, 8 MB SDRAM och 4 MB flash-minne. För extern anslutning finns en 4 bitars VGA-DAC, PS2-kontakt, SD-kortläsare och 72 GPIO-pinnar. Det finns även brytare, lysdio-der och knappar på kortet.

2.2

Arduino Uno

Figur 2.2:Arduino Uno

Arduino Uno är en utvecklingsplattform byggd med öppen hårdvara kring en AT-mega328 mikrokontroller. På kortet finns en USB-seriell adapter, spänningsregu-lator och en 16 MHz klocka till mikrokontrollern. Mikrokontrollern bygger på en 8-bitars RISC-arkitektur med 2 kB SRAM, 1 kB EEPROM och 32 kB programmin-ne. Utåt finns det 20 GPIO-pinnar varav sex kan användas som PWM-utgångar och sex som ingångar till den interna 10-bitars ADC:n. Programmeringen sker genom USB-seriell adaptern, som i sin tur är konstruerad av en ATmega 16U2, vilket gör att mikrokontrollern måste vara laddad med en bootloader som väntar ny programkod vid reset. Det finns även headers för extern ICSP-programmerare på kortet.

Till Arduino Uno finns det även en mängd expansionskort att köpa kallade “shi-elds”. Dessa staplas på Arduinon och ansluter i de stiftlister som finns på kortet och tillverkas både av Arduino som officella tillbehör och av tredjepart. Exem-pel på expansionskort kan vara nätverkskort, WiFi-kort, motordrivare eller GSM-kort.

2.3 Raspberry Pi 5

2.3

Raspberry Pi

Figur 2.3:Raspberry Pi

Raspberry Pi är en enkortsdator utvecklad av den brittiska organisationen Rasp-berry Pi Foundation. Datorn bygger på Broadcoms BCM2835 SoC och inkluderar en ARM-processor på 700 MHz samt en GPU. På kortet finns 512 MB RAM till-gängligt vilket ska delas mellan CPU och GPU. Datorn är bland annat utrustad med 17 GPIO-pinnar, 2 USB-portar, HDMI-utgång, 3,5 mm audio-utgång, RCA-utgång samt SD-kortläsare.

3

Mjukvara

3.1

Altera DE0

För att beskriva funktionen som ska realiseras av FPGA:n används HDL-kod som sedan syntetiseras till grindnivå. Beskrivningen av detta grindnät kan sedan brän-nas över till FPGA:n som realiserar funktionen. FPGA:n förlorar sitt grindnät vid strömbortfall men beskrivningen kan lagras på ett flash-minne ur vilket FPGA:n konfigureras vid varje uppstart.

3.1.1

Quartus II Web Edition & ModelSim-Altera

Quartus II Web Edition är en gratisvariant av Alteras Quartus II som är något be-gränsad till vilka FPGA:er som stödjs och hur fort kompileringen sker[5]. Quar-tus har använts som IDE för att skriva VHDL-koden, skapa blockscheman där modulerna kopplas ihop, syntetisera designen och programmera FPGA:n. För att simulera de olika blockens beteenden har Altera använts. Modelsim-Altera är ett simuleringsverktyg från Modelsim-Altera där insignalssekvenser till blocken kan beskrivas och utsignaler genereras och visas i diagramform. Simulering av designen underlättar vid felsökning och verifiering av blockens funktion. Quar-tus kan även göra tidsanalys på designen och beräkna den maximala klockfre-kvensen.

Quartus kommer också med verktyget Qsys som används för att sammankoppla färdiga IP-block [4]. Det finns både kommersiella och gratis IP-block som reali-serar allt från PLL:er till kompletta processorer. Altera erbjuder också sin egna konfigurerbara processor Nios II som i Qsys kan sammankopplas med andra IP-block så som minneskontroller för att skapa ett komplett SoC[3]. Denna utveck-lingsmetodik har dock inte använts i detta projekt.

8 3 Mjukvara

3.2

Arduino Uno

Arduino Uno bygger på en AVR mikrokontroller och programmeras vanligtvis i assembler, C eller C++. Det finns öppenkällkods-varianter av både program-merare (avrdude) och kompilatorer (AVR GCC) portade till Windows, OS X och Linux.

3.2.1

Arduino IDE

Arduino Uno kommer med ett eget IDE som slår samman editor, kompilator och programmerare till ett enkelt program. IDE:n är skriven i java och fungerar på Windows, OS X och Linux. Arduino IDE försöker göra utvecklingen möjlig för de som inte har en bakgrund inom elektronik eller mjukvara och har därför förenk-lat en del steg av processen. Exempelvis sköts kompilering och programmering av mikrokontrollern med ett enda knapptryck. Ett Arduinoprogram kallas en sketch och skiljer sig något från vanlig C++ då det inte har en funktion main() utan istället måste ha de två funktionerna setup() och loop(). I funktionen setup()skall kod som endast behöver köras en gång placeras och resten pla-ceras i loop() som kommer att köras oändligt. Arduinos IDE inkluderar ock-så automatiskt ett omfattande bibliotek kallat wiring med färdiga funktioner för kontroll av GPIO-pinnar, seriell kommunikation, AD-omvandling, PWM, av-brott med mera. Det följer också med mängder av bibliotek för extrautrustning så som displayer, nätverkskontroller, stegmotorer och sensorer. Detta tillsammans med Arduinos enorma community gör att det är väldigt enkelt att fort realisera ganska avancerade projekt även för hobbyanvändare.

Det bör nämnas att de bibliotek som medföljer Arduinon fokuserar på enkelhet och läsbarhet i koden och många funktioner tar avsevärt många fler instruktio-ner än en klassisk C-implementering. Om effektivitet efterfrågas bör den under-liggande källkoden undersökas innan dessa funktioner används.

3.2.2

Atmel Studio 6

Atmel tillhandahåller också sitt egna IDE Atmel Studio 6 som stödjer alla deras AVR- och ARM-processorer. Eftersom Arduinon använder sig utav seriellporten för programmering måste avrdude installeras och konfigureras i Atmel Studio men det fungerar också att använda sig utav andra programmerare.

3.3

Raspberry Pi

Raspberry Pi Foundation tillhandahåller fyra olika operativsystem som färdiga skivavbildningar. De fyra operativsystem som erbjuds är Debian Wheezy (Rasp-bian), RISC OS, Pidora och Arch Linux ARM. Dessa är kompilerade, optimerade och inkluderar de drivrutiner som behövs för Raspberry Pi. Det går också att använda andra operativsystem förutsatt att de kan kompileras för Raspberryns ARM-processor. Raspberryn måste ha ett SD-kort att starta från men kan därefter konfigureras att ladda operativsystemet från USB eller nätverk.

3.3 Raspberry Pi 9

WiringPi

WiringPi är ett bibliotek som är till för att underlätta åtkomsten till GPIO-pinnar på Raspberryn. Biblioteket är inspirerat av Arduinons motsvarighet wiring och detta är något som tydligt syns på de funktioner som finns att tillgå.

3.3.1

Operativsystem

Av de fyra operativsystemen som Raspberry Pi Foundation erbjuder så bygger tre av dessa på Linux. RISC OS bygger dock inte på Linux utan utvecklades speciellt för ARM-chipset och den första versionen släpptes 1987 [1]. Det finns även en mängd olika typer av operativsystem som är lämpliga om Raspberryn är tänkt att användas som mediacenter, detta är dock inget vi är intresserade av i detta arbete. Raspberry Pi Foundation rekommenderar att man använder Raspbian och framförallt därför så är det den distribution som använts.

Raspbian

Raspbian är en version utav Debian Wheezy som är kompilerad och optime-rad för Raspberryns specifika ARM-processor. Raspbian tillhandahåller också en mängd färdigkompilerade paket och program för enkel installation via den in-byggda pakethanteraren[10].

Xenomai

Xenomai är en realtidspatch som körs tillsammans med Linuxkärnan i ett opera-tivsystem. Med hjälp av denna patch kan man utveckla och köra applikationer med realtidskrav. Xenomai körs nämligen parallellt med Linux-kärnan och kan konfigureras för att ta hand om schemaläggning och avbrott innan Linux-kärnan får chansen att göra det. Xenomai är helt klart en intressant kandidat när det gäl-ler att köra realtidsapplikationer på Raspberryn, och en del tester gjordes med denna patch installerad på Raspbian.

4

Teori

4.1

Realtidsapplikationer

En realtidsapplikation är en applikation som har en viss maximal tid på sig att utföra den uppgift applikationen är skapad för att göra och skulle denna tiden överskridas så är risken stor att resultatet ej längre är användbart. Ofta benämns WCET i dessa sammanhang vilket betyder worst case execution time. Om en ap-plikation passerar sin WCET kan det leda till oönskade konsekvenser, beroende på vad det är för typ av applikation så kan konsekvenserna förstås vara olika mycket förödande, jämför en pacemaker med en live-ström av en fotbollsmatch. Med tanke på detta finns det olika grader av krav på realtidssystem och de delas vanligen upp i tre olika grupper. Det finns mjuka krav, där en överskriden WCET då och då kan vara acceptabel utan att resultatet blir förstört. Fasta krav inne-bär att en överskriden WCET fortfarande kan vara acceptabel då och då men att resultatet däremot blir oanvändbart. Den sista gruppen av realtidskrav brukar benämnas som hårda realtidskrav vilket däremot innebär att hela systemet blir oanvändbart vid en överskriden WCET[9].

4.2

DSP

DSP kan översättas till digital signalbehandling och är ett begrepp som används vid analys och behandling av digitala signaler. Typiskt användande av DSP är då en analog signal ska läsas in till ett system för att digitaliseras och behandlas och sedan matas ut som en analog signal igen. Tiden från att en signal matas in i ett system till att den matas ut är begränsad, överskrids den begränsade tiden så är utsignalen inte användbar. Det är detta som gör DSP till ett realtidsproblem, ett mycket vanligt sådant.

12 4 Teori

4.2.1

Digitala filter

Digitala filter är en viktig och stor del av DSP. Digitala filter använder matematis-ka operationer för att justera en tidsdiskret signals egensmatematis-kaper. Med ett filter matematis-kan oönskade frekvenser på en signal tas bort, ofta handlar det om att filtrera bort brus. Ett digitalt filter är i många hänseenden överlägsen sin analoga motsvarig-het [14]. Digitala filter delas vanligtvis in i två grupper, IIR- och FIR-filter.

IIR

IIR-filter är rekursiva, tidigare utsignaler används för att beräkna den aktuella utsignalen och har därför ett oändligt långt impulssvar. Funktionen nedan visar hur utsignalen från ett IIR-filter kan beräknas, filtrets ordning fås av N, c och d är koefficienter, x insignal och y utsignal.

y(n) = N X m=0 cm· x(n − m) + N X m=0 dm· y(n − m) (4.1) FIR

Ett FIR-filter innebär att filtrets impulssvar konvergerar mot noll. FIR-filter är ej rekursiva, vilket innebär att de inte har någon återkoppling. Detta medför så-ledes att FIR-filter alltid är stabila vilket är en önskvärd egenskap. Funktionen nedan visar hur utsignalen från ett filter beräknas, filtrets ordning fås av N, b är koefficient och x är insignal.

y(n) =

N

X

m=0

bm· x(n − m) (4.2)

Att designa FIR-filter är en lättare uppgift jämfört med att designa IIR-filter, dock kräver oftast ett FIR-filter en högre ordning än ett motsvarande IIR-filter. I detta arbete kommer FIR-filter att implementeras framförallt på grund av att det är det mest vanligt förekommande filtret [7].

4.3

Exempelapplikation: FIR-filter på ljudström

Genom att låta en ljudström passera ett FIR-filter kan man på ett ganska effekt-fullt sätt visa funktionen av filtret. Enligt funktion 4.2 behöver en koefficient-vektor beräknas för att kunna implementera ett FIR-filter, denna koefficient-vektor beräk-nas fram vid designen av filtret. Vid design av ett filter tas ett önskat frekvens-svar fram där man definierar passband, stoppband, passbandsrippel och stopp-bandsattenuering. När frekvenssvaret tagits fram kan koefficienterna fås fram genom att ta den inversa Fouriertransformen på frekvenssvaret. Alternativt finns en mängd olika programvaror för att designa filter och beräkna dess koefficienter.

4.4 Exempelapplikation: Kantdetektering 13

4.4

Exempelapplikation: Kantdetektering

Kantdetektering utav en bild eller videoström identifierar punkter i bilden där in-tensiteten kraftigt förändras i jämförelse med närliggande punkter. Eftersom en förändring av intensitet ofta motsvaras av en förändring i scenen som t ex djup, material eller belysning så är kantdetektering ett viktigt steg i många datorseen-deapplikationer där information ska extraheras ur bilder. Kantdetektering kan också användas för att öka kontrasten i bilder. De flesta metoderna för kantde-tektering använder sig utav längden av gradientvektorn. Om bildens intensitet beskrivs av den tvådimensionella funktionen:

f (x, y) (4.3)

Så kan gradienten beskrivas med partiell derivering: 5_{f = (}∂f

∂x, ∂f

∂y) (4.4)

Längden kan sedan tas fram med Pythagoras sats: |5_{f | =} s ∂f ∂x !2 + ∂f ∂y !2 (4.5) Eftersom bilden endast är beskriven i diskreta punkter måste en approximation av derivatan användas. En vanlig metod är att använda en central differansopera-tor:

∂f ∂x ≈

f (x + 1) − f (x − 1)

2 (4.6)

Vanligtvis appliceras också ett filter i förväg för att undvika att identifiera kanter som beror på brus i bilden.

4.4.1

Sobeloperator

Figur 4.1:Före och efter sobeloperatorn[11]

Sobeloperatorn är en klassisk metod för att ta fram kanter i bilder och bygger på ett linjärt filter över tre pixlar kombinerat med partiell derivering i x- och

y-14 4 Teori

led. Sobeloperatorn fungerar genom att falta bilden med två matriser Gx och Gy. Därefter beräknas gradientens längd med Pythagoras sats[12].

Gx =         −_{1 0 1} −_{2 0 2} −_{1 0 1}         (4.7) Gy =         1 2 1 0 0 0 −₁ −₂ −₁         (4.8) G = q Gx2_{+ Gy}2 _(4.9)

Eftersom kvadratroten är en relativt tung beräkning brukar denna approximeras med absolutbelopp: G = |Gx| + Gy    (4.10)

5

Analys

5.1

Responstid

Att snabbt kunna svara på externa händelser är ett vanligt kriterium för real-tidsapplikationer, därför är det intressant att jämföra de olika systemens förmå-ga att göra detta. I detta arbete har vi definierat responstiden som fördröjningen från en insignal till att en utsignal kan ställas ut. Detta testades genom att låta varje system pulsa en GPIO-pinne så fort som möjligt efter att det detekterats en positiv flank på en annan GPIO-pinne. För fasta och mjuka realtidskrav är det relevant att jämföra den tid det tar att svara på majoriteten av insignalerna. I detta fall har vi valt att jämföra tiden då 95 % av insignalerna blivit behandlade. För hårda realtidskrav är den maximala responstiden avgörande för systemets prestanda.

5.1.1

Testuppställning

Alla systemen konfigurerades för att så snabbt som möjligt reagera på en positiv flank på en GPIO-pinne genom att pulsa en annan GPIO-pinne. På Arduinon och Raspberryn användes avbrott för detta och på FPGA:n användes en enkel D-vippa. Tiderna för Arduinon och Raspberryn mättes med en logikanalysator som samplade i 16 MSa/s och FPGA:n mättes med ett 100 MSa/s oscilloskop på grund av de väldigt korta tiderna.

Avbrottsrutinen för Raspberryn och Arduinon fungerade enligt följande (pseudo-kod): isr(){ output_GPIO = 1; output_GPIO = 0; } 15

16 5 Analys

5.1.2

Resultat

Figur 5.1:Raspberry Pi histogram över responstider

System Mätvärden Min Median 95% Max

Altera DE0 - 0,01 us - - 0.03 us

Arduino Uno 62000 st 1,39 us 1,44 us 1,50 us 1,56 us RPi WiringPi 615000 st 25 us 68 us 229 us 903 us

Tabell 5.1:Responstider

Altera DE0

Eftersom responstiderna för FPGA:n var så korta krävdes det högre upplösning än vad logikanalysatorn gav. Istället användes ett oscilloskop och därför fanns det inte möjlighet att erhålla värden för median, 95 % och antal mätvärden. Re-sponstiden för FPGA:n har en väldigt liten spridning som beror på att D-vippan klockades i 50 MHz. Den minsta fördröjningen på 10 ns berodde på fördröjning-ar i mätkablfördröjning-arna (se mätning i appendix A.1). Det är inga problem att gfördröjning-arantera varken mjuka, fasta eller hårda realtidskrav.

Arduino Uno

Arduinon har mycket bättre responstid på grund av avsaknaden utav operativsy-stem och svarar efter ca 1,5 us. Spridningen på 0,2 us motsvarar tre klockcykler och beror på noggrannheten hos logikanalysatorn samt att den instruktion som pågår får köra klart innan avbrottet behandlas. Denna lämpar sig därför för fasta, mjuka och hårda realtidskrav där en responstid ner till 1,5 us krävs.

Raspberry Pi WiringPi

Responstiden skiljer sig väldigt mellan min och max (0,88 ms i spridning) på grund av operativsystemets schemaläggare. Den övre gränsen kan inte heller ga-ranteras eftersom operativsystemets kärna alltid kommer att köras med förtur. Fördelningen kan ses i histogrammet i figur 5.1. Majoriteten av avbrotten (95 %) hanteras inom 229 us men den långa maxtiden gör att man riskerar att missa

5.2 Förmåga att parallellt utföra uppgifter 17

flera avbrott i följd om responstiden som krävs är i närheten av detta. Denna lös-ning rekommenderas därför enbart för fasta och mjuka realtidsapplikationer där kravet på responstid är över en millisekund.

5.2

Förmåga att parallellt utföra uppgifter

Ofta kan man dela upp en applikation i delar som har realtidskrav angivna samt delar som inte är tidskritiska. Därför är det intressant att jämföra de olika syste-mens förmåga att utföra dessa uppgifter parallellt.

5.2.1

Altera DE0

FPGA:n kan konfigureras så att varje uppgift har separat hårdvara och därför är det inga problem att parallellt utföra olika uppgifter.

5.2.2

Arduino Uno

På Arduinon kan man schemalägga uppgifter med hjälp av timeravbrott och på så sätt få det att utföras repetitivt med väldigt hög noggrannhet. Eftersom avbrot-ten körs oavsett vad huvudprogrammet gör lämpar det sig att lägga tidskritiska saker i dessa avbrott och låta de andra uppgifterna skötas i huvudprogrammet. Eftersom Atmega328:an inte erbjuder möjligheten att ändra avbrottens prioritet samt att avbrotten inte kan avbrytas av andra avbrott [13] får man vara försiktig om flera tidskritiska uppgifter ska utföras i olika takter.

5.2.3

Raspberry Pi Raspbian

Raspian saknar funktioner för att på ett säkert sätt utföra tidskritiska uppgifter vilket gör det olämpligt till hårda realtidsuppgifter. Om periodtiden är tillräck-ligt stor kan vissa mjuka och fasta realtidsuppgifter utföras och med hjälp av Raspbians förmåga att prioritera olika processer i olika nivåer kan tidskritiska samt icke-tidskritiska applikationer köras parallellt.

5.2.4

Raspberry Pi Xenomai

Xenomai har förmågan att schemalägga uppgifter vid sidan av Linuxkärnan vil-ket gör att även hårda realtidsuppgifter kan lösas samtidigt som mindre priorite-rade applikationer körs i Linux. Xenomai har inbyggda tester för att mäta laten-ser för periodiskt schemalagda användarapplikationer (se appendix B) för vilket resultatet redovisas i tabell 5.2 nedan.

Min Medel Max

Latens obelastat 3,132 us 8,36 us 42,42 us Latens belastat 3,676 us 25,64 us 66,93 us

18 5 Analys

Även om dessa tider inte är direkt jämförbara med responstiden för externa av-brott som redovisas i tabell 5.1 visar den på hur pass förutsägbart systemet blir med realtidsoperativsystem. Anledningen till att det skiljer sig mellan obelastat och belastat system tros vara att Xenomai:s underliggande system och Linuxkär-nan delar IRQ-signaler. För att lösa realtidsuppgifter med hårda krav bör alltså extra mycket noggrannhet läggas på konfigurationen utav systemet.

5.3

Effektförbrukning

Ofta vill man implementera realtidsapplikationer i inbyggda system som kan dri-vas på batterier. I dessa fall är det mycket viktigt att hålla effektförbrukningen så låg som möjligt. I detta avsnitt visas mätningar på effektförbrukningen på de tre systemen. Raspberryn och Arduinon har mätts upp i vila samt vid full belastning. Altera DE0 mättes förutom i vila även med exempelapplikationerna körandes, an-ledningen till att inte kortets effektförbrukning mättes vid full belastning beror på svårigheten att belasta en FPGA till 100 %. Alla mätningar är gjorda på syste-men utan externa komponenter inkopplade när de drivs på 5 V från en USB-port.

Altera DE0

FPGA-kortets effektförbrukning utvärderades vid körning av de två exempelap-plikationerna som implementerats. Enligt tabell 5.3 ökar förbrukningen med cir-ka 10 % vid körning av cir-kantdetektering. Effektförbrukningen är direkt beroende av applikationens storlek och därför var full belastning svårt att bestämma. Till exempel använder kantdetektering tillsammans med testbänken enbart 2 % av FPGA:ns logikelement.

Arduino Uno

Arduinon förbrukar klart minst effekt, enligt tabell 5.3 är Arduinons förbruk-ning cirka 10 gånger lägre än Raspberryns och tre gånger lägre än FPGA-kortet. Beroende på belastning varierar förbrukningen upp mot 50 %. Mätningen på Ar-duinon obelastad gjordes genom att sätta mikrokontrollern i sleep-mode vilket den kan konfigureras att vakna upp från genom timer-avbrott.

Raspberry Pi

Tabellen 5.3 visar att beroende på hur pass belastat systemet är så pendlar effekt-förbrukningen upp mot 20 % och ligger som mest på cirka 2 Watt.

Raspberry Pi Arduino Uno Altera DE0

Obelastad 1,65 W 150 mW 575 mW

FIR-filter - - 600 mW

Kantdetektering - - 635 mW

Full belastning 1,90 W 223 mW -Tabell 5.3:Effektförbrukning av de olika systemen

5.4 Kantdetektering 19

5.4

Kantdetektering

För att implementera kantdetektering av en videoström på de olika systemen användes sobeloperatorn tillsammans med ett FIFO-minne. Implementeringen har inte på något sätt som mål att vara effektiv utan försöker vara så lik som möjligt på alla systemen. Eftersom sobeloperatorn använder sig utav alla pixlar som angränsar till den pixel som behandlas behöver FIFO-minnet var stort nog att hålla minst två rader och tre pixlar för att undvika att behöva läsa in samma pixel flera gånger. Videon som behandlades valdes till att vara 320x240 i 15 fps. Detta resulterade i att systemen skulle behöva behandla 1,152 miljoner pixlar i sekunden för att kunna spela upp videon i realtid och behandlingstiden per pixel fick alltså max vara 869 nanosekunder.

Figur 5.2:Illustration av FIFO-minnet

Figur 5.3:Flödeschema för kantdetektering

5.4.1

Testuppställning

Eftersom Arduinon saknar möjlighet till att både lagra video och visa video på ett smidigt sätt bestämdes det tidigt att FPGA-kortet skulle användas som en testbänk. FPGA:n fick ta hand om lagring utav en videofil på flash-minnet och att rita på skärm genom sin VGA-DAC för alla systemen. Gränssnittet mellan FP-GA:n och det system som skulle testas fick bli två parallelbussar där testsystemet kunde läsa in data ur den ena och skriva till den andra. Eftersom VGA-DAC:en endast har 4-bitars upplösning blir dynamiken i videon som visas något begrän-sad men till beräkningarna valdes ändå 8-bitars pixlar att användas för att få ett

20 5 Analys

mer realistiskt testsystem. Videofilen lagrades okomprimerad i flash-minnet för att kunna behandla videon pixel för pixel, vilket var ett krav då Arduinon hade så begränsad mängd RAM att dekomprimering hade varit svårt. För enkelhets skull kopplades inte Raspberryn till testbänken utan läste och skrev till filer lokalt på SD-kortet istället. Detta eftersom parallellbussen hade problem med störningar i högre hastigheter och GPIO-pinnarna ändå var mappade till filsystemet i Rasp-bian och därför gav en liknande fördröjning.

Figur 5.4:Testbänk för kantdetektering

5.4.2

Resultat

System Tid per pixel Altera DE0 7,63 ns Raspberry Pi 939 ns Arduino Uno 139 us

Tabell 5.4:Behandlingstid per pixel efter initiering

System 160x120 320x240 640x480 1280x720 1920x1080 Altera DE0 35 ms 141 ms 562 ms 1,68 s 3,80 s Arduino Uno 640 s 2562 s 7686 s 30744 s 69175 s Raspberry Pi 4,33 s 17,3 s 69,3 s 207 s 467 s

Tabell 5.5:Beräknad tid att behandla 10 sekunder 24 fps video i olika stan-dardupplösningar

5.5 FIR-filter 21

Altera DE0

Implementeringen av sobeloperatorn på FPGA:n löstes med 211 logikelement, 103 register och 5056 minnesbitar. Detta är under två procent av FPGA:ns logike-lement. Tidsanalys av designen rapporterar en maxfrekvens på 131 MHz och im-plementeringen behandlar en pixel per klockcykel. Att behandla videon i realtid var alltså inga problem med de 1,152 MHz som krävdes. Eftersom flash-minnet i testbänken är begränsat till 11 MB i sekunden blir det den begränsande faktorn men med ett snabbare interface till ett snabbare minne eller genom att skicka komprimerad video skulle FPGA:n kunna behandla även högupplöst video i re-altid.

Arduino Uno

Arduinon körde samma C-kod som Raspberryn för att behandla videon och den enda skillnaden blev i in- och utmatning av data. På grund av den begränsade beräkningskraften tog det hela 139 mikrosekunder per pixel vilket resulterade i att varje bildruta tog över tio sekunder. Dessutom begränsar RAM-minnet som bara är på 2 kB den maximala upplösningen den kan behandla. Arduinon lämpar sig alltså inte för att behandla någon video i realtid.

Raspberry Pi Raspbian

Raspberryn behandlar videon med en hastighet av 1,065 miljoner pixlar i sekun-den vilket innebär att sekun-den var lite för långsam för realtidsbehandling av video-filen med sina 939 nanosekunder per pixel. Det är dock troligt att det går att optimera algoritmen så att den skulle klara det men eftersom systemen skulle jämföras ansågs det viktigare att de körde samma kod.

5.5

FIR-filter

Ett givet filter appliceras på respektive system och dess prestanda utvärderas i denna del av rapporten. Filtret har applicerats på en ljudfil av WAVE-format med en sampelfrekvens på 44100 Hz, en sampelstorlek på 16 bitar och en storlek på 2,7 MB vilket motsvarar en speltid på cirka 31 sekunder. Flertalet filter av olika ordningar, fixpunkt- och flyttalskoefficienter samt både låg- och högpassfilter har testats på systemen. Resultatet som visas här är på ett filter av ordning 22 med 8-bitars fixpunktskoefficienter.

5.5.1

Funktionsbeskrivning

De tre systemen skulle läsa in två stycken 8-bitars ord och slå ihop dessa till en ljudsampel. Ljudsampeln körs sedan genom filtret för att till sist skrivas ut som två stycken 8-bitars ord igen. Tanken med att läsa 2 stycken 8-bitars värden istället för ett 16-bitars var att en databuss på 8-bitar skulle ha implementerats mellan systemen. En 16-bitars databuss var inte möjlig på grund av bristen på GPIO-pinnar på Raspberryn och Arduinon. Eftersom det finns ett snabbt flash-minne på FPGA:n och en implementation av ett PWM-block för att spela upp

22 5 Analys

ljud är en enkel uppgift att applicera på en FPGA så skulle Altera-kortet agera som testbänk för alla systemen. Applikationerna till Raspberry och Arduino är skrivna i C och FPGA:n är konfigurerad i VHDL. Pseudokod för FIR-filter:

sample = read_input();

SAMPLE_BUFFER[SIZE_OF_FILTER - 1] = sample;

output = SAMPLE_BUFFER[0] * FILTER_COEFFICIENTS[0] + ...

+ SAMPLE_BUFFER[SIZE_OF_FILTER - 1] * FILTER_COEFFICIENTS[SIZE_OF_FILTER - 1] for(i = 0; i < SIZE_OF_FILTER - 1; i++)

{

SAMPLE_BUFFER[i] = SAMPLE_BUFFER[i + 1]; }

Figur 5.5:Testbänk för FIR-filtret

5.5.2

Resultat

System Beräkningstid per sampel Beräkningstid WAVE-fil

Altera DE0 62 ns 0,086 s

Arduino Uno 84 us 115 s

Raspberry Pi 6 us (medelvärde) 8 s

Tabell 5.6:Resultat från en körning av ett 22:a ordningens filter

Altera DE0

FPGA:n klarade utan bekymmer att köra filtreringen av WAVE-filen i realtid. Med hjälp av Quartus tidsanalys av designen så erhölls en maxfrekvens på 32 MHz för filtret vilket betyder att hela WAVE-filen skulle hinna filtreras på 0,086

5.5 FIR-filter 23

sekunder. Enligt databladet för flash-minnet som finns på Altera-kortet så kan dock inte data läsas så pass fort, minnet har en åtkomsttid på 90 ns [2], vilket motsvarar en läshastighet på cirka 11 miljoner 8-bitars eller 16-bitars ord per se-kund. För att testa FPGA:n i realtidskörning implementerades ett PWM-block i designen, detta block matades med filtrerade sampels i likvärdig takt som sam-pelfrekvensen av WAVE-filen.

Arduino Uno

Vid körning av applikationen på Arduinon har tiden för att beräkna en utsignal gjorts med hjälp av funktionen micros(). Funktionen micros() är en del av biblioteket wiring och mäter mikrosekunder med en noggrannhet på 4 mikro-sekunder. Tiden för beräkning av en sampel mättes till 84 mikrosekunder vilket skulle innebära att den 31 sekunder långa ljudfilen skulle ta 115 sekunder att filtrera. För att lyckas filtrera ljudfilen i realtid krävs att man väljer en lägre samplingsfrekvens eller möjligen reducerar filterordningen samt optimerar ko-den. Som ett exempel hade ett filter av 4:e ordningen en beräkningstid på mellan 24 och 28 mikrosekunder vilket inte är långt ifrån den maximalt tillåtna tiden 22,7 mikrosekunder vid sampelfrekvensen 44100 Hz.

Raspberry Pi Raspbian

För att visa Raspberryns förmåga att utföra applikationen mättes tiden för att köra hela WAVE-filen genom filtret. Vid testerna lästes sampels från en fil och skrevs sedan till en annan fil. Åtkomst till GPIO-pinnar i Raspbian kan nämligen ske via filer och tider för läsning och skrivning är därför likvärdiga med läsning från GPIO-pinnarna. Tiderna visade sig, som befarat, vara inkonsekventa. Tider-na för en körning varierade typiskt mellan sex och nio sekunder. Vid mätning på behandling av en enskild sampel varierade mättiderna med flera 1000 procent, vilket så klart är ohållbart vid realtidskörning. Vid körning av applikationen på ett belastat system var de uppmätta tiderna ännu värre. Tiderna för läsning av he-la filen kan dock användas för att estimera beräkningskraften på systemet för en jämförelse med de andra systemen. Om ett realtidsoperativsystem istället skulle köras på Raspberryn kan beräkningskraften som erhållits i dessa tester användas som en riktlinje för vad som är möjligt och inte möjligt att göra i realtid.

6

Slutsats

Några ord om systemens prestanda och hur lämpliga de är för att köra realtidsap-plikationer.

6.1

Altera DE0

FPGA:n på detta kort gör det till ett riktigt kraftfullt system som med fördel ska utnyttjas för sin förmåga att köra applikationer parallellt. Att det kan användas för snabba realtidskritiska applikationer har framgått i detta arbete och tack vare FPGA:ns flexibilitet kan den användas inom många områden.

6.2

Arduino Uno

Arduinon är ett utmärkt alternativ för tidskritiska applikationer som inte kräver alltför tunga beräkningar. Med alla expansionskort som finns tillgängliga och den stora community som tillhandahåller exempelapplikationer så är det enkelt för såväl hobbyanvändare som proffs att använda sig utav detta system. Är man på jakt efter ett system som ska drivas på batterier är Arduino Uno ett system som bör övervägas. Utan operativsystem har man också full kontroll över hårdvaran och kan enkelt utföra tidskritiska uppgifter vilket även gör den väl lämpad för realtidsapplikationer med hårda krav.

6.3

Raspberry Pi

En Raspberry med en ren installation av Raspian som operativsystem lämpar sig inte väl för realtidskritiska applikationer. För icke-realtidsuppgifter klarar sig

26 6 Slutsats

Raspberryn bra tack vare sin kraftfulla processor och med hjälp av mer lämpade operativsystem eller realtidspatcher i stil med Xenomai kan Raspberryn använ-das till realtidsapplikationer. Det krävs dock en hel del mer arbete och undersök-ningar för att utvärdera realtidsoperativsystem som kan köras på Raspberry Pi. Dessutom bör Xenomai-patchen som testats till viss del, undersökas mer grund-ligt för att få en klarare bild på realtidsprestandan som kan fås ut av systemet.

A

Mätvärden responstid Altera DE0

Figur A.1:Fördröjning mätkablar

30 A Mätvärden responstid Altera DE0

Figur A.2:Fördröjning OR-grind

B

Xenomai latenstest

Xenomai är kalibrerat att starta alla tasks 9500 ns i förväg. Absoluta tider erhålls alltså genom att addera 9,5 us till alla tider.

Följande tider erhölls då systemet kördes obelastat:

== Sampling period: 1000 us

== Test mode: periodic user-mode task == All results in microseconds warming up...

RTT| 00:00:01 (periodic user-mode task, 1000 us period, priority 99)

RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst RTD| -4.880| -0.672| 14.004| 0| 0| -4.880| 14.004 RTD| -5.612| -0.748| 24.420| 0| 0| -5.612| 24.420 . . . RTD| -5.712| -1.144| 13.848| 0| 0| -6.368| 32.924 RTD| -5.724| -1.048| 25.220| 0| 0| -6.368| 32.924 ---|---|---|---|---|---|---RTS| -6.368| -1.140| 32.924| 0| 0| 00:04:31/00:04:31

Följande tider erhölls då systemet stresstestades samtidigt:

== Sampling period: 1000 us

== Test mode: periodic user-mode task == All results in microseconds warming up...

RTT| 00:00:01 (periodic user-mode task, 1000 us period, priority 99)

RTH|----lat min|----lat avg|----lat max|-overrun|---msw|---lat best|--lat worst RTD| -5.152| -0.396| 12.724| 0| 0| -5.152| 12.724 RTD| -5.204| -0.336| 15.364| 0| 0| -5.204| 15.364 . . . RTD| -5.224| -0.376| 26.760| 0| 0| -5.824| 57.432 RTD| -5.076| -0.184| 24.112| 0| 0| -5.824| 57.432 ---|---|---|---|---|---|---RTS| -5.824| 16.140| 57.432| 0| 0| 00:11:27/00:11:27 31

Litteraturförteckning

[1] Wikipedia. http://en.wikipedia.org/wiki/RISC_OS. Hämtad: 2013-05-30. [2] Spansion. http://www.spansion.com/Support/Datasheets/ s29gl-n_01.pdf, . Hämtad: 2013-05-31. [3] Altera. http://www.altera.com/devices/processor/nios2/ ni2-index.html, . Hämtad: 2013-05-20. [4] Altera. http://www.altera.com/products/software/ quartus-ii/subscription-edition/qsys/qts-qsys.html, . Hämtad: 2013-05-20. [5] Altera. http://www.altera.com/products/software/ quartus-ii/web-edition/qts-we-index.html, . Hämtad: 2013-05-20. [6] Arduino. http://arduino.cc/en/uploads/Main/ArduinoUno_R3_ Front.jpg. Hämtad: 2013-05-14. [7] DSP-guru. http://www.dspguru.com/dsp/faqs/fir/basics. Häm-tad: 2013-05-31. [8] Etteplan. http://www.etteplan.com/about-etteplan.aspx. Häm-tad: 2013-05-14.

[9] TDDD07 Real-time system Lecture 1. http://www.ida.liu.se/~snt/ teaching/REAP/HT12/TDDD07-lecture1.pdf. Hämtad: 2013-05-31. [10] Raspbian. http://www.raspbian.org/. Hämtad: 2013-05-31.

[11] Stockvault. http://www.stockvault.net/photo/123730/ stop-sign-. Hämtad: 2013-05-31.

[12] Wilhelm Burger and Mark Burge. Digital image processing. New York: Springer, first edition, 2008.

34 Litteraturförteckning

[13] Atmel Corporation. Atmega48a/pa/88a/pa/168a/pa/328/p datasheet. 2013.

[14] Steven W. Smith. The scientist and engineer’s guide to digital signal proces-sing, 1997.

Upphovsrätt

Detta dokument hålls tillgängligt på Internet — eller dess framtida ersättare — under 25 år från publiceringsdatum under förutsättning att inga extraordinära omständigheter uppstår.

Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för icke-kommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ art.

Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart.

För ytterligare information om Linköping University Electronic Press se förla-gets hemsida http://www.ep.liu.se/

Copyright

The publishers will keep this document online on the Internet — or its possi-ble replacement — for a period of 25 years from the date of publication barring exceptional circumstances.

The online availability of the document implies a permanent permission for anyone to read, to download, to print out single copies for his/her own use and to use it unchanged for any non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional on the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility.

According to intellectual property law the author has the right to be men-tioned when his/her work is accessed as described above and to be protected against infringement.

For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its www home page: http://www.ep.liu.se/