Op naar batterijloze IoT-apparaten: Ultralaag vermogen

Gepubliceerd op: 19 oktober 2018

Expert:

Herman Roebbers MSEE

Trainer

Lees meer over Herman Roebbers

Deel

---

Herman Roebbers is een advanced expert bij Capgemini Engineering en werkt al sinds halverwege de jaren tachtig aan embedded systemen en parallelle verwerking. Hij is ook extern adviseur van de EEMBC-werkgroepen Ulpmark, Iotmark en Securemark, en ultra-low power trainer in de workshop“Ultra-low power for the Internet of Things”.

In het streven naar batterijloos IoT is het belangrijk om zo efficiënt mogelijk met energie om te gaan. Aan de hand van een encryptiebibliotheek laat Herman Roebbers zien hoe alleen al kleine aanpassingen aan de tooling en chipinstellingen een enorme impact kunnen hebben op het verbruik.

Hoe kan ik het energieverbruik van mijn IoT-systeem verlagen naar ultralaag vermogen? Deze vraag wordt steeds relevanter nu we steeds hogere verwachtingen hebben van IoT-apparaten. Uiteindelijk is het doel dat systemen zo weinig energie nodig hebben, dat ze het kunnen oogsten uit hun omgeving en geen batterijen meer nodig hebben.

Om dit te bereiken moeten we in twee richtingen werken: de opbrengst van de oogst verhogen en het verbruik verlagen. Aan de eerste wordt gewerkt: nieuwe materialen en methoden om zonnecellen te maken en na te bewerken zorgen voor steeds hogere opbrengsten. Er wordt ook vooruitgang geboekt op het gebied van RF-energieoogst. De Delftse startup Nowi heeft bijvoorbeeld speciale chips gemaakt die hier heel goed in zijn. Verder wordt er veel onderzoek gedaan naar nieuwe materialen om temperatuurverschillen efficiënter om te zetten in energie. Ook wordt er hard gewerkt aan steeds efficiëntere converters die de geoogste energie omzetten in benodigde spanning(en) en zorgen voor efficiënte energieopslag, bijvoorbeeld in oplaadbare batterijen of supercondensatoren.

Een casestudy voor ultralaag vermogen

Een eerder artikel van Bits&Chips gaf een overzicht van alle aspecten die belangrijk zijn om energie te besparen: van chipsubstraat, transistorselectie, processorarchitectuur en de printplaat tot driver, OS, codeertools en coderingsstijlen tot de toepassing. Inmiddels is de tabel iets uitgebreid.

Een recent geval illustreert het effect van verschillende mechanismen op het energieverbruik. EEMBC heeft net een benchmark uitgebracht om de energie te bepalen die nodig is voor verschillende typische tls (transport layer security) operaties. Tls maakt deel uit van een https-implementatie en is als zodanig essentieel voor het opzetten van een veilige verbinding. De benchmark is overgezet naar een evaluatiebord dat cryptografie ondersteunt via de Arm Mbedtls bibliotheek.

We kunnen dat proces gebruiken om te laten zien wat elke optimalisatiestap oplevert. Hiervoor voeren we elke keer eerst een nulmeting uit. Het benchmarkkader gebruikt een energiemonitor van Stmicroelectronics en een Arduino Uno. De Arduino wordt gebruikt als uart-interface naar het geteste apparaat (dut, figuur 1).

Afbeelding 1: De opstelling voor het meten van stroomverbruik

We gebruiken ook de ontwikkelomgeving Atollic Truestudio 9.0.1 voor STM32, die een eigen versie van de GCC-compiler gebruikt, en de software Stm32cubemx, die (initialisatie)code voor randapparatuur kan genereren en zo de configuratie aanzienlijk vereenvoudigt.

Stap 1: Kijk naar de compilerinstellingen

Als we een nulmeting doen met een niet-geoptimaliseerde versie (instelling -O0) op 80 MHz (hoogste snelheid) en 3,0 volt, resulteert dit in een Securemark-score van 505. Als we de optimizer-instelling veranderen in -O1, maakt dit een enorm verschil: we gaan naar 1336! De optimizer instellingen voor -Og en -O2 maken niet veel verschil, maar als we naar -O3 of -Ofast gaan, gaat het nog beter: 1490.

Dit laat zien wat je kunt bereiken met alleen de compilerinstellingen. De ideale instellingen kunnen echter per functie verschillen. In ons geval is er bijvoorbeeld geen verschil tussen -O3 en -Ofast, maar dat is niet altijd het geval. Het kan dus lonen om de instellingen per functie of per bestand apart te kiezen.

Met de compilerinstellingen -O2, -O3 en -Ofast kunnen programmeerfouten optreden die niet optreden met andere instellingen. Timing kan veranderen en het is noodzakelijk om variabelen die in meerdere contexten worden gebruikt (bijv. normale en interrupt-context) als vluchtig te kwalificeren om problemen te voorkomen.

Stap 2: Kijk naar de pll

Microcontrollers hebben tegenwoordig zeer uitgebreide instellingen voor allerlei kloksignalen op de chip. Een van die instellingen betreft de frequentie vermenigvuldiger (pll). Deze kan worden gebruikt om een lage frequentie te vermenigvuldigen en te delen om allerlei andere kloksnelheden te maken.

In ons geval is de frequentie van de interne oscillator 16 MHz. Om daar 80 MHz van te maken, kunnen we het helaas niet simpelweg met vijf vermenigvuldigen. We hebben de keuze uit twee instellingen: de eerste is om te delen door 1, te vermenigvuldigen met 10 en dan te delen door 2. De tweede optie is om te delen door 2, te vermenigvuldigen met 20 en dan weer te delen door 2.

Dat geeft verschillende scores: 1462 tegen 1490. Het resultaat is in beide gevallen 80 MHz, maar de tweede methode is twee procent zuiniger. Hoe lager de klokfrequenties, hoe minder energie je verliest, en hoe eerder je de klokfrequentie verdeelt, hoe beter.

Als je genoeg tijd tot je beschikking hebt, kun je de processor ook zonder pll gebruiken, want dat is eigenlijk best een energievreter. Met de ingebouwde oscillator kunnen we een maximale frequentie van 48 MHz genereren, wat resulteert in een 4 procent hogere score. Het nadeel is dat het wat langer duurt: 80/48 = 1,66 keer langer om precies te zijn.

Het Nucleo L4A6ZG-ontwikkelbord van STMicroelectronics biedt veel hulpmiddelen om het energieverbruik te optimaliseren.

Stap 3: Schakel onnodige klokken uit

Nu we een paar dingen hebben onderzocht, kunnen we een instelling kiezen en van daaruit verder optimaliseren. We beginnen vrij conservatief: -O1 en een frequentie van 80 MHz via onze tweede pll-instelling. Dit brengt onze Securemark-score op 1336.

De volgende stap is het uitschakelen van alle overbodige klokken. In ons geval kunnen de klok naar de uart en alle i/o-poorten uitgeschakeld worden. Dit bespaart tussen de 2,5 en 2,9 mW en geeft een score van 1448. Dit kost 1448/1336 = 1,08 keer minder energie (8 procent winst).

Stap 4: De memcpy-functie optimaliseren

Tijdens het uitvoeren van cryptografische functies wordt de functie memcpy regelmatig gebruikt. Kiezen voor een geoptimaliseerde versie levert vijf procent winst op in het geval van GCC. De IAR compiler levert al een geoptimaliseerde versie. Hierdoor kunnen we onze score verhogen naar 1524. Winst: 5 procent.

Stap 5: Draai de duimschroeven vast

Nu kunnen we kijken of we het ook kunnen doen met een lage klokfrequentie. Daarmee zouden we de kernspanning kunnen verlagen. Voor onze mcu moet deze kernspanning 1,2 V zijn voor frequenties boven 26 MHz. Voor de eenvoud nemen we 24 MHz, een standaardfrequentie in het menu van de msi-oscillator, waarbij de pll uit kan blijven – nog eens 4 procent winst: 1588.

We kunnen ook testen of we de optimalisaties van de compiler veilig wat agressiever kunnen instellen. Als we -O2 gaan instellen, komen we op een score van 1691 – nog eens 6,4 procent winst.

Stap 6: Spanningen verlagen

We hebben de klokfrequentie al voorbereid om een lager kernvoltage toe te staan. Nu gaan we het daadwerkelijk instellen. Het resultaat is prachtig: 2021, bijna 20 procent winst!

De voedingsspanning kan ook iets lager zijn. We zijn begonnen met 3,0 V, maar als we naar 2,4 V gaan, geeft dat weer een verbetering van 26 procent. We kunnen zelfs nog verder gaan naar 1,8 V als dat nodig is. Dat hebben we hier niet gedaan, maar als we extrapoleren, kunnen we een verdere besparing van een derde verwachten.

Conclusie

Met een paar eenvoudige maatregelen kan het energieverbruik al drastisch worden teruggebracht tot ultralaag vermogen. In onze casestudy is een factor vijf tot zeven gemakkelijk haalbaar in vergelijking met een niet-geoptimaliseerde versie.

Ik heb me hier echter beperkt tot gereedschap en spaaninstellingen. Met aanvullende maatregelen op andere gebieden kunnen tientallen procenten extra verbetering worden bereikt. Een embedded systeem zonder batterijen ligt dus binnen handbereik.

Dit artikel is gepubliceerd door Bits&Chips.