Plattform för studentprojekt i datortekniksundervisning baserad på Chipkit Uno32

DEGREE PROJECT, IN INFORMATION AND SOFTWARE SYSTEMS , FIRST LEVEL STOCKHOLM, SWEDEN 2015

Plattform för studentprojekt i

datortekniksundervisning baserad på

Chipkit Uno32

Sammanfattning

För laborationer i datortekniksundervisning på KTH används för närvarande Nios II-processorn på utvecklingskortet DE2. Processorn skiljer sig från den MIPS-processor som används i resten av kursen och den tillhörande utvecklingsmiljön är komplicerad. Ett tidigare kandidatexamensarbete har undersökt möjligheten att by-ta ut den nuvarande plattformen mot utvecklingskortet Uno32 från Digilent Chipkit. Planer finns även att utöka kursen till att innefatta ett projektmoment där studen-terna använder plattformen självständigt. I syfte att utvärdera hårdvaruplattformen utvecklas en serie exempelprojekt som även demonstrerar hårdvaran. Under arbetet utvecklas också en fri utvecklingsmiljö som ska vara enkel att installera och använ-da för studenterna. Slutsatserna som dras är att den fria utvecklingsmiljön som tas fram är ett framtidssäkert alternativ som är mer hårdvarunära än Digilent MPIDE, men smidigare än Microchip Mplab X då ingen programmeringsutrustning krävs. Från de utvecklade exempelprojekten dras slutsatsen att hårdvaruplattformen är en möjlig projektplattform för datortekniksundervisning, men att den behöver testas av studenter i undervisningen.

Abstract

Laboratory exercises in the computer hardware engineering course at Royal In-stitute of Technology are currently based around the Nios II processor running on the Altera DE2 development board. The Nios II processor differs from the MIPS processor taught during lecures, and the accompanying development environment is complicated to use. A previous bachelor’s thesis has explored the possibility of replacing the current platform with the Uno32 development board from Digilent Chipkit. Plans also exist to extend the course with more independent project work, where students would use the hardware platform on their own. To evaluate the hard-ware platform, a series of example projects are developed. These projects are also aimed to be used in demonstion of the platform and as a base for the students’ own projects. In the process, a toolchain and development environment based on free software is developed with the goal of being easy to install and use by students. In conclusion, the developed free software toolchain is a future-proof and viable al-ternative to Digilent Chipkit MPIDE and Microchip Mplab X. The free software toolchain is lower level than the MPIDE Arduino environment, but easier to use than Mplab X since extra programming hardware is not needed. The developed ex-ample projects hint that Uno32 is a viable hardware platform for education, but more thorough student testing is required to draw further conclusions.

Innehåll

2.2 Bygga GCC för PIC32 . . . 5

2.3 Användning av startladdare utanför Arduino-miljön . . . 5

3 Hårdvaruplattformen 6 3.1 Processorn . . . 6

3.1.1 Delay slots . . . 6

3.1.2 Avbrottskontrollern . . . 6

3.2 Kringhårdvara . . . 7

3.2.1 Generella in- och utgångar . . . 7

3.2.2 UART-serieport . . . 8 3.2.3 OLED-skärm . . . 8 3.2.4 Styrning av skärmen . . . 8 3.2.5 Adressering av grafikminnet . . . 8 3.2.6 Temperatursensor . . . 8 4 Arbetsgång 11 4.1 Utveckling av utvecklingsmiljön . . . 11 4.2 Verifiering av utvecklingsmiljön . . . 12

4.3 Utvärdering av plattformen med hjälp av testprojekt . . . 12

4.4 Avlusning . . . 13

4.4.1 Avlusning genom inspektion av genererad IHEX-fil . . . 13

4.4.2 Avlusning genom blockerande slinga . . . 13

4.4.3 Avlusning med visuell indikation . . . 14

4.4.4 Avlusning med UART . . . 14

5 Skräddarsydd utvecklingsmiljö 15 5.1 Utvecklingsmiljöns beståndsdelar . . . 15

5.1.1 Utvecklingsmiljöns målkatalog . . . 16

5.1.2 Kompileringsberoenden . . . 16

5.1.3 Automatisk nedladdning av källkod . . . 17

5.1.4 PIC32-specifika C-huvuden, symboler . . . 18

5.1.5 Körstödsbiblioteket crt0 . . . 19 5.1.6 Länkskript . . . 19 5.1.7 Konverterare av binärfilsformat . . . 20 5.1.8 Miljövariabler i utvecklingsmiljön . . . 20 5.1.9 Paketering för distribution . . . 21 5.2 Konfigurationsflaggor för utvecklingsmiljön . . . 22 5.2.1 Gemensamma konfigurationsflaggor . . . 22

5.2.2 Konfiguration för målplattform utan matteprocessor . . . . 22

5.2.3 Konfigurationsflaggor för binutils . . . 23 5.2.4 Konfigurationsflaggor för GCC . . . 23 5.2.5 Konfigurationsflaggor för Avrdude . . . 24 5.3 Projektmall . . . 24 5.3.1 Stubbkod . . . 25 5.3.2 Avbrottsvektorer . . . 25

5.3.3 Kod och data utanför standardareorna . . . 25

5.4 Programmeringsutrustning . . . 26

5.5 Hårdvarubyglar . . . 26

6 Framtagna exempelprojekt 28 6.1 Test av grundläggande in- och utmatning . . . 28

6.2 Test av analog- till digitalkonverteraren . . . 28

6.3 Test av seriekommunikation (UART) . . . 29

6.4 Test av skärm . . . 29

6.4.1 Initiering av skärm . . . 29

6.4.2 Teckensnitt för skärmen . . . 29

6.4.3 Visa rastergrafik på skärmen . . . 31

6.5 Test av avbrottskontroller . . . 31

6.6 Test av temperatursensorn . . . 31

7 Slutsatser 33 7.1 Analys . . . 33

7.1.1 Mjukvarulicenser . . . 33

7.1.2 Hårdvaran som projektplattform . . . 33

7.2 Diskussion . . . 34

7.2.1 Startladdare jämfört med programmeringsutrustning . . . 34

7.2.2 Framtidssäkerhet för programmeringsutrustning . . . 35

7.2.3 Exempelkod tillgänglig för studenter . . . 36

7.3 Konsekvensanalys . . . 37

7.3.1 Objektfiler med symboler för absolutadresserade register . 37 7.3.2 Support . . . 37

7.4 Uppnådda mål . . . 37

8 Framtida arbete 39 8.1 IHEX-visare . . . 39

8.2 Uppgradera Avrdude . . . 39

8.3 Ersätta bin2hex med objcopy . . . 39

8.4 Återskapa processorspecifika symbolobjektfiler . . . 40

8.5 Test av andra målplattformar . . . 40

8.6 Tänkbara tillägg till Uno32 för studentprojekt . . . 40

9 Litteraturförteckning 41

Bilaga A Pic32MX toolchain 44

Figurer

1 Skärmens minneslayout . . . 9 2 Utvecklingsmiljöns ingående komponenter . . . 15 3 Beroendeträd för kompilering av utvecklingsmiljön. Skript och färdig

me-tadata har utelämnats. Pilar pekar på komponenter som måste vara in-stallerade. . . 17

Terminologi

ABI Application Binary Interface; Anropskonvenioner, hur argu-ment och returvärden skickas mellan funktioner.

Arduino Hårdvaruspecifikation och abstraktionslager med egen pro-grammeringsmiljö för hobbyelektronik.

DE2 Utvecklingskort från Altera baserad på Cyclone II.

EEPROM Electrically Erasable, Programmable Read Only Memory; återskrivningsbart minne som behåller data efter avstäng-ning.

ELF Executable and Linkable Format; Körbart och länkningsbart format.

FPGA Field Programmable Gate Array; Programmerbart

lo-gikchipp som kan syntetisera andra chipp, till exempel pro-cessorer.

GCC Gnu Compiler Collection; En uppsttning kompilatorer från GNU.

GNU GNU’s Not Unix; En uppsättning fri mjukvara med en

mängd olika verktyg.

GPIO General Purpouse Input/Output; Generella in- och utgång-ar.

I²C Inter-Integrated Circuit; Seriellt protokoll för flera enheter över två delade signalledningar.

ICSP In-Circuit Serial Programmer; Programmeringsutrustning som kan anslutas direkt i kretsen.

IHEX Intel HEX; Textbaserat format som beskriver en adressrymd och data.

Max32 Arduinokompatibelt utvecklingskort från Digilent Chipkit, baserat på mikrokontrollern Microchip PIC32MX795F512L MIPS Microprocessor without Interlocked Pipeline Stages; En pro-cessorarkitektur vanlig inom undervisning och inbyggda sy-stem.

MOSFET Metal Oxide Semiconductor Field Effect Transistor; Fältef-fekttransistor.

MPIDE Multi-Platform IDE; Integerad utvecklingsmiljö med Arduino-kompabilitet.

Mplab X Integrerad utvecklingsmiljö från Microchip med fokus på ut-veckling i C och C++.

Nios II Mjukvaruimplementation av en MIPS-liknande processor för FPGA

OLED Organic Light Emitting Diode; Organisk lysdiod, vanlig tek-nik för små skärmar.

PIC32 En familj av mikrokontrollers baserade på 32-bitars MIPS-arkitektur.

PIC32MX320F128H MIPS-baserad mikrokontroller i PIC32-serien från Microchip som används på Digilent Uno32.

RAM Random Access Memory; läs- och skrivbart minne, arbets-minne.

ROM Read Only Memory; skrivskyddat minne.

RISC Reduced Instruction set Computer; En designstrategi som förespråkar enkla ortogonala instruktionsuppstättningar för processorer.

SPI Serial Peripheral Interface; seriellt fullduplexprotokoll för flera enheter över tre signalledningar.

UART Universal Asynchronous Receiver/Transmitter; seriellt, självklockande fullduplexprotokoll för två enheter.

Uno32 Arduinokompatibelt utvecklingskort från Digilent Chipkit, baserat på mikrokontrollern Microchip PIC32MX320F128H XC32 Kompilatorkedja från Microchip för Pic32.

Författarförteckning

1.1 Bakgrund Steven Arnow

1.2 Syfte Axel Isaksson

1.3 Avgränsningar Axel Isaksson

1.4 Konkreta mål Axel Isaksson

2.1 Uno32 och lämplig utvecklingsmiljö Axel Isaksson

2.2 Bygga GCC för PIC32 Steven Arnow

2.3 Användning av startladdare utanför Arduino-miljön Steven Arnow

3.1 Processorn Steven Arnow

3.2.1 Generella in- och utgångar Axel Isaksson

3.2.2 UART-serieport Steven Arnow

3.2.3 OLED-skärm Axel Isaksson

3.2.6 Temperatursensor Axel Isaksson

4 Arbetsgång Steven Arnow

5 Skräddarsydd utvecklingsmiljö Axel Isaksson

5.1.1 Utvecklingsmiljöns målkatalog Axel Isaksson

5.1.2 Kompileringsberoenden Steven Arnow

5.1.3 Automatisk nedladdning av källkod Axel Isaksson 5.1.4 PIC32-specifika C-huvuden, symboler Axel Isaksson

5.1.5 Körstödsbiblioteket crt0 Steven Arnow

5.1.6 Länkskript Axel Isaksson

5.1.7 Konverterare av binärfilsformat Steven Arnow 5.1.8 Miljövariabler i utvecklingsmiljön Steven Arnow 5.1.9 Paketering för distribution Axel Isaksson 5.2 Konfigurationsflaggor för utvecklingsmiljön Steven Arnow

5.3 Projektmall Steven Arnow

5.4 Programmeringsutrustning Axel Isaksson

5.5 Hårdvarubyglar Axel Isaksson

6.1 Test av grundläggande in- och utmatning Axel Isaksson 6.2 Test av analog- till digitalkonverteraren Axel Isaksson 6.3 Test av seriekommunikation (UART) Steven Arnow

6.4 Test av skärm Axel Isaksson

6.5 Test av avbrottskontroller Steven Arnow

6.6 Test av temperatursensorn Axel Isaksson

7.1 Analys Steven Arnow

7.2.1 Startladdare jämfört med programmeringsutrustning Arnow, Isaksson 7.2.2 Framtidssäkerhet för programmeringsutrustning Axel Isaksson 7.2.3 Exempelkod tillgänglig för studenter Axel Isaksson

7.3 Konsekvensanalys Steven Arnow

7.4 Uppnådda mål Axel Isaksson

1

Introduktion

Kapitlet introducerar arbetet, arbetets bakgrund och arbetets mål. Avsnitt 1.1 förklarar bakgrunden till arbetet. Avsnitt 1.2 förklarar syftet med arbetet. Avsnitt 1.2 förklarar de avgränsningar som valdes för arbetet. Avsnitt 1.4 beskriver de konkreta mål som arbetet förväntas uppnå.

1.1 Bakgrund

Nuvarande datorteknikslaborationer vid KTH i Kista utförs på en FPGA-baserad platt-form kallad Altera DE2. En FPGA är en stor, programmerbar logikkrets som kan anta många roller och implementera olika typer av system[44]_{. På FPGA-plattformen används}

en processorkärna kallad Nios II[1]_{. Processorn Nios II skiljer sig från MIPS-arkitekturen}

som studeras i den teoretiska undervisningen i kursen. Skillnaden mellan praktiskt an-vänd och teoretiskt studerad processor är ett vanligt klagomål från studenter. Skillnaden i arkitektur är märkbar eftersom ett grundläggande lärandemål är lågnivåprogrammering i C och assembler[19].

plattformen som används i undervisningen har även andra problem. Då DE2-plattformen använts i undervisningen under en längre tid börjar hårdvaran få problem med åldersmässigt slitage. Den integrerade utvecklingsmiljön som används, Nios II IDE, är långsam och klumpig att använda. Eftersom plattformen har en FPGA i stället för en riktig processor, och eftersom lagringminne för hur logiken programmeras saknas, behöver studenter ladda upp processordefinitionen till utvecklingskortet varje gång ut-vecklingskortet används. För att ladda upp processordefinitionen krävs en annan pro-gramvara: Altera Quartus[2].

En möjlig ersättare för plattformen har eftersökts och hittats: plattformen Chipkit Uno32 kombinerat med expansionskortet Basic IO Shield. Med bakgrund av bytet till en ny plattform vill även kursansvarig undersöka möjligheten att använda den nya plattformen i ett nytt projektmoment i kursen.

1.2 Syfte

Det övergripande syftet är att undersöka hur Digilent Chipkit Uno32 i kombination med Basic IO Shield kan användas som en projektplattform i datortekniksundervisning. Projekten som avses är projekt som studenterna utvecklar självständigt efter ett betygs-underlag/kravspecifikation.

Största fokus läggs på att studenterna själva ska kunna använda plattformen i kursens projektdel. Den mjukvara och hårdvara som används behöver därför vara lätt att använ-da och enkelt kunna installeras på studenternas egna använ-datorer. Detta skiljer sig från de laborationer som hålls i kursen, där laborationerna utförs i för ändamålet avsedda salar under handledning. Flera alternativ finns för hur Uno32 kan användas för projekten.

Alternativen avser bland annat olika kringutrustning, utvecklingsmiljöer och mjukva-rupaket. Arbetet syftar till att finna det lämpligaste alternativet för användning som studentprojektplattform i datortekniksundervisning.

Ett antal testprojekt utvecklas i samband med utvärderingsarbetet. Testprojektens syfte är att:

• Fastställa plattformens lämplighet som projektplattform för studenterna. • Användas i undervisningen för att demonstrera plattformen.

• Agera utgångspunkt/referensimplementation för studenternas egna projekt. 1.3 Avgränsningar

Tidigare arbeten har redan undersökt flera aspekter av Uno32 samt gjort jämförelser mellan Uno32 och den nuvarande DE2-plattformen. Ingen större vikt kommer därför att läggas på att åter göra dessa jämförelser.

Arbetet syftar heller inte till att i större utbredning behandla den salsbundna laborta-tionsundervisningen i datorteknikskursen. Fokuset för arbetet ligger främst på de mer självständiga studentprojekten. Studenterna förväntas redan vara bekanta med plattfor-men från föreläsningar och laborationerna.

Det ursprungliga målet med arbetet var att utveckla exempelprojekt för självständiga studentprojekt i kursen Datorteknik vid KTH i Kista på plattformen Uno32. Exempel-projekten skulle demonstrera hur studentprojekt på olika betygsnivåer skulle kunna se ut. Tidigt i arbetet uppdagades dock flertalet brister med de för plattformen tillgängliga utvecklingsmiljöerna. Bristerna identifierades främst under studier av tidigare arbeten. På grund av bristerna i utvecklingsmiljöerna skiftades arbetets fokus till att i första hand ta fram en skräddarsydd utvecklingsmiljö utan dessa brister, bättre lämpad för dator-tekniksundervisningen. Den framtagna utvecklingsmiljön testas med mindre testprojekt, men dessa testprojekt ämnar inte fungera som exempel för ett fullständigt studentpro-jekt.

1.4 Konkreta mål

Målet med arbetet är att ta fram en utvecklingsmiljö för användning i datortekniksunder-visning, för plattformen Chipkit Uno32. Utvecklingsmiljön ska innehålla en C-kompilator och en assemblerare för mikrokontrollerserien PIC32. Fokus för kompabilitet ska vara på plattformen Uno32 och dess specifika modell av PIC32-processorn, då detta är plattfor-men som ämnas användas i undervisningen. Den framtagna utvecklingsmiljön ska vara framtidssäker och lämplig att använda i undervisningen med hänseense på de ingående komponenternas licensavtal. Målsättningen är att göra utvecklingsmiljön tillgänglig för följande populära värdplattformar:

• System baserade på Apple OS X • System baserade på GNU/Linux

En serie testprojekt tas fram för att utvärdera hårdvaruplattformen och testa den fram-tagna utvecklingsmiljön. En projektmall utvecklas som innehåller den kodbas som behövs för att köra kod på plattformen.

2

Tidigare arbete

Kapitlet beskriver de tidigare arbeten som huvudsakligen ligger som grund för arbetet. Avsnitt 2.1 beskriver det tidigare kandidatexamensarbete som pekade ut Uno32 som lämplig plattform samt de slutsatser som drogs om utvecklingsmiljöer för Uno32. Av-snitt 2.2 beskriver tidigare dokumenterade kompileringar av GCC för PIC32. AvAv-snitt 2.3 beskriver hur en startladdare kan användas med Uno32 utanför Arduino-miljön.

2.1 Uno32 och lämplig utvecklingsmiljö

Ett tidigare kandidatexamensarbete vid KTH, Översikt och detaljstudium av hårdvara

för laborationer i datorteknik[42]_{, undersökte möjliga hårdvaruplattformar att använda}

för datortekniksundervisning vid KTH. KTH har tidigare använt utvecklingskortet DE2 från Altera tillsammans med en syntetiserad Nios-II-processor.

Plattformen som fastställs som en möjlig ersättare till DE2-plattformen i Översikt och

de-taljstudium av hårdvara för laborationer i datorteknik är Digilent Chipkit Uno32. Uno32

är baserad på mikrokontrollern PIC32MX320F128H från Microchip[33]_{. Mikrokontrollers}

i PIC32-serien bygger på en processor med MIPS-arkitektur[32] och skulle därför lämpa sig väl för användning i datortekniksundervisningen, då undervisningen i övrigt är fo-kuserad kring MIPS. Utöver processorarkitekturen pekades det lägre priset ut som en fördel för Uno32 gentemot DE2-plattformen[42]_.

Vidare jämfördes olika utvecklingsmiljöer för Uno32 för att hitta den bäst lämpade mil-jön att använda för datorteknikslaborationerna. Utvecklingsmiljöerna som undersöktes var Mplab X från Microchip och Arduino-miljön MPIDE från Chipkit.

Slutsatserna var att MPIDE var lättanvänd, men lämpade sig inte väl för datortek-niksundervisningen, då utvecklingsmiljön abstraherade bort för mycket av hårdvaran. Mplab X tillät emellertid mer hårdvarunära programmering än MPIDE, och hade and-ra fördelar som en kand-raftfull avlusare. Den största nackdelen med MPIDE ansågs vaand-ra utvecklingsmiljöns komplexitet samt behovet av extra programmeringshårdvara.

Detta arbete bygger vidare på de idéer och förslag som ges i Översikt och detaljstudium

av hårdvara för laborationer i datorteknik. Arbetet kommer, till skillnad från det

tidiga-re, att behandla användandet av Uno32 som en projektplattform för studenternas egna projekt. Extra stor vikt läggs därför på att studera enkelheten med vilken studenterna kan använda plattformen på egen hand, utan den handledning som kan ges under salsla-borationer. För att undvika komplexiteten i Mplab X, men utan att abstrahera bort den underliggande hårdvaran, undersöks en skräddarsydd kompileringsmiljö baserad på GNU GCC och byggfiler (Engelska: makefiles). Att använda en skräddarsydd miljö togs upp som framtida arbete i Översikt och detaljstudium av hårdvara för laborationer i

datorteknik. I arbetet undersöks också möjligheterna att frångå behovet av extern

(Engelska: bootloader) skulle program kunna överföras direkt till Uno32 utan den extra programmeringshårdvaran.

2.2 Bygga GCC för PIC32

Både MPIDE och Mplab X använder Microchips kompilatormiljö XC32. XC32 bygger i grunden GCC[35]_{, GNU Compiler Collection, varför möjligheten att använda en}

omodi-fierad GCC undersöktes.

Det är i sig ingen nyhet att bygga en korskompilator (Engelska: cross compiler) för PIC32, dvs. en kompilator som genererar kod för en annan plattform än plattformen kompilatorn kör på. Ett flertal lyckade försök har hittats, varav ett till viss grad do-kumenterat[39]_{. Gemensamt för alla hittade fall är en avsaknad av färdig paketering av}

andra viktiga komponenter, exempelvis körstödsbiblioteket crt0 (Engelska C runtime library) och länkskript.

Då fokus i funna tidigare arbeten läggs på att bygga själva kompilatorn utelämnas detal-jer om hur en komplett utvecklingsmiljö kan byggas. Detta arbete kommer till skillnad från tidigare arbeten sikta in sig på att bygga en utvecklingsmiljö passande kursens be-hov med en korskompilator för PIC32 som utgångspunkt. Den primära fortsättningen på tidigare arbeten är att packa ihop en komplett utvecklingsmiljö på ett distribuer-bart sätt. Ytterligare fokus läggs på lättanvändhet, installerbarhet och att inte använda komponenter med tvivelaktiga licenser.

2.3 Användning av startladdare utanför Arduino-miljön

Arduinomiljön MPIDE tillåter uppladdning av kod till Uno32 med hjälp av en startlad-dare (Engelska: bootloader). Användandet av en startladstartlad-dare medför att koduppladd-ning kan göras till Uno32 utan speciell utrustkoduppladd-ning, en vanlig persondator ansluts via USB till Uno32. I ett tidigare arbete av Marc McComb visas hur Mplab X kan använ-da den Arduinokompatibla startladanvän-daren från MPIDE genom att bland annat använanvän-da modifierade länkskript i Mplab X[24]_{. Länkskripten med stöd för startladdaren}

använ-des som bas för att kringgå behovet av extern separat programmeringsutrustning i den framtagna utvecklingsmiljön.

3

Hårdvaruplattformen

Kapitlet behandlar den gjorda litteraturstudien. Avsnitt 3.1 behandlar studie av proces-sorn i PIC32-mikrokontrollern och dess arkitektur. Avsnitt 3.2 behandlar hårdvaran på utvecklingskortet Uno32 och dess expansionskort Basic IO Shield.

3.1 Processorn

Mikrokontrollern på Uno32 är PIC32MX320F128H från Microchip. Processorn använder en variant av MIPS instruktionsuppsättning, MIPS32r2[32, s. 37]_{. Processorn saknar}

hård-vara för flyttalsberäkning[27, s. 56]. C-kompilatorn GCC kan hantera flyttalsberäkningar i mjukvara när hårdvarustöd saknas[11]_.

Avsnittet behandlar MIPS-processorn i PIC32-mikrokontrollern. Avsnitt 3.1.1 beskriver hur processorn använder sig av så kallade delay slots efter hopp. Avsnitt 3.1.2 beskriver hur processorns avbrottskontroller fungerar.

3.1.1 Delay slots

MIPS-arkitekturen använder sig av delay slots[10]. Delay slots innebär att instruktionen följande en hoppinstruktion kommer att utföras oavsett om hoppet görs eller inte. GNU Assembler har som standardinställning att automatiskt byta plats på instruktioner för att fylla i delay slots med en vettig instruktion. I utbildningssyfte kan det vara in-tressant att studenten själv får ta hänsyn till delay slots. För att avaktivera automatiken kan ett attribut sättas i assemblerfilen:

.set noreorder

Instruktioner som ligger efter denna rad i källkodsfilen kommer inte att omstruktureras av assembleraren. Inga nop-instruktioner fylls heller i och inga försök till att undvi-ka kända kiselbuggar (fel i hårdvaran som undvi-kan utlösas av vissa instruktionssekvenser) utförs[43]_.

3.1.2 Avbrottskontrollern

PIC32-mikrokontroller har en inbyggd avbrottshanterare för att hantera avbrott från både extern hårdvara och inbyggda styrenheter[32]. Avbrottskontrollern har två lägen: dels kan olika avbrott gå till samma avbrottsvektor och dels så kan olika avbrott gå till olika avbrottsvektorer (multivektorläge). Vilken vektor ett avbrott använder i multivek-torläget är hårdkodat.

Standardinställningen medför att alla avbrott genererar samma avbrottsvektor: vektor 0. När alla avbrott går till samma vektor finns det inget bra sätt i hårdvaran att ta reda på vilket avbrott som inträffade. Då det specifika avbrottsnumret inte kan utläsas måste

avbrottshanteraren polla all hårdvara som möjligtvis kan ha orsakat avbrottet. Detta gäller inte i lika stor grad när multivektorläget används, då enbart ett fåtal avbrott finns som använder samma avbrottsvektor. Standardinställningen i mikrokontrollern är att alla avbrott går till samma vektor. Denna inställning används också i den framtagna utvecklingsmiljön.

Oavsett vilket läge avbrottskontrollern är i hanteras dock undantag (Engelska: excep-tions) på ett annat sätt. Undantag har i båda lägena en egen vektor strax före av-brottsvektorerna. Undantag orsakas av fel såsom bussfel (Engelska: bus error), reser-verad instruktion (reserved instruction) och aritmetiskt dataspill (Engelska: arithmetic overflow). Undantag orsakas också av trap och systemanrop (Engelska: syscall).

Mikrokontrollern har utöver MIPS-processorn en inbyggd hjälpprocessor som hanterar bland annat delar av avbrottskonrollern. Hjälpprocessorn är ansluten som hjälpprocessor 0 (Engelska: coprocessor 0) och åtkomst till dess interna register sker med särskilda instruktioner. Vilket undantag som inträffade går att ta reda på genom att läsa register 13:0 i hjälpprocessorn[25, s. 33]_.

För PIC32MX-familjen gäller att en speciell instruktion eret används när avbrottshan-teraren ska återge kontrollen till det avbrutna programmet.[28, s. 33] _{Denna instruktion}

återställer automatiskt programräknaren och tillstånd i avbrottskontrollern. Att manu-ellt återställa detta tillstånd är inte undersökt i detalj.

PIC32MX har en dubbel uppsättning av programregister för att snabba upp hante-ring av avbrott, dessa register kallas GPR shadow registers[32, s. 37]_{. Avbrottskontrollern}

kan växla automatiskt mellan dessa två uppsättningar, beroende av prioriteten på det inträffade avbrottet[28, s. 18].

3.2 Kringhårdvara

Följande avsnitt beskriver kringhårdvaran på utvecklingskortet Uno32 och dess expan-sionskort Basic IO Shield. Avsnitt 3.2.1 beskriver de enheter kopplade till mikrokontrol-lerns generella in- och utgångar. Avsnitt 3.2.2 beskriver hur mikrokontrolmikrokontrol-lerns UART-serieport är kopplad på Uno32. Avsnitt 3.2.3 beskriver hur skärmen på Basic IO Shield fungerar. Avsnitt 3.2.6 beskriver hur temperatursensorn på Basic IO Shield fungerar.

3.2.1 Generella in- och utgångar

PIC32MX320F128H har ett 50-tal GPIO-pinnar[32] (Generella in- och utgångar). Fler-talet av dessa pinnar är anslutna till expansionskontakten på Uno32. På expansions-kortet Basic IO Shield finns fyra tryckknappar, fyra skjutomkopplare och åtta lysdio-der. Knapparna, omkopplarna och lysdioderna är kopplade via expansionskontakten till GPIO-pinnarna på mikrokontrollern.

3.2.2 UART-serieport

PIC32MX320F128H har två kontrollers för UART-serieport[32]. Serieporten UART1 är kopp-lad till en UART- till USB-brygga på Uno32, UART0 är koppkopp-lad till expansionskontakten på Uno32.

3.2.3 OLED-skärm

På Basic IO Shield finns en OLED-skärm (Organisk Lysdiod) med beteckningen UG-23832HSWEG04 från Wisechip/Univision. Skärmens styrkontroller har beteckningen SSD1306 från Solomon Systech.

Avsnitt 3.2.4 beskriver skärmens gränssnitt och styrsignaler. Avsnitt 3.2.5 beskriver hur skärmens grafikminne adresseras.

3.2.4 Styrning av skärmen

Skärmen är en svartvit, grafisk skärm med en upplösning på 128×32 pixlar. Styrkontrol-lern är ansluten via SPI (Serial Peripheral Interface) till mikrokontrolStyrkontrol-lern på Uno32. Skärmen har två olika matningsspänningar som är kopplade genom två MOSFET-transistorer (fälteffekttransistor). Transistorernas styrsignaler är kopplade till GPIO (generella in- och utgångar) på mikrokontrollern. Ytterligare två styrsignaler på skärm-kontrollern, reset och command/data är kopplade till GPIO på mikrokontrollern. Sig-nalen reset återställer skärmkontrollerns interna register till ursprungsvärden. SigSig-nalen command/data bestämmer om värden som skickas på SPI-porten ska tolkas som kontrol-lerkommandon eller grafikdata[7]_{. Grundläggande exempelkod för hur skärmen initieras}

och används tillhandahålls av Chipkit[7]. Mer utförlig dokumentation av skärmens styr-kontroller finns i styrstyr-kontrollerns datablad[23]_.

3.2.5 Adressering av grafikminnet

Skärmens grafikminne är indelat i fyra olika banker (rader). Varje rad är 8 pixlar hög och är kolumnadresserad, där varje kolumn motsvarar en byte i minnet. Se Figur 1 för en ritning över skärmens minneslayout. Den radbaserade minneslayouten med kolumn-adressering är lämplig för att skriva ut text med ett 8 pixlar högt typsnitt. Efter att skärmen initierats och en minnesbank är vald kan skärmen ställas i dataläge. I dataläget tar skärmen emot data som läggs i grafikminnet.

3.2.6 Temperatursensor

På Basic IO Shield finns en temperatursensor. Temperatursensorn är av beteckningen TCN75A och tillverkas av Microchip[29]. Temperatursensorn är ansluten till

mikrokontrol-Bit 0

Bit 7

Byte 0 Byte 15

Rad 0

Rad 3

lern på Uno32 via I²C (Inter-Integrated Circuit) och kommunikationen sker genom att läsa och skriva till sensorns interna register.

Temperatursensorn har fyra register och ett adresspekarregister. Varje transaktion med temperatursensorn sätter först adresspekarregistret till numret på det register som ska läsas eller skrivas. Exempel på temperatursensorns register är konfigurationsregistret och temperaturregistret. Konfigurationsregistret är ett läs- och skrivbart register. I konfigu-rationsregistret finns inställningar för upplösning på den samplade datan och om kon-tinuerlig sampling eller engångssampling ska användas. Temperaturregistret innehåller det samplade värdet från sensorn. Temperaturdatan är ett 16 bitars fasttal (Engelska: fixed point), med 8 bitars heltalsdel och 8 bitars bråktalsdel. Enheten är grader Celsi-us[29].

4

Arbetsgång

I det här kapitlet beskrivs hur plattformen Chipkit Uno32 utvärderades som plattform för studentprojekt samt hur avlusning skedde under utvecklandet av testprogram. I av-snitt 4.1 behandlas överskådligt arbetsflödet som användes för att konstruera en prototyp av utvecklingsmiljön samt hur den utvärderades. I avsnitt 4.2 behandlas metoden som användes för att verifiera funktionalitet hos utvecklingsmiljön. I avsnitt 4.3 behandlas testprojektens roll vid plattformsutvärderingen. I avsnitt 4.4 behandlas olika avlusnings-metoder som användes när utvecklingsmiljön och exempelprojekten utvecklades. Utvärderingen har flera distinkta steg som behandlar olika delar av frågeställningen. Generellt har en översiktlig litteraturstudie gjorts i början för att utvärdera potentialen i plattformen samt grovt planera vad som behöver undersökas i detalj, och i vilken ord-ning. Den översiktliga studien är en fortsättning på ett tidigare arbete som behandlade laborationer i kursen[42].

4.1 Utveckling av utvecklingsmiljön

Det finns ett flertal krav som måste uppfyllas för att en utvecklingsmiljö ska vara attrak-tiv för användande i ett studentprojekt. Främst ska studenter kunna installera utveck-lingsmiljön på sin egen dator. Utveckutveck-lingsmiljön ska heller inte dölja tekniska detaljer som kursen ämnar att behandla. Tekniska detaljer som kursen behandlar är bland an-nat minnesmappad I/O och avbrott[19]. Att studenter använder byggfiler (makefiles) och därmed kan följa processen av kompilering och överföring anses fördelaktigt enligt kursansvarig[21]_.

Ett iterativt arbetssätt användes för att konstruera prototypen till kompilatormiljön. Det mest grundläggande steget var att ta fram en korskompilator för MIPS-arkitekturen. Den grundläggande och avskalade kompilatorn kompletterades därefter med en komponent i taget för att utöka funktionaliteten. Hur dessa komponenter valdes baserades främst på tidigare erfarenhet av vad en korskompilator består av. I första hand plockades dessa komponenter från Mplab X och MPIDE där licens tillät vidaredistribuering. De existe-rande utvecklingsmiljöerna kan producera fungeexiste-rande kod för PIC32 och komponenterna från dessa utgör en utgångspunkt.

Funktionstest är svåra att göra innan hela kedjan finns på plats. För att ytligt utvärdera funktionalitet inspekterades utfilerna efter varje steg. Efter kompilering undersöktes den genererade assemblykoden. Efter länkning undersöktes den genererade ELF-binären med verktyget file och med objdump för att lista disassemblerad kod och säkerställa att alla programareor (section) fanns med. När ELF-filen såg bra ut vid inspektion konverte-ras den till en IHEX-fil. Den skapade IHEX-filen inspektekonverte-ras enligt avlusningsmetod i avsnitt 4.4.1. Till en början användes objcopy från GNU Binutils för att utföra konver-teringen. Då de genererade IHEX-filerna inte fungerade hittades en ersättare. Verktyget bin2hex från kompilatorkedjan XC32 från Microchip användes i slutskedet för att göra

konverteringen. Som sista steg i utvärdering av prototypen skickas IHEX-filen över med verktyget avrdude till Uno32 för att testköra den skrivna programkoden.

4.2 Verifiering av utvecklingsmiljön

För att verifiera utvecklingsmiljöns funktionella duglighet användes främst de framtag-na testprojekten beskrivframtag-na i kaptiel 6. Dessa projekt testar att plattformens tillgängliga hårdvara går att använda med utvecklingsmiljön som tagits fram och att genererad kod är körbar på plattformen. Test gjordes även för att verifiera att globala variabler kan användas i kompilerad kod samt läsas och skrivas under körning. Testprojektet för skär-men på Basic IO Shield använder globala variabler initierade med värde noll i binärens BSS-area. Ett separat test användes för att verifiera att initierade, globala variabler med värde annat än noll (binärens dataarea) kan läsas och skrivas samt att de har korrekt initieringsvärde. Detta test baserades på en buffer med initierad data. Innehållet i denna buffer visades med hjälp av de åtta lydioderna på Basic IO Shield. Innehållet i buffern modifierades därefter genom programkoden till ett nytt värde. Den modifierade bufferns innehåll visades sedan med hjälp av lysdioderna på Basic IO Shield.

Utvecklingsmiljöns funktionalitet på olika värdplattformar verifierades genom att kom-pilera och installera de framtagna testprojekten. Utvecklingsmiljön har testats på nedan listade plattformar. • Windows XP SP3 • Windows 7 SP1 • Ubuntu 14.04 LTS • Debian Jessie (8.0) • Mac OS X 10.10.3

För målplattformar med en annan mikrokontroller än den på Uno32 har inga omfattande tester konstruerats eller utförts. Eftersom det är specifikt plattformen Uno32 som ämnas användas i utbildningen har ingen särskild fokus lagts på att säkra kompabilitet med andra PIC32-plattformar. Ett enkelt test där en lysdiod blinkades kördes på Digilent Chipkit Max32. Plattformen Max32 använder en annan PIC32-baserad mikrokontroller än plattformen Uno32, PIC32MX795F512L[6]_{. Körstödsbiblioteket som används}

tillsam-mans med utvecklingsmiljön (avsnitt 5.1.5) förefaller inte använda funktioner specifika för enskilda mikrokontrollers men detta testades inte närmare. Att testet med en blin-kande lysdiod fungerade på Max32 indikerar dock att körstödsbiblioteket tar sig igenom initieringssekvensen utan att allvarliga fel uppstår.

4.3 Utvärdering av plattformen med hjälp av testprojekt

Efter att en måluppfyllande utvecklingsmiljö färdigställts till den grad att kod kunde testköras på plattformen började plattformens hårdvara att utvärderas. För att

utvärde-ra plattformens egentliga användbarhet skapades en utvärde-rad testprojekt beskrivna i kapitel 6. Dessa exempelprojekt användes för att utvärdera olika komponenter på Uno32 tillsam-mans med expansionskortet Basic IO Shield samt för att säkerställa korrekt funktiona-liet hos den framtagna utvecklingsmiljön. Testprojekten konstruerades för att utvärdera plattformens komponenter separat och därmed uppskatta svårighetsgraden för studenter att själv använda en specifik del av hårdvaran. Utöver detta användes även testprojek-ten för att ge en egen intern kännedom av hårdvaran. Tanken var att underlätta inför utvecklingen av de exempel på studentprojekt som sattes upp som mål för arbetet. Då målsättningen för arbetet i ett tidigt skede gjordes om till att utesluta dessa fullständiga exempelprojekt konstruerades dessa aldrig, utan ligger som framtida arbete.

4.4 Avlusning

Flera olika metoder användes för avlusning av den framtagna utvecklingsmiljön samt de utvecklade programmen. I det här avsnittet beskrivs avlusningsmetoder som an-vänts.

I avsnitt 4.4.1 beskrivs hur felsökning skedde genom visuell inspektion av utdatafiler. I avsnitt 4.4.2 beskrivs hur program på plattformen testades i ett tidigt skede, när tillgång till hjälpsam kringhårdvara saknades. I avsnitt 4.4.3 beskrivs hur grundläggande in-och utmatning till kringhårdvaran användes i felsökningen. I avsnitt 4.4.4 beskrivs hur UART-serieporten användes för felsökning.

4.4.1 Avlusning genom inspektion av genererad IHEX-fil

Under utvecklandet av testprogram upptäcktes en del fel i länkskript och källkod till körstödsbiblioteket för C-kod (crt0). En metod för att felsöka och testa om felet av-hjälps var att inspektera IHEX-filen som genereras från den länkade ELF-binären av det sista steget i kompileringskedjan. Denna IHEX-fil beskriver exakt det som skickas över till mikrokontrollern och är i ett format som är läsbart för människor. Med en textredigerare som Vim med syntaxmarkering kan IHEX-filen visuellt inspekteras ef-ter programareor (Engelska: sections) som inkluderats med adresser som utgångspunkt. Kombinerat med en beskrivning av IHEX-formatets uppbyggnad[4] _{är en sådan}

inspek-tion relativt enkel.

4.4.2 Avlusning genom blockerande slinga

Under uppstartstiden, då de olika stegens egentliga korrekthet är okänd, användes enklast möjliga tester.

Det första testet som gjordes försäkrade att den överförda koden faktiskt kördes. En lys-diod på Uno32 blinkar under tiden som startladdaren är aktiv. Enkel testkod utvecklades som blockerade programflödet i en lång loop, och sedan åter hoppade till startladdaren.

Under tiden som koden körs slocknar lysdioden på Uno32, och när koden hoppat till startladdaren igen börjar den åter att blinka. Då tydlig indikation visas när startladda-ren är aktiv, kan testkodens repeterbarhet och kontroll över hur länge testkoden låser (och stoppar blinkandet från startladdaren) indikera att byggstegen av testprogram-met är tillräckligt korrekt för noggrannare test och avlusning. Steget vidare involverar främst testerna beskrivna i kapitel 6. Testerna repeterades även för utvecklingskortet ChipkitMax32.

4.4.3 Avlusning med visuell indikation

Vid avlusning av blockerande program, exempelvis textprogrammet hello-temperature, användes de åtta lysdioderna på Basic IO Shield för avlusning. En lysdiod i taget tändes efter varje steg i programmet. När låsning uppstod kunde den låsande kodraden enkelt hittas genom att undersöka lysdioderna.

4.4.4 Avlusning med UART

Efter att datorkommunikation via UART upprättats kan information skickas till ett ter-minalprogram på en persondator över UART. Att skicka information över UART är ett sätt att förenkla avlusning. En implementation av biblioteksfunktionen printf() hade tidigare utvecklats för andra ändamål[17]. Denna printf()-implementation anpassades för UART-serieporten på PIC32. Genom möjligheten att göra spårutskrifter förenklades avlusningen avsevärt.

Figur 2: Utvecklingsmiljöns ingående komponenter

5

Skräddarsydd utvecklingsmiljö

Som en del i arbetet undersöktes möjligheten att använda en skräddarsydd utvecklings-miljö istället för Microchip Mplab X eller Chipkit MPIDE. Undersökningarna resulterade i att en fungerande utvecklingsmiljö för PIC32 togs fram[39].

Utvecklingsmiljöns mest grundläggande komponenter är C-kompilatorn GCC och verk-tygsuppsättningen GNU Binutils som har assembleraren as och länkaren ld. Verktyget bin2hex används för att konvertera ELF-binären från ld till ett format som kan skic-kas till mikrokontrollern, och konvertera alla adresser till rätt adressrymd. Verktyget avrdude används för att skicka över program till mikrokontrollern. För att styra kom-pileringen används byggfiler (makefiles) kompatibla med GNU Make.

Figur 2 beskriver de olika komponenterna i utvecklingsmiljön. Figuren visar vilka kom-ponenter som är standardkomkom-ponenter för alla plattformar och vilka komkom-ponenter och tillägg som gjorts specifikt för PIC32.

Kapitlet behandlar de resultat som erhållits från arbetet och gjorda undersökningar un-der framtagningen av den skräddarsydda utvecklingsmiljön. Avsnitt 5.1 beskriver framta-gandet av den skräddarsydda utvecklingsmiljön. Avsnitt 5.2 beskriver kompileringsflag-gorna som används för att bygga utvecklingsmiljön. Avsnitt 5.3 beskriver den framtagna projektmallen för projekt som kompileras under den skräddarsydda utvecklingsmiljön. Avsnitt 5.4 beskriver resultatet från studien av tillgänglig programmeringshårdvara till PIC32. Avsnitt 5.5 beskriver byglarna på Uno32 och deras inverkan på utvecklingskortets funktionalitet.

5.1 Utvecklingsmiljöns beståndsdelar

Avsnittet beskriver den framtagna utvecklingsmiljöns beståndsdelar. Alla byggskript, paketeringsskript och kringmjukvara som utvecklades eller adapterades för färdiga

ut-vecklingsmiljön finns tillgänglig på Github[39]. Bilaga A instruerar steg för steg hur utvecklingsmiljön byggs från källkod och paketeras för distribution.

Avsnitt 5.1.1 förklarar valet av målkatalog för utvecklingsmiljön. Avsnitt 5.1.2 beskriver kompileringsberoendena hos utvecklingsmiljöns olika beståndsdelar. Avsnitt 5.1.3 beskri-ver hur och varför byggskriptet för utvecklingsmiljön modifierades till att automatiskt ladda ner källkoden för de ingående beståndsdelarna. Avsnitt 5.1.4 beskriver de pro-cessorspecifika C-huvuden som används i utvecklingsmiljön. Avsnitt 5.1.5 beskriver kör-stödsbiblioteket som används. Avsnitt 5.1.6 beskriver de länkskript som används och hur de modifierades för att passa utvecklingsmiljön. Avsnitt 5.1.7 beskriver hur binärfiler ska-pade av utvecklingsmiljöns länkare måste konverteras för att fungera på målplattformen. Avsnitt 5.1.8 beskriver de miljövariabler som behöver sättas av utvecklingsmiljön. Av-snitt 5.1.9 beskriver hur den färdiga utvecklingsmiljön paketeras för distribution. 5.1.1 Utvecklingsmiljöns målkatalog

Då åtminstone GCC använder hårdkodade sökvägar behövdes en fast målkatalog be-stämmas vid kompileringstillfället. Samma katalog behöver sedan användas när utveck-lingsmiljön installeras på en annan dator. Målkatalogen valdes därför till en lämplig standardinställning per plattform. På målplattformen Microsoft Windows används kom-patiblitetslagret Msys2[40] _{för att översätta sökvägar till en UNIX-liknande miljö som}

GCC förväntar sig.

Målkatalogen som valdes för Linux- och Msys2-system är /opt/pic32-toolchain För Mac OS X valdes målkatalogen /Applications/pic32-toolchain.app Skrivning till dessa kataloger är endast tillåtet för administratörsanvändare (root). Vanligtvis när program kompileras körs kommandot make install som en administratörsanvända-re för det sista installationssteget. Då flera av kompileringsstegen beror på att andra komponenter i kedjan installerats till målmappen valdes ett annat tillvägagångssätt för att undvika att hela byggprocessen körs som administratörsanvändare, eller att bygg-processen måste avstannas mitt i för att köra ett installationssteg som administratör. Tillvägagångssättet som valdes var att uppmana användaren att först som administratör skapa målmappen manuellt och ge en vanlig användare skrivrättigheter till målmappen. Resten av byggprocessen kan sedan köras utan administatörsbehörighet.

Målkatalogen som används går att ställa in när utvecklingsmiljön byggs genom att re-digera variabeln PREFIX i utvecklingsmiljöns byggfil kallad Makefile.

5.1.2 Kompileringsberoenden

För att kunna utnyttja flera trådar vid kompilering av utvecklingsmiljön behövde byggfi-len konstrueras till att korrekt hantera beroenden i byggprocessen mellan de olika delarna i utvecklingsmiljön. Till exempel beror GCC på att biblioteken gmp, mpfr och mpc först

Figur 3: Beroendeträd för kompilering av utvecklingsmiljön. Skript och färdig metadata har utelämnats. Pilar pekar på komponenter som måste vara installerade.

har kompilerats och installerats till målmappen innan GCC kan kompileras. Figur 3 beskriver kompileringsberoenden mellan utvecklingsmiljöns komponenter.

5.1.3 Automatisk nedladdning av källkod

Källkoden för hela utvecklingsmiljön behöver totalt 1,2 GB diskutrymme. Den stora storleken gjorde att källkodsträdet blev osmidigt att hantera med versionshanteringssy-stemet Git, då operationer i Git tog lång tid att utföra. Github rekommenderar även att källkodsträd som distribueras på Github håller sig under 1 GB storlek[12].

Efter överläggning med uppdragsgivare gjordes överenskommelsen att byggprocessen själv skulle ladda ner källkoderna för utvecklingsmiljöns beståndsdelar. Byggfilen ändra-des till att automatiskt ladda ner och packa upp källkodsarkiv från internet. Källkodsar-kiven för de olika komponenterna laddas ner från utvecklarnas officiella filservrar. Byggskriptet laddar ner specifika versioner av alla komponenter i utvecklingsmiljön, då kompatibilitet med nyare versioner inte kan garanteras. Till exempel skiljer sig fil-formatet på konfigurationsfilen för komponenten Avrdude mellan versionerna 5.x och 6.x. Utvecklingsmiljön använder en modifierad konfigurationsfil för Avrdude, ursprung-ligen tillhandahållen av Chipkit för MPIDE. Valet gjordes därför att använda den äldre versionen Avrdude 5.11 istället för den nyare versionen 6.1 för att kunna använda

kon-komponenter i utvecklingsmiljön valdes till de för tillfället senaste versionerna.

Komponenterna i utvecklingsmiljön är baserade på följande källkodspaket som laddas ner automatiskt under byggprocessen. Samtliga komponenter distribueras under fria mjukvarulicenser.

• GNU Binutils version 2.25; assemblerare, länkare, konverterare mellan olika binär-format.

• GNU GCC version 4.9.2; C-kompilator • GNU gmp version 6.0.0; beroende för GCC. • GNU mpfr version 3.1.2; beroende för GCC. • GNU mpc version 1.0.3; beroende för GCC.

• Avrdude version 5.11; verktyg för att programmera mikrokontrollers.

• GNU Make version 4.1; endast för Mac OS X som saknar make i standarddistri-bution.

Biblioteken gmp, mpfr och mpc finns installerat på vissa Linux-system. Systemets egna versioner av biblioteken används dock inte vid kompilering av utvecklingsmiljön. Dessa bibliotek laddas ner av utvecklingsmiljöns byggskript för att förbättra kontrollen över versioner på utvecklingsmiljöns beroenden.

5.1.4 PIC32-specifika C-huvuden, symboler

Styrhårdvaran i PIC32 är minnesmappad; den styrs genom läsningar och skrivningar till särskilda minnesadresser, ibland kallade register.

C-huvuden med definitioner över hårdvaruregistren för flertalet PIC32-mikrokontrollers, bland annat PIC32MX320F128H distribuerades tillsammans med Chipkit MPIDE under en tre-klausuls BSD-licens. Dessa C-huvuden inkluderades i den skräddarsydda utveck-lingsmiljön.

C-huvudena ackompanjeras av objektfiler med översättningar från huvudets symbol-namn till minnesadresser. För dessa objektfiler hittades ingen licensinformation. Det är möjligt att generera egna objektfiler med samma symbolöversättningar. En symbolta-bell kan genereras med hjälp av objdump utifrån de ursprungliga objektfilerna som en lista över alla symboler kopplade till absoluta minnesadresser. Dessa symboltabeller kan sedan länkas ihop till nya objektfiler med hjälp av ld.

Av juridiska skäl behandlade i avsnitt 7.3.1 är dock varken symboltabellerna eller de nygenererade objektfilerna inkluderade i utvecklingsmiljön.

5.1.5 Körstödsbiblioteket crt0

Crt0 är ett körstödbibliotek (Engelska: runtime library) som förbereder miljön för att kö-ra funktionen main() i ett C-progkö-ram. Körstödsbiblioteket innehåller en kodsekvens som körs först i programmet, före main(). Crt0 kan anropa andra moduler. Dessa moduler är crti, crtn, crtbegin och crtend.

Källkoden till ett C++-anpassat körstödsbibliotek för PIC32-baserade mikrokontrollers distribueras tillsammans med Chipkit MPIDE under filnamnet cpp-runtime.S. Licensen för körstödsbiblioteket i MPIDE är en tre-klausuls BSD-licens, och körstödsbiblioteket kunde därför användas och anpassas för den skräddarsydda utvecklingsmiljön.

Filen cpp-runtime.S döptes om till crt0.S, inga vidare anpassningar behövde göras för att använda filen tillsammans med C-kod istället för C++. I koden användes dock makron för processorns register (MIPS generella processorregister, ej PIC32-specifika minnesmappade register), vilka var definierade i en extern fil med en restriktiv mjukva-rulicens. Referenserna till den externa filen plockades bort och makrona ersattes med de faktiska registernamnen i koden.

Extramodulerna crti, crtn, crtbegin och crtend är ett komplement till crt0 och ligger i utvecklingsmiljön som kompilerade objektfiler. Gemensamt med alla fyra extramoduler är att de hanterar objektkonstruktorer och objektdestruktorer i C++. Då stöd för C++ aldrig var ett mål vid konstruktion av utvecklingsmiljön stubbades anrop till dessa mo-duler ut. Länkaren förväntar sig fortfarande att dessa momo-duler finns. Momo-dulerna crti, crtn, crtbegin och crtend ersattes därför med tomma objektfiler.

Körstödsbiblioteket modifierades även för att tillåta hantering av undantag (Engelska: exceptions) i användarkoden istället för i körstödsbiblioteket.

5.1.6 Länkskript

Länkskript för PIC32-baserade mikrokontrollers distribueras tillsammans med Chipkit MPIDE under licensen GNU Lesser General Public License. Länkskripten från MPIDE finns både för användning med och utan startladdare (bootloader).

Länkskripten för användning tillsammans med startladdare extraherades från MPIDE, och modifierades för att ta bort MPIDE-specifika detaljer. Dessa länkskript fungerade till synes bra, men problem uppdagades tillsammans med kod som använder initierade globala variabler.

Globala variabler som är initierade placeras i en data-area i RAM (Random Access Me-mory), men initieringsvärdena måste även finnas i en kopia i ROM (Read Only Memory). Körstödsbiblioteket kopierar vid körning upp initieringsvärdena från ROM till rätt ställe i RAM innan kontroll ges till programmet.

Program som länkades med de modifierade länkskripten från MPIDE placerade ROM-kopian av variablernas initieringsvärden på en felaktig adress; adress 0. Då ROM börjar

på adress 0x1D000000 ledde det till att avrdude kraschade vid programmering av mikro-kontrollern.

Problemet löstes genom att ytterligare modifiera länkskriptet till att explicit lägga ROM-kopian av initieringsvärdena efter alla andra areor i ROM. I samband med modifikatio-nerna förenklades även data- och bss-areorna. Areorna sdata (Small Data) och sbss (Small BSS) togs bort. Dessa areor används för snabbare åtkomst till globala variabler av mindre storlek, men ansågs överflödiga. Borttagandet av sdata och sbss medförde att flaggan -G 0 behöver skickas till GCC vid kompilering.

5.1.7 Konverterare av binärfilsformat

Binutils länkare ld genererar utfiler i formatet ELF, avrdude förväntar sig filer i formatet IHEX (Intel HEX). Detta medförde att ett verktyg för att konvertera från binärformatet ELF (Executable and Linkable Format) till IHEX behövdes.

Det första försöket att konvertera från ELF till IHEX gjordes med objcopy, som är en del av binutils. Med kommandot objcopy -O ihex in.elf out.hex returneras ett felmeddelande om att en adress är för stor för IHEX-formatet.

Ett specialanpassat verktyg kallat bin2hex distribueras med kompilatormiljön XC32, som används av Microchip Mplab X och Chipkit MPIDE. Källkoden till verktyget dis-tribueras under licensen Gnu General Public License och byggs in i källkodsträdet för binutils.

bin2hex konverterar från ELF till IHEX. Efter studier av bin2hex källkod upptäcktes det att verktyget även konverterar adresser mellan adressrymder. ELF-filen som skapas av länkaren är i den virtuella adressrymden, men IHEX-filen som beskriver avbildningen i ROM är i den fysiska adressrymden. bin2hex tar i vissa fall bort de tre översta bi-tarna i de minnesadresser som skrivs till IHEX-filen. Det beslutades därför att använda verktyget bin2hex i den framtagna utvecklingsmiljön.

Ett fåtal ändringar behövde göras till bin2hex för att använda verktyget i den skräd-darsydda utvecklingsmiljön. Först flyttades bin2hex ut från binutils källkodsträd, då källkoden för binutils laddas ner separat. En byggfil för att kompilera och länka bin2hex statiskt mot delar av binutils källkodsträd utvecklades. Några konstanter behövde bytas namn på för att bin2hex skulle kompilera med binutils version 2.25, som är nyare än den versionen använd i Microchip XC32. För att kunna kompilera på Mac OS X behövde #include <malloc.h> bytas ut mot #include <stdlib.h>.

5.1.8 Miljövariabler i utvecklingsmiljön

I utvecklingsmiljön har ett antal miljövariabler satts. Miljövariablerna innehåller re-kommenderade flaggor för C-kompilatorn, assembleraren och länkaren. Dessa flaggor försäkrar att kod byggs och länkas för rätt målplattform. Flaggorna som sätts i kompi-latormiljön listas nedan.

PATH = ${TOOLCHAIN_INSTALL_DIR}/bin

CFLAGS = -march=mips32r2 -msoft-float -Wa,-msoft-float ASFLAGS = -march=mips32r2 -msoft-float

LDFLAGS = -L ${TOOLCHAIN_INSTALL_DIR}/lib/proc C_INCLUDE_PATH = ${TOOLCHAIN_INSTALL_DIR}/include

Dessa variabler (med undantag för C_INCLUDE_PATH) refereras till i byggfilen för ett mikrokontrollerprogram. Om programmerarna för ett sådant program i byggfilerna läg-ger till egna variabler utan att skriva över tidigare så kommer dessa flaggor automatiskt att användas. Variabeln C_INCLUDE_PATH är en speciell variabel som läses direkt av GCC för extra sökvägar till globala C-huvudfiler.

En beskrivning av flaggorna i CFLAGS, ASFLAGS och LDFLAGS följer nedan.

• -march=mips32r2 - Sätter målarkitektur och därmed tillåtna processorinstruktio-ner.

• -msoft-float - Använd inte flyttalsinstruktioner, beräkna flyttal i mjukvara. Vik-tig flagga att sätta för rätt ABI, med fel ABI misslyckas länkning.

• -Wa,-msoft-float skickar flaggan -msoft-float till assembleraren genom C-kompilatorn

• -L ${TOOLCHAIN_INSTALL_DIR}/lib/proc sätter upp en sökväg för bibliotek och länkskript till länkaren.

• Konstanten ${TOOLCHAIN_INSTALL_DIR} byts ut till utvecklingsmiljöns installa-tionsmapp under installation av utvecklingsmiljön.

Alla rekommenderade standardinställningar i miljövariablerna konsoliderades till en mil-jövariabelsfil kallad environment. Denna fil kan inkluderas i kommandoskalet för att aktivera utvecklingsmiljön.

5.1.9 Paketering för distribution

Då ett av delmålen med den skräddarsydda utvecklingsmiljön var att förenkla installation och användande för studenterna valdes att paketera den färdiga utvecklingsmiljön för att enkelt kunna distribueras och installeras.

För Linux valdes att paketera distributionen i en självuppackande arkivfil baserat på

Makeself[41]. Makeself genererar ett körbart skalskript med det ihoppackade arkivet in-bäddat i skriptet. Självuppackande arkiv baserade på Makeself behöver endast systemets standardverktyg som sh, tar och bzip2 för att kunna packas upp.

För Microsoft Windows krävs att UNIX-undersystemet Msys2[40] _{först installerats.}

In-stallationen av utvecklingsmiljön sker sedan på samma sätt som för Linux, genom att köra en självuppackande arkivfil.

För Mac OS X valdes att paketera utvecklingsmiljön i för plattformen standardformatet .app, och distribuera som en diskavbildning i .dmg-format. Diskavbildningen

funge-rar som installationsfil och öppnar ett fönster där användaren kan dra applikationen pic32-toolchain till systemets applikationskatalog, vilket är ett vanligt sätt att instal-lera tredjepartsmjukvara på Mac OS X.

5.2 Konfigurationsflaggor för utvecklingsmiljön

Avsnittet beskriver de kompileringsflaggor som används för att bygga utvecklingsmil-jön. Avsnitt 5.2.1 beskriver de gemensamma kompileringsflaggor som används för alla beståndsdelar i utvecklingsmiljön. Avsnitt 5.2.2 beskriver anropskonventionerna som an-vänds för målplattformen. Avsnitt 5.2.3 beskriver kompileringsflaggorna som användes för GNU Binutils. Avsnitt 5.2.4 beskriver kompileringsflaggorna som användes för kom-pilatorn GCC. Avsnitt 5.2.5 beskriver kompileringsflaggorna som användes för program-meringsverktyget Avrdude.

5.2.1 Gemensamma konfigurationsflaggor

Några av konfigurationsflaggorna är gemensamma för flera paket och beskrivs i det här avsnittet.

• --prefix="$(PREFIX)", då samtliga komponenter skall installeras i samma ka-talog. Strängen ${PREFIX} är en variabel i byggfilen som är konfigurerbar. Stan-dardvärdet på denna är /opt/pic32-toolchain på Windows (Msys2) och Linux. På Mac OS X är standardvärdet

/Applications/pic32-toolchain.app/Contents/Resources/Toolchain. • --target=mipsel-pic32-elf beskriver målplattformen; mipsel för little-endian

MIPS, elf för att bygga binärer i formatet ELF. Utelämnas -elf byggs verktygen för flera utformat (ELF, COFF, aout), vilket är onödigt. Simplifieras mipsel till bara mips byggs verktygen för både big och little endian. Strängen pic32 är en etikett för målplattformen som saknar betydelse vid kompilering.

5.2.2 Konfiguration för målplattform utan matteprocessor

Bland olika implementationer av MIPS förekommer plattformar som har hårdvara för beräkning av flyttal (hardfloat), samt plattformar som saknar hårdvara för beräkning av flyttal (softfloat). PIC32MX faller i den senare kategorin, vilket medför att flyttals-beräkningar måste måste göras i mjukvara. På plattformar där flyttalsberäkning görs i hårdvara kan också flyttal som argument till funktioner skickas i flyttalenhetens regis-ter. Då dessa register inte finns på softfloat-plattformar finns det olika ABI (Application Binary Interface) och anropskonvenioner. Kod med olika ABI förhindras från att länkas med varandra. Av denna anledning har ett mål varit att allt skall byggas för softflo-at.

För stödbiblioteket libgcc, som byggs när GCC byggs, så kan detta åstadkommas med argument till byggskriptet configure. Standardinställningarna för den installerade kom-pilatorn har dock inte lyckats sättas korrekt Detta medför att byggflaggor för softfloat fortfarande behövs, både till C-kompilatorn och assembleraren (och till assembleraren även när C kompileras). Utelämnas flaggorna till assembleraren kommer fel ABI att byggas (hardfloat) och varningar genereras. Resultatet av utelämnade ABI-flaggor leder till att länkning med crt0 misslyckas, då crt0 byggs för softfloat. Miljöfilen som lägger till utvecklingsmiljön i $PATH med mera lägger därför till dessa flaggor för softfloat i miljövariablerna $CFLAGS och $ASFLAGS, kommandot make importerar dessa automa-tiskt.

5.2.3 Konfigurationsflaggor för binutils

För att bygga Binutils räcker det med ett fåtal extra flaggor utöver installationsmapp. Flaggorna Binutils byggs med är --target=mipsel-pic32-elf --prefix="$(PREFIX)" --with-float=soft --enable-soft-float --enable-static

• --with-float=soft --enable-soft-float aktiverar stöd för softfloat. Dessa flaggor är inte tillräckliga för att sätta softfloat till standardvalet för binutils in-stallerade verktyg.

• --enable-static får interna bibliotek för binutils att byggas som statiska. De statiska biblioteken används när komponenten bin2hex byggs, då bin2hex länkar mot Binutils källkodsträd.

5.2.4 Konfigurationsflaggor för GCC

För att bygga en användbar GCC behövs ett fåtal flaggor till konfigurationsskripet configure. Den viktigaste av dessa är att målplattformen sätts till MIPS. Resteran-de flaggor kan på vissa system vara överflödiga eller frivilliga om utvecklingsmiljön inte skall distribueras. GCC konfigureras med flaggorna --target=mipsel-pic32-elf --prefix=${PREFIX} --enable-languages=c,c++

--with-newlib --with-gnu-as --with-gnu-ld --without-headers --disable-libssp --with-float=soft --with-arch=mips32r2 --disable-multilib

• --enable-languages=c,c++ får både en C-kompilator och en C++-kompilator att byggas. Stöd för C++ är ej komplett i körstödsbiblioteket crt0, därav skulle C++-kompilatorn kunna utelämnas.

• --with-newlib indikerar för GCC att inte förvänta sig att C-biblioteket libc finns i installationsmappen. Flaggan är nödvändig då C-biblioteket libc saknas i den framtagna utvecklingsmiljön.

• --with-gnu-as, --with-gnu-ld sätter explicit att GCC byggs mot GNU:s binu-tils. Vid bygge av en korskompilator kan autodetektering använda fel assemblerare

och länkare (t.ex. värdsystemets) vid tester, därav används flaggor för att kringgå detekteringen.

• --without-headers får byggprocessen att inte anta att huvudfilerna för C-biblioteket libc finns. Då inget C-bibliotek finns i utvecklingsmiljön finns därför inte heller dess huvudfiler.

• --disable-libssp används för att inte bygga libssp, en stackskyddare (Engelska: stack protector, detekterar stackkorruption). Libssp behöver C-biblioteket libc. Libssp kan inte inkluderas i utvecklingsmiljön eftersom något C-bibliotek inte finns i utvecklingsmiljön.

• --with-float=soft sätter ABI till att använda softfloat eftersom PIC32MX inte har hårdvarustöd för flyttalsberäkning. Att utelämna den här flaggan orsakar i senare skede att libgcc byggs för hardfloat, vilket medför att libgcc inte kan an-vändas för att bygga kod med softfloat-ABI. Softfloat-ABI krävs på plattformar utan flyttalshårdvara.

• --with=arch=mips32r2 ställer in standardvärdet för målarkitektur till MIPS32r2, vilket är den variant av MIPS som används av PIC32MX-mikrokontrollers. Flaggan är inte kritiskt för att bygga utvecklingsmiljön eftersom målarkitektur kan anges när kompilatorn används.

• --disable-multilib gör att libgcc inte byggs för något annat ABI än standard-valet. Eftersom målplattformarna för den här utvecklingsmiljön alla är softfloat är det onödigt att bygga med stöd för andra ABI:er än softfloat. Skulle behov av andra ABI:er (ex. hardfloat) finnas så kan denna flagga utelämnas.

5.2.5 Konfigurationsflaggor för Avrdude

Utöver installationskatalog behöver inte Avrdude några speciella konfigurationsflaggor. Då Avrdude kan kan finnas installerat på en användares system sedan tidigare har dock en extra flagga använts för att sätta ett prefix på dess kommandonamn. Avrdude konfigu-reras med flaggorna --prefix="$(PREFIX)" --program-prefix="mipsel-pic32-elf-". Flaggan --program-prefix="mipsel-pic32-elf-" sätts för att ge binären för avrdude namnet mipsel-pic32-elf-avrdude. Utvecklingsmiljön beror på att Avrdude har detta kommandonamn för att skilja utvecklingsmiljöns version av Avrdude från en eventuell användarinstallerad.

5.3 Projektmall

Avsnittet beskriver en projektmall som utvecklades för att enkelt kunna skapa nya pro-jekt för Uno32. Propro-jektmallen för nya propro-jekt innehåller en byggfil med kompilerings-flaggor samt stubbkod. Projektmallen finns tillgänglig på Github[18]_.

Avsnitt 5.3.1 beskriver stubbkoden som alla projekt bygger på. Avsnitt 5.3.2 beskriver avbrottsvektorn. Avsnitt 5.3.3 beskriver de extra programareor som behövs i projektens binärer.

5.3.1 Stubbkod

Alla projekt som utvecklas med utvecklingsmiljön utgår från en gemensam, liten kodbas. Denna kodbas består av stubbkod innehållande avbrottsvektorer, felhanterare och en C-eller assemblerfil som innehåller symbolen main. Förutom symbolen main innehåller även stubbkoden de funktionerna _nmi_handler, _on_reset och _on_bootstrap.

Funktionen _nmi_handler anropas när processorn tar emot ett oblockerbart avbrott (NMI; Non Maskable Interrupt). Stubbkoden i funktionen ställer mikrokontrollern i en oändlig loop när ett NMI. Ett NMI förväntas inte under normal användning.

Funktionen _on_reset anropas från körstödsbiblioteket när mikrokontrollern är om-startad, men innan data- och bss-areorna finns tillgängliga. I stubbkoden är funktionen tom.

Funktionen _on_bootstrap anropas från körstödsbiblioteket när mikrokontrollern är omstartad, efter data- och bss-areorna blivit initierade. I stubbkoden är funktionen tom.

5.3.2 Avbrottsvektorer

Definition av avbrottsvektorerna sker i en egen fil för varje projekt, i detta exempel vectors.S. Förutsatt att enkelvektorsläget (single vector mode) för avbrott används behövs enbart två vektorer anges; en avbrottsvektor (__vector_0) samt undantagsvek-tor (__gen_exception). Alla avbrottsvekundantagsvek-torer ligger var för sig i en egen programarea __vector_new_* .

5.3.3 Kod och data utanför standardareorna

När hårdvara testats har små testprogram skrivits för delkomponenter var för sig. I varje delprogram definieras avbrottsvektorer som ligger i egna programareor (sections) med definierade adresser. När assemblerkod skrivs som inte skall ligga i .text eller .data måste länkskriptet veta var i ROM programarean för koden skall ligga. Avbrottsvektorerna är redan definierade, men för att dessa ska följa med till binären genom länkaren och bin2hex måste vissa attribut sättas när assemblerkod skrivs. Dessa attribut kan kan sättas vid deklaration av programarean med:

.section <section name>,"ax",@progbits

Strängen <section name> byts ut mot namnet på programarean. De viktiga bitarna är strängen ax som sätter programarean till allokerbar och körbar. Attributet @progbits

indikerar att programarean innehåller definierad data (till skillnad mot tomrum som bara har plats allokerad). Denna kombination fungerar och rekommenderas därför som en utgångspunkt.

5.4 Programmeringsutrustning

Chipkit Uno32 kommer förinstallerad med en startladdare (Engelska: bootloader). Start-laddaren möjliggör att Uno32 kan programmeras utan särskild programmeringsutrust-ning. Startladdaren är kompatibel med protokollet stk500, och programmet Avrdude kan användas för att överföra program till Uno32. Avrdude och Uno32 kommunicerar via en serieportsanslutning över USB genom att ansluta en USB-kabel mellan en dator och Uno32. Programmet Avrdude fungerar på flertalet plattformar, exempelvis Linux, Microsoft Windows och Mac OS X. Avrdude kräver en speciell konfigurationsfil för att kunna kommunicera med Uno32. Denna konfigurationsfil tillhandahålls av Chipkit och är paketerad tillsammans med MPIDE.

I de fall startladdaren saknas eller har skrivits över behöver den återställas. Starthante-raren finns att ladda ner från Chipkits hemsida[5]. För att återställa startladdaren krävs en speciell programmerare, till exempel Pickit 2 eller Pickit 3 från Microchip. PIC-programmeraren ansluts till programmeringskontakten (ICSP header; In Circuit Serial Programming) på Uno32 och använder ett särskilt program på värddatorn. Bilaga B instruerar steg för steg hur startladdaren installeras på utvecklingskortet.

Pickit 2 kan användas med kommandoradsprogrammet pk2cmd. Pickit 2 stödjer inte alla nyare PIC32-processorer, men den stödjer PIC32MX320F128H som används av Uno32. Källkoden till pk2cmd finns tillgänglig och tillhandahålls av Microchip[26]. Pk2cmd kan användas på bland annat Linux, Microsoft Windows och Mac OS X.

Pickit 3 kräver Microchips utvecklingsmiljö Mplab X. Mplab X finns tillgängligt på Linux, Microsoft Windows och Mac OS X och tillhandahålls av Microchip.

5.5 Hårdvarubyglar

Utvecklingen av temperatursensorkoden mötte problem då koden kunde hänga sig i vän-tan på svar från temperatursensorn. För att finna felet användes LED-lamporna på Basic IO Shield för att indikera status. Efter varje operation på I²C-bussen tändes en ny lampa så koden kunde undersökas steg för steg och raden som orsakade låsningen kunde iden-tifieras. Raden som orsakade låsningen var kod som väntade på att temperatursensorn skulle bekräfta en gjord busstransaktion.

Efter att noga ha läst databladet för mikrokontrollerns I²C-kontroller[30]_{, den officiella}

referensen för I²C-protokollet[36]_{samt temperatursensorns datablad}[29]_{konstaterades att}

koden var korrekt.

Vidare undersöktes hårdvaran noggrannare för att finna orsaken till problemet. Ett oscil-loskop kopplades till I²C-kontakten på Basic IO Shield. När koden som skulle

kommu-nicera med temperatursensorn kördes visade oscilloskopet inga utslag på aktivitet. Slut-satsen drogs att I²C-pinnarna inte var korrekt kopplade till mikrokontrollern. Efter att ha studerat kopplingsschemat för Uno32[9] _{konstaterades att två byglar på Uno32}

be-höver flyttas för att använda I²C. Byglarna JP6 och JP8 väljer funktionen för två av pinnarna på expansionskontakten på Uno32. Dessa två pinnar är vidare kopplade till temperatursensorn på Basic IO Shield. I standardläget är pinnarna kopplade till två av mikrokontrollerns analog- till digitalkonverterarkanaler. I det andra läget kopplas pin-narna till mikrokontrollerns I²C-modul. Efter att byglarna flyttats över till det andra läget fungerade kommunikationen med temperatursensorn korrekt.