Interfacing met moderne sensoren:Polled ADC-stuurprogramma's

In de laatste post hebben we onderzocht hoe een ontwikkelaar in een moderne embedded applicatie een interface moet maken die de details van de implementatie van stuurprogramma's op laag niveau loskoppelt van de applicatiecode. Deze interface biedt een architecturale abstractie die de schaalbaarheid en overdraagbaarheid van de applicatiecode vergroot door deze minder afhankelijk te maken van de hardware.

Nu gaan we kijken naar verschillende manieren waarop een ontwikkelaar een ADC-stuurprogramma kan implementeren op basis van de technieken die we hebben besproken in 3 driverontwerptechnieken voor microcontrollers. In dit artikel gaan we dieper in op hoe we de pollingtechniek kunnen gebruiken en bespreken we het verschil tussen blokkerende en niet-blokkerende stuurprogramma's.

Te blokkeren of niet te blokkeren, dat is de vraag

Bij het ontwikkelen van een stuurprogramma voor een microcontroller moet een ontwikkelaar beslissen of het stuurprogramma blokkeert of niet. Een blokkerende driver blokkeert in wezen de uitvoering van de code totdat de driver zijn taak heeft voltooid. De typische implementatie voor printf die is toegewezen aan een UART blokkeert bijvoorbeeld.

Wanneer u belt zoals:

printf(“Hallo wereld!”);

Een ontwikkelaar weet dat welke coderegel dan ook die instructie volgt, pas wordt uitgevoerd als de hele "Hallo wereld!" verklaring is afgedrukt uit de UART. "Hallo Wereld!" bevat twaalf bytes, 96 bits, maar de hoeveelheid tijd die de instructie blokkeert, hangt af van de UART-baudrate. Voor een UART die is geconfigureerd op 1 Mbps, zou je ongeveer 96 microseconden verwachten. Voor een UART die is geconfigureerd op 9600 bps, zou je ongeveer 10.000 microseconden verwachten! Dat is een groot verschil, afhankelijk van hoe de hardware is geconfigureerd en het kan de uitvoering van het programma dramatisch beïnvloeden, aangezien het UART-stuurprogramma is geconfigureerd als een blokkerend stuurprogramma.

Een niet-blokkerende driver is er een die de uitvoering van het programma niet blokkeert terwijl de driver zijn taak aan het voltooien is. Printf en het UART-stuurprogramma uit het vorige voorbeeld kunnen bijvoorbeeld zo worden geconfigureerd dat het niet blokkeert en in plaats daarvan de toepassing laat doorgaan met uitvoeren terwijl elke byte uit de UART wordt verzonden. Dit kan zorgen voor een efficiëntere toepassing onder de juiste omstandigheden, maar vereist aanvullende instellingen zoals het gebruik van interrupts, DMA of op zijn minst een verzendbuffer.

Welke manier u uw stuurprogramma ontwerpt, hangt af van uw toepassing en hardware. Als de UART bijvoorbeeld is geconfigureerd voor 1 Mbps, zal het schrijven van een niet-blokkerende driver waarschijnlijk niet veel opleveren vanuit het oogpunt van efficiëntie en kan het zelfs meer problemen veroorzaken dan het oplost door extra programmacomplexiteit. Als de applicatie echter 9600 bps nodig heeft, waarbij de applicatiecode 10 milliseconden wordt geblokkeerd, kan het hebben van een niet-blokkerende driver de programma-efficiëntie drastisch verbeteren en is het risico op extra timingcomplexiteit veel minder en beter beheersbaar.

Een geïntegreerd ADC-stuurprogrammaoverzicht

Het is belangrijk op te merken dat ik in een enkele blog niet alle stappen kan doorlopen die nodig zijn om een ​​volledig ADC-stuurprogramma te schrijven. Ik zou er gemakkelijk een paper van twintig pagina's over kunnen schrijven of een heel webinar kunnen geven en het zou waarschijnlijk nog steeds niet alle details behandelen, maar we kunnen in ieder geval naar enkele van de kernstukken kijken.

Er zijn verschillende manieren waarop we een ADC-stuurprogramma kunnen organiseren, maar de manier waarop ik ze graag wil organiseren, vereist drie componenten:

• De low-level driver
• De applicatiecode
• Een configuratiemodule

De low-level driver neemt de configuratiemodule tijdens de initialisatie en stelt de hardware in op basis van de configuratie. Het stuurprogramma op laag niveau biedt een gemeenschappelijke hardware-abstractielaag (HAL) die de toepassingscode vervolgens kan gebruiken. De ADC HAL-aanroepen moeten generiek zijn, zodat de toepassing op hoog niveau de hardware op elke gewenste manier kan configureren en herbruikbaar en schaalbaar kan zijn. Een paar ADC HAL-aanroepen die ik in het verleden heb gebruikt, zijn bijvoorbeeld:

• AdcError_t Adc_Init(const AdcConfig_t * Config);
• AdcError_t Adc_StartConversion(void);
• bool Adc_ConversionComplete(void);
• void Adc_RegisterWrite(uint32_t const Address, uint32_t const Value);
• uint32_t Adc_RegisterRead(uint32_t Address);
• void Adc_CallbackRegister(AdcCallback_t const functie, TYPE (*CallbackFunction)(type));

De eerste drie API's bieden de mogelijkheid om de ADC-hardware te initialiseren, een conversie te starten en vervolgens de conversiestatus te controleren. De laatste drie functies zijn ontworpen om schaalbaarheid naar de low-level hardware mogelijk te maken. Als de HAL bijvoorbeeld geen optie biedt die nodig is voor de toepassing, zoals het converteren van een enkel ADC-kanaal, kan de HAL worden uitgebreid met de functies Adc_RegisterRead en Adc_RegisterWrite. Dit biedt flexibiliteit op basis van de applicatiebehoeften zonder een overweldigende API te creëren.

Een eenvoudig blokkerend ADC-stuurprogramma schrijven

We kunnen een heel eenvoudig ADC-stuurprogramma schrijven dat zich boven de hardwarelaag bevindt. We kunnen bijvoorbeeld een eenvoudige functie maken met de naam Adc_Sample die de ADC-hardware start en vervolgens alle resultaten opslaat in een buffer die vervolgens toegankelijk is voor de toepassing. De buffer die de analoge waarden opslaat, hoeft niet per se één enkele waarde op te slaan, maar kan meerdere waarden opslaan die later kunnen worden gemiddeld of gefilterd op basis van de toepassingsbehoefte. De blokkerende versie voor de bemonsteringsfunctie kan er ongeveer als volgt uitzien:

Zoals je in deze code kunt zien, blokkeert de while-lus de uitvoering totdat de ADC-hardware de conversie heeft voltooid en vervolgens worden de waarden opgeslagen in de applicatiebuffer.

Een eenvoudig niet-blokkerend ADC-stuurprogramma schrijven

Het converteren van het blokkerende stuurprogramma naar niet-blokkerende code is vrij eenvoudig, maar er zijn wijzigingen in de toepassingscode op een hoger niveau nodig. Als de applicatie nu bijvoorbeeld de sensoren wil testen, roept een ontwikkelaar:

Adc_Sample();

In de niet-blokkerende versie moet een ontwikkelaar de retourwaarde van Adc_Sample controleren om te zien of de voorbeelden zijn voltooid en klaar voor gebruik. Hierdoor kunnen de voorbeelden op de achtergrond worden uitgevoerd, terwijl de applicatiecode blijft werken met de volgende updates van onze stuurprogrammacode:

Conclusies

Zoals we in dit bericht hebben gezien, zijn er meerdere manieren om een ​​ADC te schrijven en de implementatie kan blokkerend of niet-blokkerend zijn op basis van onze behoeften. Het blokkeren van stuurprogramma's is meestal eenvoudiger en minder compleet dan niet-blokkerende stuurprogramma's, maar ze kunnen inefficiënt zijn. Niet-blokkerende stuurprogramma's zorgen ervoor dat andere code kan worden uitgevoerd terwijl het stuurprogramma werkt, maar de applicatiecode moet nog steeds de status controleren, wat op zichzelf inefficiënt is in een opgevraagde implementatie.

In het volgende artikel in deze serie zullen we onderzoeken hoe we een applicatie kunnen schrijven die een sensor samplet via een ADC-randapparaat dat gebruikmaakt van interrupts.