Slutsats

kunna ersättas med bättre varianter [24]. Ett dåligt val av polynom kan göra CRC ett sämre val än Fletcher, som kräver mindre beräkningskraft[21].

3.2.5 Feldetektering stödd av hårdvara

Många mikrokontroller har inbyggt stöd för feldetektering. Om en modell till ex-empel innehåller en CAN-modul ingår de mekanismer som CAN-specifikationen anger. Andra mikrokontroller har inbyggt stöd för att åtgärda fel i Flash under körning. Vissa mikrokontrollermodeller har även en särskild CRC-modul som med hjälp av hårdvara kan utföra effektiv CRC-beräkning. [9, 10]

3.3 Slutsats

Vid uppgradering via nätverk är utformningen beroende av hårdvaran. Vissa mikro-kontroller har inbyggt stöd för uppgradering via CAN, till andra måste program skrivas. Även de mikrokontroller som har inbyggt stöd kan behöva program som gör IAP, beroende på det inbyggda stödets utformning och egenskaper.

Den metod som Cao et al. [19] utvecklat för att säkerställa att det alltid finns en fungerande version av mjukvaran har studerats. Metoden innehöll även intressanta aspekter rörande användarvänlighet.

Det skydd som finns inbyggt i CAN gör att nätverksprotokollet är mycket säkert. Sannolikheten för att ett fel inte upptäcks är mycket liten. Därför kan det antas att den data som kommer fram med CAN är felfri. Däremot finns det fortfarande risk att andra fel uppstår.

Flera varianter av feldetekteringsmekanismer studerades. Den mest effektiva av dem är CRC, som också är den metod som kräver mest beräkningskraft. Det är viktigt att ett bra polynom väljs, annars kan lika gärna Fletcher användas. Vissa mikrokontroller har inbyggt CRC-stöd, nackdelen med den lösningen är att CRC-polynomet är fast och inte kan skräddarsys efter ändamålet. Enkomplements-addition bör inte implementeras då feldetekteringen är för dålig.

Det har varit svårt att hitta akademiska artiklar om mjukvaruuppgradering av mikrokontroller. Uppgradering är befintlig teknik, det finns därför inte intresse hos forskare att skriva om det. Maxino [21] har legat till grund till graderingen av kontrollsummor och CRC. Det examensarbetet är noga utfört och visar med flera metoder hur feldetekteringsmekanismerna förhåller sig till varandra.

Då systemet för uppdatering av Plockmatics maskiner utformas är det viktigt att de slutsatser som dragits av litteraturstudien tas hänsyn till.

Kapitel 4

Utformning

Vid utformning av mjukvarunedladdning finns flera områden som är viktiga att ta hänsyn till, vilket beskrivs i detta kapitel. Inledningsvis utvecklades en första modell. Den bortser från flera begränsningar och är utarbetad som en teoretisk modell. Därefter anpassades den första modellen till vad som var praktiskt genom-förbart vid möten med ingenjörer på företaget. Den andra modellen användes sedan vid implementeringen av systemet. Kapitlet börjar med en genomgång av hårdvaruberoende faktorer.

4.1 Hårdvaruberoende faktorer

Vid programmering av mikrokontroller är många faktorer hårdvaruberoende, vilket gör att utformningen måste anpassas efter dem.

4.1.1 Uppgradering

Vid uppgradering av mikrokontroller via nätverk finns olika metoder som används i modeller från tillverkarna Renesas och NXP vilka Plockmatic använder [9, 10].

Metoderna skiljer sig åt och olikheterna beror till viss del på hårdvaruspecifika faktorer. De metoder som finns tillgängliga i Plockmatics mikrokontrollers kommer att beskrivas nedan.

NXP LPC2292

LPC2292 stöder ISP och IAP. Vid ISP startas ett laddningsprogram från start-sektorn och ny data kan skrivas över seriell kommunikation. Startstart-sektorn är en

24 KAPITEL 4. UTFORMNING

del av Flashminnet som startar när mikrokontrollern slås på. ISP kräver att hård-varan startas om, och att vissa pinnar sätts höga eller låga. Startsektorn läser av pinnarna och exekverar sedan antingen ISP-koden eller användarens program om sådant finns installerat. [9]

Mikrokontrollern har stöd för IAP då ett användarskrivet program exekveras i RAM och kopierar data från det minnet till Flash. Innan IAP kan genomföras måste sektorerna i Flash-minnet förberedas för skrivning så de inte längre skyddas. Samma förfarande gäller om sektorer ska raderas. Initiering av programöverföring från RAM till Flash sker genom att minnesadresserna till datan skrivs i särskilda register. [9]

Renesas M16C/6N

M16C/6N har flera möjligheter för mottagande av program. Förutom vanlig ISP

via seriell kommunikation finns även ISP via parallell kommunikation, då större befogenheter finns. Vid den parallella laddningen kan även startsektorn, »Boot Area«, programmeras. I startsektorn finns programmen som tar emot uppda-teringar via seriell kommunikation samt över CAN, kallat »CAN I/O Mode«. De programmen förinstalleras på Renesas-fabriken. Om startsektorn inte har installer-ats om finns de kvar. [10]

Mikrokontrollern har även två sorters IAP, kallade EW0 och EW1. Dessa kan

radera och skriva till Flash oberoende av vilket medium det nya programmet lev-ereras med. I tabell 4.1 jämförs de två metoderna. Det speciella med EW1 är att programmet inte behöver kopieras till RAM för exekvering. Detta fungerar om mikrokontrollern har en dedicerad sektor som bara innehåller uppdaterings-program. Uppdateringsprogrammet kan i så fall installera om resten av Flash. [10]

4.1.2 Feldetektering

Det förekommer att mikrokontroller har inbyggt stöd för feldetektering. Detta underlättar och kan snabba upp exekveringstiden vid till exempel användandet av kontrollsummor. Här redogörs för det stöd för feldetektering som finns i hårdvaran.

LPC2292

Den kraftfullare av mikrokontrollerna, LPC2292, har inte någon dedicerad hård-vara för feldetektering som kan anropas av användaren. Det finns inbyggda mekanis-mer, men de används endast automatiskt. Flashminnet har inbyggd Error Correc-tion Code (ECC). Med detta menas att en kontrollsumma för varje 128 bitar finns

4.1. HÅRDVARUBEROENDE FAKTORER 25

Egenskaper EW0 EW1

Arbetssätt • Standardläge • Minnesexpansionsläge • Startläge • Standardläge Minne där uppgraderings-programmet kan lagras • Användarsektorerna • Startsektorn • Användarsektorerna Minne där uppgraderings-programmet exekveras Uppgraderingsprogrammet måste flyttas till ett annat minne än Flash (t.ex. RAM) innan exekvering.

Uppdateringsprogrammet kan exekveras i

användarsektorerna. Minne som kan

skrivas om

Användarsektorerna. Användarsektorerna, utom de sektorer där uppdaterings-programmet finns lagrat.

Mjukvaru-begränsningar

• Inga begränsningar. • Program- och sektorraderings-kommandon kan inte exekveras i en sektor där uppdateringsprogrammet finns sparat.

• Kommandot »Radera alla olåsta sektorer« kan inte exekveras om sektorn med

uppdaterings-programmet är olåst. Tabell 4.1: Metoder för programmering, EW0 och EW1. Deltabell från [10].

lagrad på en separat plats i Flash som användaren inte har tillgång till. Vid varje läsning kontrolleras Flash mot kontrollsumman. Om ett bitfel upptäcks korrigeras det innan datan lämnas till processorn. Detta är transparent för användaren. [9]

M16C/6N

Den andra mikrokontrollern, M16C/6N, har inbyggt hårdvarustöd för CRC som kan anropas av användaren. Polynomet som finns i hårdvaran är x16+ x12+ x5+ 1 [10]. Polynomet kallas även CCITT-16 och är vanligt förekommande i CRC-implementationer [24]. CCITT-16 är bättre än Fletcher-16 vid ett test med slump-mässiga datamängder hela vägen upp till 65536 bitar med felfrekvens 1 · 10⁻⁵. Vid 65536 bitar har CCITT-16 en sannolikhet för oupptäckta fel på ∼ 1 · 10⁻⁶. För

26 KAPITEL 4. UTFORMNING

att jämföra med tidigare värden får CCITT-16 ∼ 1 · 10⁻¹³ vid datamängder på 2048 bitar. Dessa värden är utlästa ur diagram från [21]. Diagrammet sträck-er sig till 65536 bitar varför det inte går att veta hur polynomet betsträck-er sig vid större datamängder. Trenden i diagrammet är att avståndet mellan CCITT-16 och Fletcher ökar. CCITT-16 ligger inom två gånger det teoretiska minimumet i spannet 1015-2048 bitar [24].