Opinie

Wat een toestand

Leon van Snippenberg is senior softwarearchitect bij Sioux Embedded Systems.

Leestijd: 3 minuten

Binnen embedded-systeemontwikkeling hoor ik de laatste jaren steeds vaker de term statemachine. Voor veel ontwikkelaars lijkt het maken van een statemachine een doel op zich geworden. Maar ook managers lijken besmet te zijn met het virus; zij verwijzen naar commerciële tooling voor het opstellen ervan en wekken de indruk dat elk systeem bestaat uit een statemachine en meer niet. Het besef dat een statemachine te allen tijde slechts een klein deel van het totaalsysteem vormt, lijkt volledig verdwenen. Alsof de resterende 95 procent van de functionaliteit gratis en risicoloos is.

Hoe komt dit toch? Een eerste oorzaak is dat de term wordt gebruikt zonder goed besef dat er in grote lijnen minstens twee soorten statemachines zijn. De eerste soort bevat de states die voor de eindgebruiker zichtbaar zijn, de user-visible states. Hier zit niet de complexiteit. Het aantal toestanden is zeer beperkt en ze komen direct voor in de functionele beschrijving van het systeem.

Het is de tweede soort die complexiteit met zich mee brengt. Ik noem dit de implementatie-statemachine. Deze wordt gebruikt voor het verdelen van beperkte resources over functionaliteit, met name de CPU-cycli. Bewerkingen van een processor kosten nu eenmaal tijd en er is dus een mechanisme nodig om de cycli te verdelen over de functionaliteit. Een implementatie-statemachine is niks anders dan een coöperatieve scheduler, en ja, deze kunnen heel complex en groot worden zodat tooling inderdaad handig is om de correctheid te bewijzen.

This article is exclusively available to premium members of Bits&Chips. Already a premium member? Please log in. Not yet a premium member? Become one and enjoy all the benefits.

Login

Related content