Warning: Undefined array key "bio" in /home/techwatch/domains/test.bits-chips.nl/public_html/wp-content/plugins/wpcodebox2/src/Runner/QueryRunner.php(126) : eval()'d code on line 13
Warning: Undefined array key "bio" in /home/techwatch/domains/test.bits-chips.nl/public_html/wp-content/plugins/wpcodebox2/src/Runner/QueryRunner.php(126) : eval()'d code on line 13
Author:
Reading time: 7 minutes
Softwareontwikkelaars kunnen het energieverbruik van hun code hooguit indirect bepalen aan de hand van de processoractiviteit. Het verbruik van externe hardware, de gevolgen van low-power-toestanden en andere overwegingen worden hierin niet meegenomen. IAR beschrijft een manier om de code direct te correleren met het verbruik van een totaal systeem en bespreekt verschillende mogelijkheden om de software te optimaliseren voor stroomverbruik.
Of het nou om medische systemen gaat, consumentenelektronica, domotica of andere embedded-segmenten, de levensduur van de batterij speelt vaak een sleutelrol. En hoewel het de hardware is die energie verstookt, is het de software die bepaalt hoe deze wordt ingezet. Power-debugging is een aanpak om inzichtelijk te maken hoe de software-implementatie het stroomverbruik op microcontrollerniveau beïnvloedt. Het stroomverbruik van het bordje en de instructiesequentie van de software worden tegelijkertijd vastgelegd en met elkaar gecorreleerd. Met deze gegevens in de hand kunnen we het energieverbruik testen en afstemmen.
De grootste moeilijkheid hierbij is de nauwkeurigheid. In het ideale geval bemonsteren we het stroomverbruik met dezelfde frequentie als de systeemklok. In de praktijk vervuilen de capaciteiten van het elektrische circuit dergelijke metingen te veel om een betrouwbaar profiel te kunnen opstellen.
Vanuit de programmeur gezien, is het echter niet zo belangrijk om het stroomverbruik te koppelen aan individuele instructies. Interessanter is om specifieke gebeurtenissen in de broncode te kunnen correleren aan het verbruik. In de praktijk is het dus geen probleem als de resolutie lager ligt dan één meting per instructie.
De sleutel tot nauwkeurige power-debugging is om de juiste correlatie te maken tussen de instructietrace en de metingen van het verbruik. De in-circuit probe van IAR gebruikt de spanningsval over een weerstandje in serie met de voeding van het device om de stroom te meten. Met een differentiële versterker en een AD-converter wordt deze spanningsval bemonsterd. Hierdoor kunnen we het verbruik overal op het bordje bepalen.
Deze stroommetingen zijn het beste te correleren wanneer de complete instructietrace beschikbaar is zoals bij Arm-microcontrollers met ETM (Embedded Trace Macrocell). Niet alle MCU‘s beschikken echter over deze functionaliteit, en bovendien is er een speciale debugprobe voor nodig. Een alternatief is daarom om de DWT-module (Data Watchpoint and Trace) in Cortex-M3- en M4-cores te gebruiken om de programme counter (PC) te bemonsteren. Dit is weliswaar minder nauwkeurig, maar biedt nog altijd voldoende correlatie. De DWT registreert de PC periodiek met snelheden tot vijftigduizend keer per seconde en zorgt er via de ITM (Instruction Trace Macrocell) voor dat elke meting van een tijdstempel wordt voorzien. Hierdoor kan de debugger de stroomverbruiksgegevens op dezelfde tijdas weergeven als interruptlogs en variabelenplots, en daarmee het energieprofiel koppelen aan de broncode.
Door de stroombemonstering te combineren met functieprofiling is het verbruik per functie te bepalen. Dit maakt inzichtelijk waar het programma na een bepaalde stimulus de meeste tijd doorbrengt, en waar de winst voor energieoptimalisatie te halen valt.
Elegant geïmplementeerd
Optimaliseren voor stroomverbruik lijkt in de eerste plaats sterk op optimaliseren voor snelheid. Embedded toepassingen hebben de neiging om de meeste tijd door te brengen met wachten: op gegevens van een seriële poort, op het veranderen van een I/O-pin, op het verstrijken van een pauze. Door een low-power-modus te gebruiken tijdens het wachten in plaats van de processor door te laten draaien, kunnen we de levensduur van de batterij met ordegroottes verbeteren. Hoe sneller een taak dus wordt uitgevoerd, hoe langer de microcontroller in low-power kan doorbrengen.
Een veelgemaakte vergissing die tot onnodig energieverbruik leidt, is om via een loop op een statusverandering van bijvoorbeeld een peripheral te wachten. Een vergelijkbare fout is om een pauze in te stellen via een aftel-loop (i = 10000; do i–; while (i != 0);). De CPU is dan intensief bezig met het uitvoeren van instructies terwijl we er niks mee bereiken.
In deze gevallen kunnen we het stroomverbruik met een paar codeaanpassingen minimaliseren. Pauzes kunnen we implementeren met een hardwaretimer; na het instellen gaat de CPU in slaapstand totdat de timerinterrupt hem weer wekt. Wachten op een toestandsverandering kunnen we vaak beter doen met interrupts, en anders kunnen we een timer gebruiken om de status periodiek te testen en tussendoor te slapen.
Het kan erg lastig zijn om dit soort fouten boven water te krijgen, ook met power-debugging. Een mogelijke aanpak hiervoor is om met de verschillende power-debugvensters het verbruiksprofiel van de toepassing te leren kennen, zodat afwijkend gedrag eruit springt. En met behulp van een RTos kunnen we het stroombeheer elegant implementeren, via een taak met de laagste prioriteit. Wanneer alle andere taken zijn volbracht, komt deze in actie en brengt de processor in low-power-stand.
Extra kloktikken
Naast het optimaliseren van de slaaptijd zijn er allerlei andere punten waarop we het energieverbruik kunnen verbeteren. Vaak gaat het dan om het afstemmen van hoe de hardware wordt aangesproken.
In embedded systemen nemen de peripherals een groot deel van de stroomconsumptie voor hun rekening, en de software bepaalt hoe ze worden gebruikt. Microcontrollers hebben meestal verschillende besparingsstanden waarin delen van het IC kunnen worden uitgeschakeld. De oscillator kan bijvoorbeeld worden teruggeschroefd in frequentie of helemaal uitgezet, peripherals en timers zijn uit te schakelen en de CPU kan stoppen met het uitvoeren van instructies. Een power-debugtool kan van pas komen om de effecten van verschillende energiestanden te vergelijken.
Vergelijkbaar hiermee is de inzet van DMA. Traditioneel wordt dit gebruikt om gegevensuitwisseling met het geheugen te versnellen, maar MCU-fabrikanten hebben ook een waaier aan DMA-technieken ontwikkeld voor flexibiliteit en stroomverbruik. Bij sommige architecturen kunnen we de CPU zelfs in slaapstand brengen tijdens een DMA-overdracht. Met power-debugging kunnen we experimenteren met verschillende DMA-technieken en direct zien wat de effecten zijn ten opzichte van een traditionele CPU-gestuurde aanpak.
In eventgestuurde systemen kan het gebeuren dat een taak met een peripheral bezig is wanneer er een interrupt inbreekt en een nieuwe taak start. De peripheral zal dan actief blijven en energie verbruiken, ook wanneer dat niet nodig is voor de nieuwe taak. Dit soort situaties zijn bijzonder lastig te identificeren, maar power-debugging kan helpen. Wel moeten we natuurlijk onderzoeken of de energiebesparing van de tijdelijke uitschakeling van de peripheral opweegt tegen de extra kloktikken die hiermee gemoeid zijn.
De helft van de tijd slapen
Een recente ontwikkeling in de MCU-industrie is de mogelijkheid om de interne voedingsspanning voor de processor aan te passen vanuit de software. Dit is vergelijkbaar met technologieën als Intels Speedstep die in desktop- en mobiele processoren al langer gebruikelijk zijn. De mogelijkheid om de voltagefactor van de vergelijking te beïnvloeden, opent nieuwe wegen voor het afstemmen van het stroomverbruik.
Voedingsspanning en frequentie bieden dankbare aanknopingspunten voor optimalisatie. Het verbruik van een MCU wordt in theorie bepaald door de formule P = f · U2 · k, waarin f de kloksnelheid is, U de voedingsspanning en k een constante. Er is bijvoorbeeld een device op de markt waarin we Vcore kunnen verlagen van 1,8 naar 1,2 volt wanneer we de kloksnelheid op maximaal 4 MHz instellen. Stel dat we de frequentie terugschroeven van 32 naar 4 MHz, dan levert dat een factor acht besparing op. Verlagen we de voedingsspanning tegelijk van 1,8 naar 1,2 volt, dan halen we zelfs een besparing met een factor achttien.
Met power-debugging kunnen we nagaan of het device zich volgens de voorspelling gedraagt. Een systeem dat bijna geen tijd in slaapstand doorbrengt op 50 MHz zou bijvoorbeeld de helft van de tijd moeten slapen op 100 MHz. Mochten er niet-lineariteiten zijn, dan geeft de tool inzicht in de optimale kloksnelheid.
Om zwevende inputs te vermijden, verbinden we ongebruikte I/O-pinnen van de MCU doorgaans met de aarde. Wanneer we zo‘n pin per ongeluk configureren als een ’logische 1‘-output, dan kan een stroom van wel 25 mA weglekken. Een vergelijkbare situatie doet zich voor wanneer de I/O-pin als input moet werken en verbonden is met extern circuit, maar geconfigureerd wordt als output.
Met een stroomgrafiekje kunnen we de onverwachte piek eenvoudig ontdekken. Op een vergelijkbare manier zal de verbruiksgrafiek van de opstartfase de foutieve initialisatiecode onthullen.
Kandidaat voor ruis
Naast verbruiksoptimalisatie is er nog een ander gebied waarbij power-debugging van pas kan komen. Het combineren van analoge en digitale circuits op een bordje brengt zijn eigen uitdagingen met zich mee. Layout en routering worden ineens belangrijk om de analoge ruis laag te houden. Een goed mixed-signal-ontwerp vraagt dan ook om uitgebreide overwegingen en de juiste kennis van de hardware. Maar ook de software kan de kwaliteit van de analoge metingen beïnvloeden. Intensief I/O-verkeer ten tijde van de analoge meting is een kandidaat voor ruis in de AD-converter.
Power-debugging kan helpen bij het onderzoeken van interferentie tussen de analoge delen en de voedings- en digitale lijnen. Interruptactiviteit kan samen met stroomdata worden getoond, dus hiermee is de elektrische activiteit rondom de AD-converterinterrupts in beeld te brengen. Stroompieken ten tijde van conversies kunnen we zodoende snel opsporen en linken aan de broncode.
Het correleren van stroomverbruik aan de software biedt nieuwe kansen om onze code door te lichten voor energieverbruik. Typisch zal het gaan om kansen om het hardwaregebruik af te stellen of mogelijkheden om de code te optimaliseren. Soms zullen ook gewoon ordinaire stroomverslindende bugs boven water komen.
