ADC AD7606-4 sampling rate hardware SPI ESP32

[JohannesMaierhofer]

Hello, I drafted a micropyton firmware to read out an ADC (AD7606-4). Using a PWM-Pin (duty cycle 50%), the ADC conversion is initiated with a fixed rate. The falling-edge of the BUSY Pin of the ADC, the SPI read is started.

The performance of my code is really bad. It seems that the spi reading is slower than expected. The measured times are around 250-250us per cycle. I want to achieve a sampling rate of around 50kHz.

hspi = SPI(1, 80000000, sck=Pin_ADC_SCK, mosi=Pin_ADC_MOSI, miso=Pin_ADC_MISO)
rxdata = bytearray(8)

def irq_readadc(p=None):
    start = time.ticks_us()
    
    try:
        Pin_LED(1)
        Pin_ADC_CS(0)                           # Select peripheral.
        hspi.readinto(rxdata)          			# Read 8 bytes inplace
    finally:
        Pin_ADC_CS(1)                            # Deselect peripheral.
        Pin_LED(0)
        
    adcrawdata.append(rxdata)
    delta = time.ticks_diff(time.ticks_us(), start) # compute time difference in us
    adctiming_us.append(delta)

def end_sampling(t=None):
    pwm0.deinit()

def start_sampling():
    global pwm0
    pwm0 = PWM(Pin_ADC_Convst, freq=10, duty=512)
    
    tim0=Timer(0,period=1000, mode=Timer.ONE_SHOT, callback=end_sampling)

Pin_ADC_Busy.irq(trigger=Pin.IRQ_FALLING,handler=irq_readadc)

adcrawdata = list()
adctiming_us = list()```

Any comment recommended that could point me to the bottleneck or how to improve the code. Thanks!

[JohannesMaierhofer]

Chip: ESP32-WROVER-E
Firmware: ESP32-Generic-SPIRAM v1.22.0 preview

[robert-hh]

Hard to say. You will need a logic analyzer to tell, where the lag happens. But you will never get to 50kHz or 20µs. The average latency of the ESP32 between a trigger and something happening I have taken recently was ~45µs. And the response to the IRQ was just switch a pin on/off. The worst latency that I had seen in measurements was ~400µs.
Few of the Microcontrollers with Micropython have a low IRQ latency. The MIMXRT boards like Teensy 4.x have latencies down to <2µs with hard interrupts, STM32 like Pyboard are in the range of 5 µs. The RP2 has a IRQ latency of about 15µs.

[JohannesMaierhofer]

Thanks for the input. Is this long latency for the ESP32 software related or a principal issue of the chip's architecture?
Is there a chance to implement the irq-function in C or even Assembler to speed up to <20us?

I found this, where a pin switch is realized in <1us.
https://haydendekker.medium.com/esp32-interrupts-can-only-do-200khz-56f8dbb6a61c

[robert-hh]

Not sure what is the slow part, MicroPython or the esp-idf. Maybe both. Did you probe, how long your MicroPython IRQ handler alone takes. That could be a quite few µs as well. At least ~10µs for the SPI transfer + data handling.

[JohannesMaierhofer]

I will setup a probe in two days and report.

[JohannesMaierhofer]

Probing the vanilla Micropython irq response time is about 50us and sometimes a huge delay is observed, so very same behavior as @robert-hh. I will consider writing my own interrupt function and compile it into the firmware. If anyone has info material to assist, please share!

[glenn20]

This is an application where busy polling the adc busy pin is likely to be substantially more performant than the interrupt mechanism (especially the soft interrupts on the esp32) and easier to implement.

[JohannesMaierhofer]

This does not really fit my idealistic way of programming 🤷‍♂️

[GitHubsSilverBullet]

hspi = SPI(1, 80000000, sck=Pin_ADC_SCK, mosi=Pin_ADC_MOSI, miso=Pin_ADC_MISO)

That's a whopping 80MHz clock rate. Is that what you want?
Can your hardware support that speed?
In case it's a typo, Python supports underscores for readability (ie. 8_000_000 for 8MHz).

[JohannesMaierhofer]

It is what I want to achieve. ESP32 hw-spi is capable of 80MHz according to its specs. Thanks for the underscore tip, didn't know that!

[GitHubsSilverBullet]

Hmmm, it looks like the datasheet from AD suggests a max. f_SCLK of 20MHz @5v and 15MHz @3.3V on page eight.

[JohannesMaierhofer]

true, but that's not the point here anyway. But thanks! -> even with 20MHz the pure reading time is around 5us. Adding around 2us for the IRQ gives <10us.

[GitHubsSilverBullet]

Within the ISR you're dynamically extending a list. That takes quite a while.
Then you're done with the ADC work and extend a second list with the timing.
That's got to be slow. (And according to the docs shouldn't be done in an ISR anyways)

[JohannesMaierhofer]

Here is my newest attempt to tackle the task. @glenn20, indeed I switched to polling the busy pin as the interrupt story is not solvable without going very deep.
Even at 10kHz, I'm randomly loosing samples. So I think I have to step up to viper (which currently throughs errors at runtime) or even to assembler.

Question: Can I poll the pwm output pin register? The busy spikes are quite small. I could then just test if the ADC is busy or not, but get the 'clock' from the pwm output.

Any comments and tips welcome.

@micropython.native
def start_sampling(buf, fs, n:int):
    mv = memoryview(buf)

    bsy = Pin_ADC_Busy.value
    LEDon = Pin_LED.on
    LEDoff = Pin_LED.off
    CSon = Pin_ADC_CS.off
    CSoff = Pin_ADC_CS.on
    
    i: int=0
    done=False
    
    pwm0 = PWM(Pin_ADC_Convst, freq=fs, duty=512) #frequency must be read out later exactly because of divider round off
    
    while(i<n):
        if not bsy() and not done:
            try:
                LEDon()
                CSon()           					# Select peripheral.
                hspi.readinto(mv[i:i + 8])          # Read 8 bytes inplace
                i+=1
                done = True
            finally:
                CSoff()            # Deselect peripheral.
                LEDoff()
        elif bsy() and done:
            done = False
            
    pwm0.deinit()