Hoewel al tientallen jaren oud is de 8 bit architectuur nog springlevend. De hierop gebaseerde microcontrollers zijn meegeëvolueerd met de eisen van productontwerpers. Dit heeft extra functies opgeleverd, zoals slimme randapparaten. Deze functionaliteit komt goed van pas in moderne ‘coöperatieve’ omgevingen, waarin 8, 16, 32 en 64 bit gebroederlijk naast elkaar draaien en samen de klus klaren.
Net iets langer dan veertig jaar geleden verscheen de eerste 8 bit microcontroller op de markt. Ontwerpers zagen al snel de voordelen. Deze alles-in-ééncombinatie van een complete microprocessor, geheugen, timer en i/o-poorten maakte de componentenlijst en het ontwerp van allerlei elektronicaproducten aanzienlijk kleiner. De mcu vond al snel zijn weg in toetsenborden voor computers en vervolgens in allerhande embedded systemen.
Hoewel we inmiddels 16, 32 en zelfs 64 bit architecturen hebben, spelen 8 bit microcontrollers nog steeds een belangrijke rol. In een heleboel simpelere systemen zoals rookmelders en industriële sensormodules is het de enige via software programmeerbare component. Daarnaast draaien ze vaak gebroederlijk naast 16, 32 en 64 bit processoren om specifieke klussen op te knappen. De toetsenbordcontroller van weleer is daar een mooi voorbeeld van: de 8 bit mcu in het randapparaat zorgde ervoor dat de hoofdprocessor zich niet vele cycli lang hoefde bezig te houden met de invoerlijnen. Op een vergelijkbare manier werken in moderne mcu’s meerdere componenten naast en met elkaar om de prestaties van het gehele systeem te verbeteren.
Welke configuratie van hardwaremotoren kunnen we nu het beste kiezen voor een nieuw processorgebaseerd product? Voor een simpele rookmelder in huis lijkt het niet zo moeilijk; die heeft genoeg aan een 8 bit microcontroller om zijn software te draaien. Voor een intelligente luidspreker is het al een stuk lastiger.
Slaapstand
De eenvoudigste benadering is om een besturingssysteem de verschillende taken naast elkaar te laten draaien op een krachtige processor. Dit is echter vrijwel nooit de zuinigste aanpak omdat de uitwisseling van gegevens met de in- en uitgangen de beperkende snelheidsfactor is: bij i/o-transacties zal een 32 of 64 bit processor van 1 GHz of hoger vele cycli duimendraaien. Het gebruik van interrupts laat de processor weliswaar doorgaan met zijn kerntaken terwijl de i/o-transacties onderweg zijn, maar zorgt voor veel overhead doordat het systeem voor de contextswitch na elke interrupt de stack moet aanspreken.
Een gemiddeld iot-systeem heeft voor het grootste deel van zijn werkzame leven bovendien nauwelijks iets te doen; het merendeel van zijn functies is slechts tijdens korte pieken nodig. Een rookmelder kan volstaan met een bemonsteringssnelheid van een seconde of langzamer om vast te stellen of de luchtkwaliteit een nauwkeurigere analyse vereist; die analyse neemt normaliter slechts een fractie van een seconde in beslag, zelfs op kernen die draaien op lage megahertzsnelheden. Een slimme luidspreker hoeft de spraakherkenningstaak pas te starten zodra de microfoon een audiosignaal oppikt in het juiste frequentiebereik. In plaats van de processorkern tussen de metingen door energie te laten verspillen in een idle-lus is het beter om hem in een zuinige slaapmodus te brengen en hem pas te wekken als er een interrupt binnenkomt van een systeemklok of teller of als randapparatuur een extern event detecteert.
High-end processoren zijn onder meer zo snel doordat ze veelgebruikte instructies en data opslaan in lokale sram-caches. Dit voorkomt dat ze code moeten kopiëren van relatief langzaam flash. Om het verbruik te drukken, verliezen cachegeheugens in de slaapstand echter hun inhoud. Na een weksignaal zullen we ze eerst weer moeten vullen voordat de processor aan het werk kan, en dat vraagt energie en geeft vertraging.
De meeste 8 bit processoren laden instructies rechtstreeks uit flash. Ze hebben vaak niet-vluchtige geheugens waarin ze data tussen twee wekmomenten kunnen bewaren en hoeven hun cache daarom bijna nooit opnieuw te laden. Dit maakt dat ze beter reageren op externe gebeurtenissen ondanks dat hun piekdoorvoer een stuk lager ligt.
Cips
Het is daarom dat systeemontwerpers er vaak voor kiezen om 16, 32 of 64 processoren te combineren met 8 bit microcontrollers. Het resulterende systeem is weliswaar complexer, maar de eventafhandeling is een stuk efficiënter. In een slimme luidspreker kan een 8 bit mcu de audiosignalen voor zijn rekening nemen als het niet nodig is om spraak te verwerken. Met een paar eenvoudige algoritmes bepaalt de microcontroller eerst of het binnenkomende geluid het achtergrondniveau overstijgt en vervolgens of het ruis is dan wel eigenschappen heeft van menselijke spraak. Als dit laatste het geval is, wekt hij de primaire processor voor verdere analyse.
Deze ‘coöperatieve’ benadering stopt niet bij de processorkern. Voor de afhandeling van veel externe gebeurtenissen hebben we de flexibiliteit van software helemaal niet nodig, maar volstaan core-independent peripherals (cips). Bij de slimme luidspreker hoeft de processor bijvoorbeeld niet te bepalen of binnenkomend geluid spraakeigenschappen heeft als de microfoon alleen achtergrondgeluid van een laag niveau oppikt. In plaats daarvan kan een comparator de amplitude van het microfoonsignaal analyseren en bij overschrijding van de drempelwaarde de processor wekken.
Cips bieden een breed scala aan mogelijkheden die veel verder gaan dan analoge ingangen vergelijken met referentieniveaus. Ze kunnen combinatorische logica, toestands- en klokfuncties implementeren die we kunnen samenvoegen tot een motorregeling met vermogenssequencing, datamodulatie en signaalconditionering zonder tussenkomst van de processorkern. Er zijn er die ook een adc aan boord hebben die we kunnen uitrusten met programmeerbare triggers en andere toestandsgestuurde functies waarmee we de core nog verder kunnen ontlasten.
Een voorbeeld van een geavanceerde cip is de analog-to-digital converter with computation die op een aantal 8 bit mcu’s van Microchip zit. Deze module kan zelfstandig verschillende functies op gedigitaliseerde signalen uitvoeren, zoals middelen en een laagdoorlaatfilter toepassen. Dit voorkomt dat het systeem moet reageren op kort optredende ruis en geluidspiekjes. Daarnaast biedt de module onder meer de mogelijkheid om het signaal alvast voor te bewerken voor analyse op spraakinhoud, alsook functies om de capacitieve bediening van aanraakgevoelige schermen te vereenvoudigen – een andere toepassing waar traditioneel veel softwarematige verwerking aan te pas komt.
Efficiënter
Slimme randapparaten hebben niet alleen een gunstig effect op het energieverbruik omdat de processorkern langer in slaapstand kan blijven, maar ook op de componentenlijst. Door de extra verwerkingscapaciteit van cips kunnen we een goedkopere 8 bit microcontroller gebruiken waar een 16 bit component op het eerste gezicht de meest voor de hand liggende keuze zou zijn. In een 8 bit mcu met hardwaregebaseerde filtering hoeft de processorkern aanzienlijk minder signaalverwerking te doen en kan hij zich concentreren op beheer en besturing op systeemniveau.
8 bit microcontrollers zijn sowieso beter geschikt voor i/o-intensieve, eventgestuurde toepassingen, met hun vele taken op sub-byteniveau. Hun grotere broers verwerken deze datatypes minder efficiënt omdat ze complete datawoorden van en naar registers moeten slepen en complexe bitmaskers moeten gebruiken om de juiste inhoud te manipuleren. 8 bit mcu’s leveren precies de benodigde functionaliteit voor toepassingen die niet steeds een groot aantal berekeningen hoeven uit te voeren.
Ook springen 8 bit microcontrollers bij i/o-intensieve taken over het algemeen efficiënter om met het programma- en datageheugen en kunnen ze met minder toe dan 16, 32 en 64 bit architecturen. Bij complexere toepassingen kunnen ze juist meer geheugen nodig hebben. Dan zou een migratie naar 16 of 32 bit gerechtvaardigd zijn.
In veel gevallen is het zinvol om op zijn minst te kijken naar de combinatie van een 8 bit component afgestemd op de toepassing en een 16 of 32 bit processor voor algemeen gebruik. Zo’n coöperatieve benadering verhoogt in eerste instantie de ontwerpcomplexiteit omdat we de verschillende processorkernen en slimme randapparaten moeten synchroniseren. Er is echter prima tooling beschikbaar die ons de vereiste managementtaken op firmwareniveau uit handen neemt.
Vertaling: Johan Smilde, Goor