Den stigende popularitet af 32-bit mikrocontroller-enheder (MCU’er) i det indlejrede samfund kommer ikke som nogen overraskelse. Disse funktionsrige enheder passer til en lang række forskellige applikationer, hvilket forklarer, hvorfor mange embedded-udviklere vælger dem til deres næste design. Designere erkender, at sådanne komplekse enheder tilbyder alt, hvad de har brug for i form af rå regnekraft, et rigt periferisæt og nem adgang til en bred vifte af udviklingsværktøjer og biblioteker.
Mange af disse 32-bit-enheder er baseret på de meget succesfulde ARM-kerner. Udviklerne føler sig således trygge ved at have adgang til enheder med anden kildekode og et omfattende sæt af udviklings-, test- og valideringsværktøjer, der er tilgængelige på markedet.
Hvis et nærmere kig på de seneste tendenser på MCU-markedet afslører imidlertid, at 32-bit-enheder ikke er de eneste, der oplever en stærk vækst (tabel 1). Det kraftigt voksende 8-bit MCU-marked kan prale af en sammensat vækstrate (6,4 %), der ligger tæt på 32-bit-markedet (6,9 %). Andre brancheanalytikere forudser identiske vækstrater for 8- og 32-bit mikrocontrollere.
Den stigende efterspørgsel efter 8-bit enheder understreger klart, at der må være nogle tvingende grunde til at bruge en 8-bit enhed i stedet for en 32-bit MCU. Denne artikel søger at kaste et indblik i, hvorfor 8-bit enheder bevarer markedsandele.
Væsentlige forskelle
De principielle forskelle mellem 8- og 32-bit MCU’er er omkostnings- og prisstruktur, CPU-ydelse, brugervenlighed, effektivitet i hardware-nære funktioner og statisk strømforbrug. Når udviklerne går i gang med et nyt design, skal de omhyggeligt afgrænse kravene til en MCU ud fra den nødvendige behandlingskapacitet, graden af den nødvendige grænseflade og, for batteridrevne designs, de meget vigtige strømforbrugsprofiler. Der er ingen tvivl om, at en 32-bit MCU leverer en højere ydelse end en 8-bit enhed, men ingeniøren står over for den traditionelle beslutning om at vælge mellem den bedste tilgængelige enhed på markedet og applikationens faktiske behov.
Selvfølgelig vil disse beslutninger i høj grad påvirke de sandsynlige bill of materials (BOM)-omkostninger. Med et lavere antal porte vil en mindre kompleks 8-bit enhed helt sikkert være billigere end en 32-bit enhed. Når man sammenligner 8- og 32-bit MCU’er fra førende leverandører, hver med samme mængde flash-hukommelse, pin-out osv., koster 8-bit-enheder typisk ca. 20 % mindre. Men dette er kun den første af mange overvejelser. Et andet aspekt vedrører, hvor let det er at sætte en ny udvikling op.
En let udvikling
MCU-leverandører har en tendens til at tilføje flere funktioner og funktionalitet til deres 32-bit-enheder i modsætning til 8-bit-produkter. Som følge heraf opstår der langt flere opsætningsovervejelser med en mere kompleks enhed. Mens nogle 32-bit MCU’er kan køre med en begrænset opsætning svarende til en 8-bit enhed, kan du ikke drage fordel af de mere kraftfulde enheders ekstra funktioner.
 |
Download denne artikel i .PDF-format Denne filtype indeholder grafik og diagrammer i høj opløsning, når det er relevant. |
En typisk 32-bit ARM-enhed vil f.eks. have uafhængige clockindstillinger for selve kernen, AHB-bussen, APBA-bussen og APBB-bussen. De kan alle være indstillet til forskellige frekvenser. Typisk skal du også skifte til det clock, du vil bruge, fordi det er indstillet i software og ikke i hardware som de fleste 8-bit dele. Desuden betyder ændring af uret, at du skal opsætte wait states for flash, eventuelt forudsagt på målt VCC-spænding.
Sådan en opsætning kan dog være meget enklere med en 8-bit MCU. For eksempel kræver Atmels tinyAVR- og megaAVR-produkter kun initialisering af stack-pointeren, som typisk tager fire linjer kode, før programmet kodes. Valget af clock, brownout-detektor, reset-pin-funktion osv. er alle forprogrammeret i enheden.
Arkitekturen er også meget mere ligetil end en 32-bit-enhed med interne registre, periferiudstyr og SRAM, der alle er kortlagt på den samme databus. Periferierne og CPU’en vil normalt køre med samme frekvens, så det er ikke nødvendigt at konfigurere periferibussen. Desuden kan designerne undgå at bekymre sig om latenstid ved synkronisering mellem forskellige clockdomæner.
Performance
Når det drejer sig om den ønskede CPU-ydelse, bør ingeniøren overveje alle anvendelsestilfælde. Virkeligheden er, at mange indlejrede designs ikke har høje krav til beregning. Ofte kræves der kun meget lidt manipulation af data, så det bliver afgørende at afveje disse behov mod kravene til strømforbrug og periferiinterfacing.
For eksempel vil et simpelt termostatprogram tilbringe det meste af sin levetid i dvaletilstand. En gang imellem vil den vågne op og måle temperaturen og derefter træffe en beslutning om at tænde/slukke et relæ eller sende en instruktion til en værtscontroller. Derefter vil den genoptage dvaleperioden. Beregnings- og grænsefladekravene i denne applikation er små, men mange andre applikationer som f.eks. branddetektorer, elværktøj, flowmålere og apparatstyring har også en lignende brugsprofil.
Effektivitet af hardware-nære funktioner
Mange moderne mikrocontrollere indeholder nogle hardwarefunktioner, der tjener til at hjælpe CPU’en til at fungere så effektivt som muligt. I Atmels tilfælde er både de 8-bit AVR- og 32-bit ARM-baserede MCU-familier med 8-bit AVR- og 32-bit ARM-baserede MCU’er udstyret med Peripheral Event System. Et hændelsessystem er et sæt hardwarebaserede funktioner, der gør det muligt for perifere enheder at interagere uden indgriben fra CPU’en. Det gør det muligt for perifere enheder at sende signaler direkte til andre perifere enheder, hvilket sikrer en kort og 100 % forudsigelig responstid.
Når event-systemets muligheder udnyttes fuldt ud, kan chippen konfigureres til at udføre komplekse operationer med meget lidt indgriben fra CPU’en, hvilket sparer både værdifuld programhukommelse og eksekveringstid. Ved registrering af en hardwarehændelse er det vigtigt først at registrere hændelsen og derefter skifte kontrol til den ønskede interrupt service rutine (ISR).
I disse situationer er CPU-hastigheden ikke den eneste afgørende faktor. Det er et spørgsmål om, hvor lang tid, i form af cyklusser, det tager at reagere på afbrydelsen, køre ISR’en og vende tilbage. Som det følgende eksempel vil vise, kan 8-bit enheder være mere effektive til at håndtere hardware nær handlinger.
Overvej at modtage en byte på SPI, brug en afbrydelse til at registrere den og kør derefter en simpel ISR-rutine for at læse byten fra SPI-periferien og gemme den i SRAM. Ved hjælp af dette scenarie er der i tabel 2 foretaget sammenligninger mellem en Atmel 8-bit AVR-enhed og en Atmel ARM Cortex M0+-baseret 32-bit MCU. Resultaterne er beregnet på grundlag af de tilgængelige oplysninger og er baseret på minimumsimplementeringer. Ingeniører bør dog kontrollere deres egne applikationer, da afbrydelsesdetektion og tilbagevenden fra afbrydelsen kan tage flere cyklusser end vist i tabellen. Hvis der kræves 12 cyklusser mod 33 cyklusser, svarer det til at have en teoretisk maksimal SPI-båndbredde på 1,67 MB/s for 8-bit CPU’en og en båndbredde på 606 kB/s for en 32-bit CPU, når den kører ved 20 MHz.
Graden af numerisk behandling kan også have en indvirkning på stakken og den nødvendige hukommelse. Anvendelse af Fibonacci-algoritmen er en særlig god metode til at teste hukommelsesbehovet. Da den kun bruger en lokal variabel, skal alt skubbes til stakken.
Ved en sammenligning mellem en 8-bit AVR og en ARM 32-bit CM0+-baseret enhed og ved brug af en rekursiv 15-trins Fibonacci-algoritme bruger AVR’en i alt 70 bytes stak, herunder 30 til returstakken (15 kald dybt). Den ARM-baserede enhed bruger 192 bytes (60 skal være returstack). Det betyder, at CSTACK’en er mere end tre gange så stor som 8-bit-løsningen. I typisk C-kode kommer flere af variablerne på stakken ofte i et pakket format, så dette er et ekstremt hjørne. Men at sige, at der er behov for 1,5 til 3 gange mere SRAM til den samme 8-bit-centrerede applikation på en 32-bit (i forhold til en native 8-bit) enhed, er et rimeligt skøn.
Effektforbrug
Ingen MCU-artikel ville være komplet uden at undersøge det statiske effektforbrug. Alene dette kan være en nøglefaktor ved valget mellem en 8- eller 32-bit enhed, især for batteridrevne applikationer. Tabel 3 illustrerer strømforbrugsforskelle mellem 8- og 32-bit enheder i både aktiv og statisk tilstand.
Aggressive fremstillingsteknologier øger transistorlækstrømmen, som omtrent fordobles med hver procesgeneration, og som er proportional med antallet af gates. Lækagestrømmen stiger eksponentielt ved højere temperaturer, hvilket let kan overses, når der designes et forbrugerdesign. Mobiltelefoner og personlige medieafspillere transporteres overalt, og som vi alle har fundet ud af, kan de temperaturer, der opleves om sommeren inde i en bil, let stige over 40 °C.
Mængden af den tid, som mikrocontrolleren vil tilbringe i aktiv tilstand kontra statisk tilstand, bidrager væsentligt til det samlede strømbudget for applikationen.
Naturligvis vil forholdet mellem aktiv og statisk tilstand variere afhængigt af applikationskravene. Hvis man tager det tidligere SPI-interrupt-eksempel (tabel 2, igen) og antager en SPI-databåndbredde på 80 kb/s, vil 8-bit CPU’en bruge 1,2 % af sin tid i aktiv tilstand sammenlignet med 32-bit CPU’en, som vil bruge 3,3 % i aktiv tilstand (tabel 4).
Slutning
Overvejelser om, hvorvidt der skal anvendes en 8- eller 32-bit mikrocontroller til et fremtidigt design, kan omfatte en Internet of things (IoT)-applikation. Hvordan IoT faktisk tager form provokerer masser af debat, men det vil helt sikkert udfordre ingeniører til at foretage en detaljeret vurdering af MCU-kravet. Trådløs konnektivitet, især ZigBee, vil også være en væsentlig komponent, men det betyder ikke automatisk, at det vil kræve en enhed med højere effekt.
|
Download denne artikel i .PDF-format Denne filtype indeholder grafik og diagrammer i høj opløsning, når det er relevant. |
En række tilgængelige 8-bit mikrocontrollerprodukter opfylder behovet for lave niveauer af behandling og trådløs tilslutning. Et eksempel herpå er Atmels ATmegaRFR2-serie, som giver en IEEE 802.15.4-kompatibel, trådløs 2,4 GHz-mikrocontroller-løsning med en enkelt chip, der passer til batteridrevne, billige IoT-designs.
Ingar Fredriksen, Atmels MCU-marketingdirektør for EMEA-regionen, er baseret i Trondheim, Normay. Han har en bachelorgrad i elektroteknik fra Trodheim University College.
Paal Kastnes personaleingeniør i MCU-applikationsteamet, der har specialiseret sig i uddannelse af Atmel-medarbejdere og kunder i brugen af Atmels mikrocontrollere og værktøjer, er også baseret i Trondheim. Han har en bachelorgrad i elektroteknik fra Trondheim University College.