ADC-drivers ontwerpen: Blockerende vs. non-blockerende polling-technieken

In ons vorige artikel hebben we verkend hoe een goed-gestructureerde interface low-level driver-details van applicatielogica kan scheiden, wat schaalbaarheid en portabiliteit over hardware-platformen boost.

In deze entry duiken we in praktische ADC-driver-implementaties, met focus op de polling-benadering. We zullen blockerende en non-blockerende ontwerpen contrasteren en laten zien hoe elk de systeemprestaties beïnvloedt.

Blokkerende vs. Non-blokkerende Drivers

Bij het creëren van een microcontroller-driver moet een ontwikkelaar beslissen of de API uitvoering zal blokkeren tot de operatie compleet is. Een blockerende driver stopt de programmaflow, wat zorgt dat opeenvolgende code alleen draait na afloop van de taak. Een klassiek voorbeeld is een UART-gebacked printf:

printf("Hello World!"); 

Met een blockerende UART-driver zal de regel die op deze call volgt niet draaien tot de 12-byte string (96 bits) volledig getransmitteerd is. De actuele vertraging hangt af van de baudrate: bij 1 Mbps duurt de blok ongeveer 96 µs; bij 9,6 kbps strekt het uit tot ongeveer 10 ms.

In tegenstelling, initieert een non-blockerende driver de overdracht en keert direct controle terug naar de applicatie. De UART kan dan doorgaan met verwerken terwijl de data uitstroomt, typisch via interrupts, DMA of een transmit-buffer. Deze benadering verbetert efficiëntie in latentie-gevoelige contexten maar voegt complexiteit toe aan de driver en applicatie.

Het kiezen van het juiste model hangt af van de applicatie's timing-eisen en hardwareconfiguratie. Voor high-speed UARTs (bijv. 1 Mbps) kan de overhead van een non-blockerend ontwerp de voordelen wegen. Voor langzamere links (bijv. 9,6 kbps) kan een non-blockerende driver significante prestatiewinst ontgrendelen met beheersbare toegevoegde complexiteit.

Een ADC-driver architecten

Een robuuste ADC-driver omvat typisch drie lagen:

• De low-level driver, die een configuratiestructuur tijdens initialisatie accepteert en de hardware-registers instelt.
• De applicatiecode, die generieke HAL-functies aanroept om conversies te starten en resultaten op te halen.
• Een configuratiemodule die apparaatspecifieke parameters abstraheert.

De low-level driver biedt een Hardware Abstraction Layer (HAL) met een beknopte, herbruikbare API. Voorbeelden uit real-world-projecten omvatten:

• 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 Function, TYPE (*CallbackFunction)(type));

Deze API's stellen eenvoudige initialisatie, conversiecontrole en status-polling in staat. De register-toegang-helpers laten ontwikkelaars de HAL uitbreiden voor custom-functies, zoals single-channel conversies, zonder de publieke API op te blazen.

Een eenvoudige blockerende ADC-driver implementeren

Een minimale blockerende driver kan een enkele Adc_Sample-routine blootleggen die de hardware start, wacht op voltooiing, en het resultaat kopieert naar een door de aanroeper geleverde buffer. De onderstaande code demonstreert de kernidee:

Code-voorbeeld: Blokkerende ADC-sample routine

De while-lus blokkeert tot Adc_ConversionComplete true retourneert, waarna de driver de conversie-registers uitleest en de samples opslaat.

Omzetten naar een non-blockerende ADC-driver

Overschakelen naar een non-blockerend model vereist een kleine verandering in de API: de aanroeper ontvangt nu een status-vlag en moet polen op voltooiing. De bijgewerkte functie zou er zo uit kunnen zien:

Code-voorbeeld: Non-blokkerende ADC-sample routine

In de applicatie wordt een typische sequentie:

Adc_Sample(); while (!Adc_ConversionComplete()) { // Andere taken uitvoeren } // Resultaten uitlezen 

Deze benadering vrijmaakt de CPU om ongerelateerde code uit te voeren terwijl de ADC-hardware de conversie voltooit.

Conclusies

Zowel blockerende als non-blockerende ADC-drivers hebben distincte voordelen:

• Blokkerende drivers zijn simpel en vereisen geen additionele state-management, maar kunnen kritieke paden stallen.
• Non-blockerende drivers stellen gelijktijdige uitvoering in staat, wat algehele doorvoer verbetert, maar vereisen zorgvuldige status-checking en potentieel complexere driver-logica.

In de volgende post zullen we deze discussie uitbreiden door een interrupt-gebaseerde ADC-driver te demonstreren die sensor-acquisitie nog verder ontkoppelt van applicatielogica.