Performance of ADC with micropython and pico

[clmoi90]

Hello all,

I have just started to dig in micropython with a raspberry pico w.
I wanted to see the performance of the ADC module, to see the maximum sampling rate at which it could acquire a signal.

I have made a simple test with this function:

ARRAY_SIZE = const(100)
sensor_temp = ADC(4)  # create ADC object on ADC pin
temp_raw_array = bytearray(ARRAY_SIZE)
write_index = 0


@timed_function
def write_temperature_array(timer):
    global temp_raw_array
    global write_index
    raw_value = sensor_temp.read_u16()
    temp_raw_array[read_index] = raw_value
    write_index = (write_index + 1) % ARRAY_SIZE

(EDIT: I have also tested with array.array and deque but I got similar results)
I am using the timed_function decorator from the micropython documentation.

I am quite disappointed with the result, around 110us with the frequency at 125 Mhz. I guess with this result, the maximum sampling rate would be around 5kHz and considering only one channel...
I am not so familiar with microcontroller. Is this limit due to 125 Mhz frequency? Or because of micropython itself? Or is something sub-optimal in my simple function?
I (maybe naively) thought I would easily be able to have a sample rate of 100kHz or even 1 Mhz if using only one channel. Do you think it would be possible to reach such sampling rate using another board? I would not have to post-process the data within the microcontroller (even if it would be better), I could forward the data to the PC via ethernet and then post-process there (but not sure if Python on PC runs faster to post-process all the data).

[GitHubsSilverBullet]

I can assure you that the full 500 ksps are not a problem at all.
You have to dig quite a bit deeper though.

Either using DMA into a buffer of a given size - singleshot.
Or using DMA into two alternating buffers of a given size - continuous.
Or using a ISR written in thumb assembler. Even a filter isn't a problem at that speed. After all, one has two microseconds per ADC value.

But by simply using the tools Micropython gives you, quite a good speed can be achieved.

#!/usr/bin/python3
# -*- coding: UTF-8 -*-
# vim:fileencoding=UTF-8:ts=4

from array import array
from machine import ADC
from time import ticks_ms, ticks_diff, sleep_ms

def measure(data):
    index = 0
    adc = ADC(ADC.CORE_TEMP)
    f = adc.read_u16
    t0 = ticks_ms()
    while index < NUM:
        data[index] = f()
        index += 1
    t1 = ticks_ms()
    td_µs = ticks_diff(t1, t0) * 1e3
    print(f'{td_µs/NUM:6.2f} µs/conversion   {1e6/td_µs*NUM:6.0f} sps')
    sleep_ms(20)

@micropython.native
def measure_native(data):
    index = 0
    adc = ADC(ADC.CORE_TEMP)
    f = adc.read_u16
    t0 = ticks_ms()
    while index < NUM:
        data[index] = f()
        index += 1
    t1 = ticks_ms()
    td_µs = ticks_diff(t1, t0) * 1e3
    print(f'{td_µs/NUM:6.2f} µs/conversion   {1e6/td_µs*NUM:6.0f} sps')
    sleep_ms(20)

@micropython.viper
def measure_viper(data):
    d: ptr16 = ptr16(data)
    _num: int = int(NUM)
    index: int = 0
    adc = ADC(ADC.CORE_TEMP)
    f = adc.read_u16
    t0: int = ticks_ms()
    while index < _num:
        d[index] = int(f())
        index += 1
    t1: int = ticks_ms()
    td_µs = ticks_diff(t1, t0) * 1e3
    print(f'{td_µs/NUM:6.2f} µs/conversion   {1e6/td_µs*NUM:6.0f} sps')
    sleep_ms(20)


NUM = const(10_000)
data = array('H', (0 for _ in range(NUM)))
print('start')
measure(data)
measure_native(data)
measure_viper(data)

Edit: Forgot the results…
13.80 µs/conversion 72464 sps
10.00 µs/conversion 100000 sps
6.10 µs/conversion 163934 sps

[mendenm]

I have successfully digitized 250 ksps using micropython.viper mode code. This is running the ADC in its continuous mode, but to get this speed, I run it in a thread on the second core, and monitor the FIFO overrun bits to make sure it is keeping up. If I try to run any faster, I get overruns This gives a complete, python-only and no DMA solution. You can use DMA to run at the full speed.

Note that the 250 ksps speed I can get includes real-time IQ demodulating the signal (using a sine lookup table), so I am doing a fair amount of math on the fly.

[GitHubsSilverBullet]

Yes, I tried that as well. Depending on an unknown amount of internal Micropython ›gimmicks‹ (gc, clocks sleep, …) , it is OK if you don't need a reliable stream of consecutive measurements.
If you do need reliability, DMA or ISR (or a combination of both) is the only way to go.

[rkompass]

In my Pico DMA class I actually included ADC as a possible data source.
This is untested, however, as I was distracted by the need to write a better ADC class first to have the ability to record from 2 or 3 sources in parallel (e.g. for stereo recording). This then was left unfinished.
An advantage of the present class is that it has a self-configuring built-in bootstrap (using a master DMA channel) for being able to record to cyclically repeating or interleaving buffers. This was tested for PWM playback but should also work for recording i.e. as DMA destination. You are welcome to try and perhaps improve.
Note that on the Pico W the first DMA channel is in use for transferring WIFI data iirc.

[mendenm]

@GitHubsSilverBullet I completely agree that DMA has as distinct advantage at high, deterministic rates.

The points of the case I was making were that 1) on processor 2 under micropython, you get left alone, and don't seem to have any interruptions, and 2) for this case, where I was processing the data as it arrived, DMA would actually be messier, since I would need double/ping-pong buffering and quite a bit of logic. It is worth knowing that you can busy-loop the ADC at 250 ksps if do do it in a thread with viper mode. I was checking the overrun bit at the end of over block of data (250000 samples for one IQ computation), and it was always clear, so you really can do some nice, streaming stuff without DMA.

[GitHubsSilverBullet]

Understood. That's all fine if one uses only a moderate few hundred kIRQs per second. The problem arises once you reach the (roughly/around) 1.5 Million IRQs per second realm. Then even a short sleep_ms() on the other core does something which I believe modifies the clocks. And waking up takes (again roughly) 3µs. BTDT.
Which is - for the average user - pretty hypothetical. ;-)