Embeddedutveckling, nya vindar. 08/09/2015

Du sitter vid din plats. Framför dig finns en utredning som pågått inom företaget med ett förord av VD. Företaget behöver förnya sig. Produkterna behöver tas in i framtiden. De ska kopplas upp och prata med 'molnet'. Din uppgift: Genomför.

Så var börjar man? Vad är viktigt? Vad är 'molnet'? Ert företag tillverkar prylar. Det kan vara för industri, det kan vara komponenter. En del standard, en del kundanpassat. Ni är inte främmande för mjukvara eller elektronik. Det sitter en del mikrokontrollers i vissa produkter. Än så länge har det kunnat hållas relativt enkelt då det inte pratar med andra delar.

En sak som nu kommer hända. Ska man prata med molnet, så behöver man ha nätverk. Någonstans längs med vägen kommer en nätverksstack komma in som pratar TCP/IP och en del andra protokoll. Inte nödvändigtvis i mikrokontrollern, men troligtvis. Och med längre beräknad livslängd på produkten, mer mer troligt att protokollstacken behövs där. Till detta diverse protokoll, stöd för att hitta rätt motpart i molnet att prata med, säkerhet, identiteter på saker och människor. Etc...

Världen blev nu bra mycket mer komplex att hantera på egen hand. Någonstans här börjar tankarna dra sig mot tidsmaskiner, 10 år tillbaka, enklare förr eller till och med bättre förr... Där bryts tankekedjan. En annons sticker ut från en branschtidning. Säger något om 'hjälpbibliotek', 'ramverk', 'IoT'.

Här kommer först nyfikenheten. Verkar bra med färdiga lösningar. Bara att köpa och plugga i, eller? Nu invändningarna, men vår egen funktionalitet? Hur får den plats? Hur vet vi att vi inte blir bakbundna av stela yttre bibliotek eller underleverantörer som inte levererar? Sedan förnekelsen. Kan aldrig fungera att ta in dom bitarna i en mikrokontroller. Vi skriver koden själva. Behöver spara flash, behöver allt RAM. Speciellt på vår lilla kontroller. Den är riktigt bra med 10 år på nacken. Alla kan den, inte avancerad som de nya där ute. Lite trång kanske men det fungerar... Sedan illusionen. Vi lägger dit det där nya själva. Hur svårt kan det vara...

Detta slutar sällan bra. Var gick det fel? Vilket steg? Jag skulle säga vid rädslan för det nya. Vi vet vad som finns, vi vet inte vad som finns där ute. Moderna mikrokontrollers har vuxit och har blivit mer komplexa. De är inte en gammal 8051 längre. De har också mer minne/funktioner/prestanda för väldigt små pengar. Däremot fungerar det inte längre att utveckla allt från början längre. Övergången är gradvis.

Tidigare gjorde alla det, nu mer klarar specialister av det. Och de blir färre över tiden. Sa jag att de har mer minne/mer prestanda. Faktiskt mer än vi behöver? Ah, köp en billigare då är väl självklart. Nej, nu börjar avvägningen komponentpris/utvecklingstid svänga över till att den lilla vinst på komponentpris inte rättfärdigar längre utvecklingstid. Det blir färre och färre nischer där det är giltigt. Just det, stod det inte något i utredningen från VD om marknadsfönster... Kan kort utvecklingstid ha vuxit i betydelse från förr? Ok. kan offra lite minne och flash på att få hjälp.

Tagit oss över det hindret. Frågan är hur gör vi? Nu börjar det bli intressant. Vi har rörelsefrihet. Vi kan använda en del av processorns resurser för lägga in 3:de parts bibliotek som löser uppgifter åt oss. Vi kan kosta på enklare OS för att partitionera problemen och få oberoende utveckling av delar. T.ex. den där TCP/IP stacken. Fanns en på nätet, open source, som alla verkar använda. Vi kan lägga ett anpassningslager och ta den. Slipper dels skriva koden. Men framför allt, vi behöver inte en TCP/IP expert som kan alla RFC:er, vi slipper testa den, och vi kan fråga andra användare om vanliga problem med den.

Kör igång ett pilotprojekt. Väljer en hyfsat kompetent mikrokontroller. Börjar gräva i dokumentationen. Det var mycket! Users guides, programmers manual, data sheet, reference manual. En del med  över 2000 sidor pdf. En del via referens till något företag kallat 'ARM'. De har gjort delen kallad 'Cortex-M4' i mikrokontrollern. Sedan val av OS, testa FreeRTOS och lwIP som TCP/IP stack.

Sitter lite fast, tills man upptäcker exempelsamlingen och firmwarebiblioteken med exempelkoden. Med denna kan det gamla arbetssättet sträckas vidare och något fungerade kommer fram. Var rätt mycket svett och tårar på vägen att klippa och klistra ihop olika exempel men det gick. Trist bara att vi behöver göra om det för nästa produkt och nästa byte av hårdvara.

Frågan är, är världen bättre mot 10 år sedan? Dags för fokusskifte. Hur såg utvecklingen ut för ca 15-20 år sedan inom PC/Linux världen? Då Windows 95 vad det nya heta. PC:n hade 64MB ram och 90% av applikationerna fortfarande startades via Dos. Det var då ramverk som 'COM' togs fram. Hemdatorerna hade dött av 5 år tidigare. Starka leverantörer som Microsoft, Borland och Lotus Notes växte fram (och en del senare dog).

Hur såg utvecklarens vardag ut? Det var: Bråka med OS och det API det erbjöd, välja hjälpbibliotek och knyta samman dessa. Redan 10 år tidigare hade man släppt att koda mot specifik hårdvara och trimmande av busy wait loopar mot specifik hårdvara. Man bytte PC var 3:de år som användare, var 18:de månad som utvecklare. Kort och gott, i stort sett all utveckling skedde mot API:er. Arbetet bestod i att skapa nya API:er och nyttja gamla från delar och sy ihop sin lösning. Yttre gränssnitt var filformat, GUI:s och sakta hade nätverk börjat dyka upp med protokoll. Också en karaktäristisk jakt på att identifiera det som ändras (teknik, hårdvara, användarkrav) från det som fast (programmets syfte, programmeringspråk med dess begränsningar). Allt för att kunna utnyttja det fasta att stå på då omvärlden förändras.

Så tillbaka till vår situation. Framtiden kommer rullande sakta men säkert. Och här vill jag påstå att den upprepar sig. Hårdvara sjunker tillbaka. Det långlivade är mjukvaran. Jakten på fast mark att ha som bas för mjukvarudesign ökar och de rörliga delarna trycks ut mot periferin. Stark är trenden av att dela upp världen i gränsnitt där man kommunicerar, mot implementation där man utför. Tidigare var delen med utförande stark. Nu är denna del ofta den som förändras medan gränssnitten är det fasta.

Här kommer det nya. Uppstart av projekt och tidig utveckling, där är gränssnitten (protokoll, filformat, interna API) är centrala. Med dom satta följer implementationen nästan automatiskt. (Kan behövas några varv då 'nästan' är relativt i sammanhanget). Även gränssnitt ändras och dessa versionshanteras för att utöka livslängden.

Ett sätt att anamma denna nya värld är att fokusera på vad som är föränderligt mot vad som ligger fast. Har man gett sig in i mikrokontrollerutveckling, så är det troligtvis någon idé som är lite mer långlivad. Hitta denna. Låt sedan krav och idéer flöda ner från denna mot hårdvara/mjukvara/hjälpsystem.Varje gång man byter kontext, t.ex från applikationslogik till protokollhantering, från OS till hårdvara, från molnet till periferidelar, fråga sig om det inte vore bra med ett gränssnitt. Med dessa kan sedan delar bytas ut, anpassningar skapas och produkten leva vidare i en föränderlig värld. 3:de partleverantörer kan lyftas in och delar kan apassas till varandra.

Det är inte ok längre att skriva om mjukvaran då hårdvara behöver bytas ut. Mjukvaran lever längre och hårdvara är en föränderlig del som mjukvaran ska skyddas ifrån genom någon form av gränssnitt. Här finns svaret till varför man måste våga byta fokus. Krav på utvecklingen som tvingar en till att skriva nytt från hårdvara och uppåt, klarar inte att växa och förändras in i framtiden.

Livslängden på mjukvara bara ökar då den växer, då investeringen i utveckling på den är större och behöver betala sig. Livslängden på hårdvara minskar med den höga utvecklingstakten idag. Så hur stannar vi i förarsätet och inte blir förpassade till bagageutrymmet?

  • Ta kontroll över gränssnitten. Se till att de är antingen standardiserade (billigast, bäst), eller att du  själv kontrollerar bägge sidor (dyrare, bra för rörelsefrihet och kontroll, men det kostar).
  • Var noggrann med dina egna gränssnitt. Inse att de är dyra att förändra. Fortfarande är det dyrare att inte  ha dom. Ta ett varv extra över dessa under design.
  • Vid 3:de partdelar. Du köper implementation. Men än viktigare, de vet förhoppningsvis vad de sysslar med. Så det API som erbjuds har troligtvis designidéer som skulle ta lång tid att upptäcka själv. Väldesignade gränsnitt är viktigt. Sedan bonus är att ofta är det vältestad kod och delas med andra användare.
  • Implementation kan vara extremt billigt, och extremt dyrt. Från gratis (open source) till helt   egenutvecklat. Se till att betala för de delar där det ger mervärde.
  • Avvägning av standard/egenskrivet. Standard innebär att det är mogen teknik. Vill man vara i framkant  är ofta standard svårt. Välj noggrant vilken teknik som behöver vara i framkant.
  • I jakten på standard riskerar man att hamna i bakkant. Ge det några år och det är föråldrat. Balansen framkant/bakkant/livslängd/förändring för olika delar är några av de mest centrala frågorna vid val av teknik. Och vet man inte, skapa ett API med en anpassning för säkerhets skull. Sannolikhet att gissa rätt första gången då man inte vet, är extremt låg.

Av att döma av PC/Server världen så blev framtiden bättre. Tror även att det gäller för mikrokontrollers. Måste bara våga omfamna det nya, hålla koll på det gamla, vara noggrann med sina gränssnitt och välja de delar man själv vill ha kontroll över.