Interrupt handling for ADC reading at fixed sample rates

[saraverbeecke]

@peterhinch, thank you for writing these great docs about asyncio and interrupts!

Still I need some expert advice...
I would like to sample the onboard ADC of an ESP32S3 at a fixed sample rate, so after reading the info on interrupt handles in MicroPython and reading your asyncio documentation regarding interrupts, I came up with this piece of code:

from machine import Pin, ADC, Timer
import array
import uasyncio

adc = ADC(Pin(1))
timer = Timer(0)

buffer_size = 100
buffer = array.array('H')

tsf = uasyncio.ThreadSafeFlag()

timer.init(freq=10_000, mode=Timer.PERIODIC, callback= isr)

def isr(_):  # Interrupt handler
    global buffer
    buffer.append(adc.read_u16())  # Append ADC value to the buffer
    if len(buffer) >= 100:
        tsf.set()  # Trigger process task

async def run():
    global buffer
    while True:
        await tsf.wait()
        # Process the buffer data here before waiting for the next interrupt
        print("Processing buffer...")
        buffer = array.array('H') # Clear buffer
        tsf.clear()

loop = asyncio.get_event_loop()
loop.run_until_complete(run())

Is this the right way to do it to avoid race conditions and to have a fixed sample rate?
Thanks!

[2dof]

Your buffer.append() append new value to end of array, i.e a process (dynamic) memory allocation in your ISR is made. it is not a
optimum (fast) .
You should define your buffer first : array.array('H', (0 for i in range(100))) ) ,and then read values into array (better create some ring buffer to automate write/ride samples), no need clear buffer since new samples will overwrite old values.
if code after await tsf.wait() will be executed slower than 0.01 sec ( 10k Hz/ 100 samples = 100 Hz ) then you will get your race condition.

[saraverbeecke]

Thanks for pointing that out @2dof!

[peterhinch]

I would use a ThreadSafeQueue. This simplifies the code and avoids needless RAM allocations. See the doc. Something along these lines:

from machine import Pin, ADC, Timer
import array
import uasyncio as asyncio
from threadsafe import ThreadSafeQueue

adc = ADC(Pin(1))
timer = Timer(0)

buffer_size = 100
buffer = array.array('H')

tsq = ThreadSafeQueue(buffer)

timer.init(freq=10_000, mode=Timer.PERIODIC, callback= isr)

def isr(_):  # Interrupt handler
    tsq.put_sync(adc.read_u16())  # Put ADC value on queue

async def run():
    async for item in tsq:
        # process the data item

asyncio.run(run())

This offers no protection against items arriving faster than you can process them. The docs suggest ways of dealing with this, but inevitably data will be discarded.

A 10KHz rate is very demanding. There are two issues. Firstly ESP32 does not support hard interrupts, so if a garbage collect is in progress IRQ's will be missed. Platforms like RP2 (and STM if you can get it) support hard IRQ's and are better suited to high speed work.

Secondly, it's a high rate for micropython: you need your processing code to run very quickly to match the throughput.

[peterhinch]

STM32 is like rocking-horse poo right now, but RP2 is readily available. However the more I think about this the more I'm doubtful whether a continuous 10KHz throughput is feasible in Python. It depends what processing you intend to do with the data. Processing bursts of data at high speed is easier, where you fill a buffer with samples then stop sampling to process the result. The STM32 read_timed and read_timed_multi methods enable very fast burst measurements. But continuous processing requires careful design and possible use of cunning techniques like Viper, inline assembler, RP2 PIO units or C modules.

[saraverbeecke]

@peterhinch I agree. I receive a STM32H7dev board soon and will try on that one. It is a work horse with amazing clock speed up to 550 Mhz... I like to experiment with the idea to have some C modules doing the fast work (think of ulab doing the FFT) while programming some application stuff in high-level micropython with for example asyncio rather than doing all the work in C or assembler.
You mentioned the GC kicking in sometimes could cause hick-ups for IRQs, is this also the case for STM32 based boards?

[peterhinch]

Some platforms including STM32 and RP2 use hard interrupts which will pre-empt a garbage collection (GC). Others like ESP32 variants only support soft interrupts: if a GC is in progress the service routine (ISR) will be delayed until GC is complete. This latency may be a few ms or, where SPIRAM exists, 100ms or more.

By contrast hard ISR latency is on the order of 15μs. Hard ISR code has restrictions discussed in this doc.

[SeregaZ2004]

@peterhinch ssory, this is wrong thopic... but i have no idea how to write here on github. i have a question about IR reciver module. i have standart 38mhz module and some remote, where says 433mhz. it have IR reciver and transmitter for USB PC. and when this 433 work - i am see how light of 38mhz module have flashing. so 38mhz have reaction for 433mhz remote. but this code dont want to read this. any other home remote for TV or android box work fine. they have NEC16 probably. but this is one 433mhz for PC, plugin to USB and have nice function for PC. i very want to use this remote for both cases at same time - for PC and for Rasbpery Pico. zero experience with this Raspbery. is any way to do this? maybe it need to make some changes in a code to get some raw data from IR 38mhz module?

[peterhinch]

To start a new discussion choose a category, say RP2040/Pico, and press "New discussion". Please do this so that we can stop hijacking this thread.

When you do so, please explain more clearly what you are trying to do. If you want a single micropython program to respond both to IR and 433MHz RF remotes using my libraries, I'm afraid this won't work. The libraries are not designed for concurrent operation.