Waarom een ​​bare-metal ontwikkelaar overstapte naar besturingssystemen

Terugkijkend op de 'Bare-Metal Age'

De eerste keer dat ik van de embedded software hoorde, was rond 2008. Ik was een tweedejaarsstudent en begon te leren over programmeren op een 51-chip. Sinds ik informatica studeerde, werden de meeste van mijn programma's uitgevoerd op de pc. Dat was een heel andere ervaring om programma's te zien draaien op een bare-metal board, en ik kan me nog de opwinding herinneren toen mijn eerste fietslampprogramma succesvol liep. Echter, hoe meer bare-metal programma's ik schreef, hoe meer problemen ik tegenkwam. Ik vat ze als volgt samen: 

Gelijktijdigheid

Voor bare-metal-programma's is er onvermijdelijk een enorme 'terwijl (1)'-lus, die bijna alle transactielogica van het hele project bevat. Elke transactie roept een of meer vertragingsfuncties op en ze worden serieel uitgevoerd wanneer de CPU een vertragingsfunctie uitvoert, de rest van de transacties moet wachten. Op deze manier wordt veel van de CPU-tijd verspild aan lege lussen, wat een vrij lage gelijktijdigheid veroorzaakt.

Modulariteit

Vanuit het perspectief van het softwareproject wordt tijdens het ontwikkelingsproces altijd de nadruk gelegd op het principe van hoge cohesie en lage koppeling. Modules in een bare-metal software zijn echter meestal sterk van elkaar afhankelijk, het is niet handig om software met een lage koppeling te ontwerpen, waardoor het moeilijk is om grote projecten op bare-metal boards te ontwikkelen. Bijvoorbeeld:

• Zoals hierboven vermeld, zijn de meeste functies verzameld in een enorme 'while (1)'-lus en moeilijk te verdelen in modules.
• Een ander voorbeeld is dat ontwikkelaars voorzichtig moeten zijn met het gebruik van vertragingsfuncties als de watchdog-timer erbij betrokken is. Als de vertragingstijd te lang is, heeft de hoofdfunctie niet de mogelijkheid om de waakhond te resetten, dan wordt de waakhond geactiveerd tijdens de uitvoering. Dus voor bare-metal ontwikkeling zijn er te veel dingen om rekening mee te houden, zelfs bij het aanroepen van een vertragingsfunctie. Hoe complexer het project, hoe meer zorg er moet worden besteed.

Ecosysteem

Veel geavanceerde softwarecomponenten moeten afhankelijk zijn van de implementatie van het lagere besturingssysteem. Bijvoorbeeld:

• Ik heb een open-sourceproject ontwikkeld op basis van 'FreeModbus' dat ik van plan was te transplanteren naar verschillende platforms, zelfs de bare-metal boards werden overwogen. Maar vergeleken met het gemak van het aanpassen aan verschillende besturingssystemen, zijn sommige functies te complex om op alle bare-metal boards te implementeren. Aan de andere kant moeten veel implementaties helemaal opnieuw worden ontworpen op verschillende hardwareplatforms vanwege het gebrek aan gemeenschappelijkheid, wat een saaie en tijdrovende taak is. Voorlopig kan mijn implementatie van Modbus-stack nog steeds niet draaien op bare-metal boards.
• Veel WiFi-softwareontwikkelingskits (SDK's) die worden geleverd door grote bedrijven zoals Realteck, TI en MediaTek, kunnen alleen op het besturingssysteem worden uitgevoerd. Ze publiceren de broncode van de firmware niet die de gebruiker kan wijzigen, dus je kunt ze niet gebruiken in de bare-metal-omgeving.

Realtime

Voor sommige toepassingsgebieden is realtime-functionaliteit nodig. In deze situatie moeten enkele kritieke stappen van de software op een bepaald moment worden geactiveerd. Voor industriële controle moeten de mechanische apparaten acties voltooien in een vooraf bepaalde volgorde en timing. Als de realtime-capaciteit niet kan worden gegarandeerd, zal dit storingen veroorzaken, die het leven van werknemers in gevaar kunnen brengen. Op bare-metal platforms, wanneer alle functies zijn vastgelopen in één grote 'terwijl (1)'-lus, is het onmogelijk om de realtime-mogelijkheden te behouden.

Herbruikbaarheid

Herbruikbaarheid is direct afhankelijk van de modulariteit. Ik geloof dat niemand hetzelfde werk keer op keer zou willen doen, vooral niet bij het schrijven van code. Maar op verschillende hardwareplatforms met verschillende chips moet dezelfde functie worden aangepast aan verschillende hardware, waarvan de implementatie sterk afhankelijk is van de low-level hardware. Het is onvermijdelijk om wielen te herbouwen.

Het voordeel van besturingssystemen

Het was ongeveer 2010 toen ik het besturingssysteem voor het eerst gebruikte. De serie STM32 MCU's begon populair te worden. Met krachtige functies draaiden veel mensen er besturingssystemen op. Ik gebruikte toen het RT-Thread-besturingssysteem waarvoor veel kant-en-klare componenten beschikbaar zijn. In vergelijking met andere besturingssystemen voel ik me meer op mijn gemak en ontwikkel ik er al 10 jaar op.

Op basis van mijn begrip wil ik de voordelen van besturingssystemen bespreken:

Modulariteit

Met het besturingssysteem kan de hele software worden opgesplitst in verschillende taken (bekend als threads), elke thread heeft zijn eigen onafhankelijke uitvoeringsruimte. Ze zijn onafhankelijk van elkaar, wat de modulariteit verbetert.

Gelijktijdigheid

Wanneer een thread de vertragingsfunctie aanroept, zal deze automatisch de CPU overdragen aan andere threads in nood, wat het gebruik van de gehele CPU en uiteindelijk de gelijktijdigheid verbetert.

Realtime

Een RTOS is ontworpen met real-time mogelijkheden. Elke thread krijgt een bepaalde prioriteit toegewezen. Belangrijkere threads worden op een hogere prioriteit ingesteld, minder belangrijke threads op lagere. Op deze manier is de realtime prestatie van de gehele software gegarandeerd.

Ontwikkelefficiëntie

Het besturingssysteem biedt een uniforme laag van abstracte interfaces, die de accumulatie van herbruikbare componenten vergemakkelijkt en de ontwikkelingsefficiëntie verbetert.

Het besturingssysteem is een product van de wijsheid van een groep software-nerds. Veel algemene softwarefuncties, zoals semafoor, gebeurtenismelding, mailbox, ringbuffer, eenrichtingsketenlijst / tweerichtingslijst, enzovoort, zijn ingekapseld en geabstraheerd om deze functies gebruiksklaar te maken.

Besturingssystemen zoals Linux en RT-Thread implementeren een standaard set hardware-interfaces voor gefragmenteerde hardware, het zogenaamde device-driver framework. Daarom hoeven software-engineers zich alleen maar te concentreren op ontwikkeling en hoeven ze zich niet langer druk te maken over de onderliggende hardware of om wielen te herbouwen.

Software-ecosysteem

De rijkdom van het ecosysteem brengt het proces van kwantitatieve veranderingen tot kwalitatieve veranderingen.

De verbetering van modulariteit en herbruikbaarheid met besturingssystemen stelt ons in staat om op besturingssystemen gebaseerde, embedded-vriendelijke herbruikbare componenten in te kapselen, die niet alleen in onze projecten kunnen worden gebruikt, maar ook kunnen worden gedeeld met meer embedded ontwikkelaars in nood, waardoor de waarde van de software.

Ik ben een open-source nerd en ik heb een aantal embedded software open source op GitHub. Voordat ik open-sourcesoftware maakte, sprak ik zelden met anderen over mijn projecten, omdat ik van mening was dat omdat mensen verschillende chips of hardwareplatforms gebruiken, mijn code nauwelijks op hun hardware zou kunnen draaien. Met besturingssystemen wordt de herbruikbaarheid van software sterk verbeterd, veel experts kunnen met elkaar communiceren over hetzelfde project. Ze komen zelfs uit verschillende landen. Dit moedigt steeds meer mensen aan om hun projecten te delen en erover te praten.