Den ökande populariteten för 32-bitars MCU-enheter (microcontroller) inom inbyggnadsbranschen kommer inte som någon överraskning. Dessa funktionsrika enheter passar en rad olika tillämpningar, vilket förklarar varför många utvecklare av inbyggda produkter väljer dem för sina nästa konstruktioner. Konstruktörerna inser att sådana komplexa enheter erbjuder allt de behöver när det gäller rå beräkningskraft, en rik uppsättning kringutrustning och enkel tillgång till ett brett utbud av utvecklingsverktyg och bibliotek.
Många av dessa 32-bitarsenheter är baserade på de mycket framgångsrika ARM-kärnorna. Utvecklare kan därför känna sig trygga med att ha tillgång till andra källkodsenheter och en omfattande uppsättning utvecklings-, test- och valideringsverktyg som finns tillgängliga på marknaden.
Om man tittar närmare på de senaste trenderna på MCU-marknaden kan man dock konstatera att det inte bara är 32-bitarsenheterna som uppvisar en stark tillväxt (tabell 1). Den kraftigt växande 8-bitars MCU-marknaden har en sammansatt tillväxttakt (6,4 %) som ligger nära 32-bitarsmarknaden (6,9 %). Andra branschanalytiker förutspår identiska tillväxtsiffror för 8- och 32-bitars mikrokontroller.
Det uppsvinget för 8-bitars enheter visar tydligt att det måste finnas några övertygande skäl att använda en 8-bitars enhet i stället för en 32-bitars MCU. Den här artikeln försöker ge en inblick i varför 8-bitars enheter behåller sin marknadsandel.
Väsentliga skillnader
De principiella skillnaderna mellan 8- och 32-bitars MCU:er är kostnads- och prisstruktur, CPU-prestanda, användarvänlighet, effektivitet i hårdvarunära funktioner och statisk strömförbrukning. När utvecklare ger sig i kast med en ny konstruktion måste de noggrant utreda kraven på en MCU utifrån den mängd bearbetningskapacitet som krävs, graden av gränssnitt som behövs och, för batteridrivna konstruktioner, de mycket viktiga strömförbrukningsprofilerna. Det råder ingen tvekan om att en 32-bitars MCU ger högre prestanda än en 8-bitars enhet, men ingenjören står inför det traditionella beslutet att välja mellan den bästa tillgängliga enheten på marknaden och applikationens faktiska behov.
Självklart kommer dessa beslut att i hög grad påverka den troliga materialkostnaden (BOM). Med ett lägre antal grindar kommer en mindre komplex 8-bitarsenhet säkerligen att vara billigare än en 32-bitarsenhet. När man jämför 8- och 32-bitars MCU:er från ledande leverantörer, var och en med liknande mängd flashminne, pin-out etc., kostar 8-bitars enheter vanligtvis cirka 20 % mindre. Men detta är bara det första av många överväganden. En annan aspekt gäller hur lätt det är att ställa in en ny utveckling.
Enklare utveckling
MCU-leverantörer tenderar att lägga till fler funktioner och funktionalitet till sina 32-bitars enheter jämfört med 8-bitars produkter. Följaktligen uppstår betydligt fler inställningsöverväganden med en mer komplex enhet. Även om vissa 32-bitars MCU:er kan köras med en begränsad inställning som liknar den för en 8-bitars enhet, kan du inte dra nytta av den kraftfullare enhetens ytterligare funktioner.
 |
Ladda ner denna artikel i .PDF-format Denna filtyp innehåller högupplöst grafik och scheman i förekommande fall. |
En typisk 32-bitars ARM-enhet har till exempel oberoende klockinställningar för själva kärnan, AHB-bussen, APBA-bussen och APBB-bussen. De kan alla ställas in på olika frekvenser. Typiskt sett måste du också växla till den klocka du vill använda eftersom den är inställd i mjukvara, inte i hårdvara som de flesta 8-bitarsdelar. Att ändra klockan innebär dessutom att du måste ställa in väntetillstånden för flash, eventuellt med utgångspunkt i uppmätt VCC-spänning.
En sådan inställning kan dock vara mycket enklare med en 8-bitars MCU. Till exempel kräver Atmels tinyAVR- och megaAVR-produkter endast initialisering av stackpekaren, vilket vanligtvis tar fyra rader kod, innan programmet kodas. Valet av klocka, brownout-detektor, reset-pinnfunktion etc. är alla förprogrammerade i enheten.
Arkitekturen är också mycket mer okomplicerad än en 32-bitarsenhet med interna register, kringutrustning och SRAM som alla är mappade på samma databuss. Periferierna och CPU:n skulle normalt sett köras med samma frekvens, så ingen konfiguration av periferibussen är nödvändig. Dessutom kan konstruktörerna slippa oroa sig för latenstid vid synkronisering mellan olika klockdomäner.
Prestanda
När det gäller önskad CPU-prestanda bör konstruktören överväga alla användningsfall. Verkligheten är att många inbyggda konstruktioner inte har höga krav på beräkningskapacitet. Ofta krävs mycket lite hantering av data, så det blir avgörande att balansera dessa behov mot kraven på strömförbrukning och gränssnitt för kringutrustning.
En enkel termostattillämpning kommer till exempel att tillbringa större delen av sin livstid i ett viloläge. Då och då kommer den att vakna upp och mäta temperaturen och sedan fatta ett beslut om att slå på/av ett relä eller skicka en instruktion till en värdstyrenhet. Sedan fortsätter den att sova. Beräknings- och gränssnittskraven för den här tillämpningen är små, men många andra tillämpningar, t.ex. brandvarnare, elverktyg, flödesmätare och apparatkontroller, har också en liknande användningsprofil.
Effektivitet av hårdvarunära funktioner
Många moderna mikrokontroller innehåller vissa hårdvarufunktioner som tjänar till att hjälpa CPU:n att arbeta så effektivt som möjligt. I Atmels fall har både de 8-bitars AVR- och 32-bitars ARM-baserade MCU-familjerna Peripheral Event System. Ett händelsesystem är en uppsättning hårdvarubaserade funktioner som gör det möjligt för kringutrustning att interagera utan att CPU:n ingriper. Det gör det möjligt för periferier att skicka signaler direkt till andra periferier, vilket garanterar en kort och 100 % förutsägbar svarstid.
När man utnyttjar händelsesystemets möjligheter fullt ut kan chipet konfigureras så att det utför komplexa operationer med mycket lite ingripande från CPU:n, vilket sparar både värdefullt programminne och exekveringstid. När det gäller att upptäcka en hårdvaruhändelse är det viktigt att först upptäcka händelsen och sedan växla kontrollen till den önskade avbrottsservicerutinen (ISR).
I dessa situationer är CPU-hastigheten inte den enda avgörande faktorn. Det är en fråga om hur lång tid, i form av cykler, det tar att svara på avbrottet, köra ISR:n och återvända. Som följande exempel kommer att visa kan 8-bitars enheter vara effektivare när det gäller att hantera hårdvarunära åtgärder.
Tänk på att ta emot en byte på SPI, använda ett avbrott för att detektera den och sedan köra en enkel ISR-rutin för att läsa byten från SPI-periferin och lagra den i SRAM. Med hjälp av detta scenario kan man i tabell 2 göra jämförelser mellan en Atmel 8-bitars AVR-enhet och en Atmel ARM Cortex M0+-baserad 32-bitars MCU. Resultaten är beräknade med tillgänglig information och baseras på minimala implementeringar. Ingenjörer bör dock kontrollera sina egna tillämpningar eftersom avbrottsdetektering och återgång från avbrott kan ta fler cykler än vad som visas i tabellen. Att kräva 12 cykler jämfört med 33 cykler motsvarar att ha en teoretisk maximal SPI-bandbredd på 1,67 MB/s för 8-bitars-CPU:n och en bandbredd på 606 kB/s för en 32-bitars-CPU när den körs vid 20 MHz.
Graden av numerisk bearbetning kan också ha en inverkan på stacken och det nödvändiga minnet. Att tillämpa Fibonacci-algoritmen är en särskilt bra metod för att testa minneskrav. Eftersom den endast använder en lokal variabel måste allting skjutas till stacken.
När man gör en jämförelse mellan en 8-bitars AVR och en ARM 32-bitars CM0+-baserad enhet, och använder en rekursiv Fibonacci-algoritm med 15 steg, använder AVR sammanlagt 70 byte stack, inklusive 30 byte för returstack (15 anrop djupt). Den ARM-baserade enheten använder 192 bytes (60 bör vara returstapeln). Detta innebär att CSTACK är mer än tre gånger så stor som 8-bitarslösningen. I typisk C-kod kommer fler av variablerna på stacken ofta i ett packat format, så detta är ett extremt hörn. Att säga att det behövs 1,5 till 3 gånger mer SRAM för samma 8-bitarscentrerade applikation på en 32-bitars (jämfört med en inhemsk 8-bitars) enhet är dock en rättvis uppskattning.
Effektförbrukning
Ingen MCU-artikel skulle vara komplett utan att undersöka den statiska effektförbrukningen. Enbart detta kan vara en nyckelfaktor vid valet mellan en 8- eller 32-bitarsenhet, särskilt för batteridrivna tillämpningar. Tabell 3 illustrerar skillnaderna i strömförbrukning mellan 8- och 32-bitars enheter i både aktivt och statiskt läge.
Aggressiv tillverkningsteknik ökar transistorernas läckström, som ungefär fördubblas med varje processgeneration och är proportionell mot antalet grindar. Läckströmmen ökar exponentiellt vid högre temperaturer, vilket lätt kan förbises när man utformar en konsumentkonstruktion. Mobiltelefoner och personliga mediaspelare transporteras överallt, och som vi alla har upptäckt kan de temperaturer som upplevs under sommaren inne i en bil lätt stiga över 40 °C.
Mängden tid som mikrokontrollern kommer att tillbringa i aktivt läge jämfört med statiskt läge bidrar i hög grad till den totala effektbudgeten för applikationen.
Naturligtvis kommer förhållandet mellan aktivt och statiskt läge att variera beroende på applikationskraven. Om man tar det tidigare exemplet med SPI-avbrottet (tabell 2, igen) och antar en SPI-databandbredd på 80 kb/s, kommer 8-bitars-CPU:n att tillbringa 1,2 % av sin tid i aktivt läge jämfört med 32-bitars-CPU:n, som kommer att tillbringa 3,3 % i aktivt läge (tabell 4).
Slutsats
Om man funderar på om man ska använda en 8- eller 32-bitars mikrokontroller för en framtida konstruktion kan det handla om en sakernas internet-applikation. Hur IoT faktiskt tar form väcker många diskussioner, men det kommer säkerligen att utmana ingenjörer att göra en detaljerad bedömning av MCU-kravet. Trådlös anslutning, särskilt ZigBee, kommer också att vara en viktig komponent, men det betyder inte automatiskt att det behövs en enhet med högre effekt.
|
Ladda ner denna artikel i .PDF-format Denna filtyp innehåller högupplöst grafik och scheman i förekommande fall. |
Ett antal tillgängliga 8-bitars mikrokontrollerprodukter tillgodoser behovet av låga bearbetningsnivåer och trådlös anslutning. Ett sådant exempel är Atmels ATmegaRFR2-serie, som erbjuder en IEEE 802.15.4-kompatibel, trådlös 2,4 GHz-mikrokontroller-lösning i ett enda chip som passar för batteridrivna, billiga IoT-konstruktioner.
Ingar Fredriksen, Atmels marknadsdirektör för MCU:er i EMEA-regionen, är baserad i Trondheim, Normay. Han har en kandidatexamen i elektroteknik från Trodheim University College.
Paal Kastnes personalingenjör i MCU Applications-teamet som specialiserar sig på att utbilda Atmels personal och kunder i att använda Atmels mikrokontroller och verktyg, är också baserad i Trondheim. Han fick sin kandidatexamen i elektroteknik från Trondheim University College.