Timer with sub-microsecond accuracy

[tomcombriat]

Hi!

If I am correct, the timers on the RP2040 have a maximum resolution of 1microsecond (https://www.raspberrypi.com/documentation/pico-sdk/hardware.html#hardware_timer), but for applications (like Mozzi) it could be useful to have Timer with higher resolution.

I know that it is possible to have the CPU count but manually checking if a number of cycles have been elapsed will probably incur a big overhead. Has anyone managed to do such thing? Maybe with a PIO?

Thanks!
Tom

[earlephilhower]

It's be relatively simple to do a timer with a PIO. They can count and send an IRQ in a couple instructions, and they can run at SYSCLK(133MHz). However, the interrupt controller and XIP flash means that you most likely can have jitter on the order of 1us++. So the very precise IRQ signal turns into a random variable WRT code timing.

Maybe a better idea would be to understand why you want <1us accuracy and see if there's some other way to get it done?

[tomcombriat]

Thanks for your answer!

So the very precise IRQ signal turns into a random variable WRT code timing.

Yes I remember reading that somewhere…

Maybe a better idea would be to understand why you want <1us accuracy and see if there's some other way to get it done?

For the Mozzi library, we are outputting the audio samples at a given frequency (32768Hz for the RP2040). The alarms, being resolved at 1us, leads to a significant error in the output frequency (see for instance this issue).

I tried to play a bit with the sys_tick timer, specifically:

    systick_hw->rvr = 99999;
    systick_hw->cvr = 0;
    systick_hw->csr = M0PLUS_SYST_CSR_TICKINT_BITS|M0PLUS_SYST_CSR_ENABLE_BITS;
   exception_set_exclusive_handler(SYSTICK_EXCEPTION, test);

but the last line seems to hang the processor (test is an empty void function)

[earlephilhower]

SYSTICK is already hooked for the cycle counter (there's only a 24-bit count OTW, the systick lets us keep an epoch and know the true cycles).

32K IRQs/second seems like a bad idea just in general. AIUI IRQ handling here is not very lightweight so you've got a lot of overhead on each one of those calls just to send 1 sample.

We use the DMA engine with timed transfers to send PWM audio output already, why not use that instead of rolling your own? Send in ping and pong buffers and the HW does all the work, only giving an IRQ when one buffer is free for the next one (which is also taken care of by the PWMAudio class).

And, obviously, having SYSCLK be an exact multiple of your desired output frequency would be best here. This is a synchronous device, so if it's not then there will be some jitter from the fractional clock division.

[tomcombriat]

We use the DMA engine with timed transfers to send PWM audio output already, why not use that instead of rolling your own?

Ah, indeed, it apparently went under the radar, thanks! I'll try to work with that or to build on it for adapting to Mozzi's architecture.

And, obviously, having SYSCLK be an exact multiple of your desired output frequency would be best here.

Indeed, but the choice of the output frequency is somewhat limited by other optimisations, this also has to run on AVR, which really benefits it.

Thanks for your help and very fast answer!

[theHDM]

SYSTICK is already hooked for the cycle counter (there's only a 24-bit count OTW, the systick lets us keep an epoch and know the true cycles).

32K IRQs/second seems like a bad idea just in general. AIUI IRQ handling here is not very lightweight so you've got a lot of overhead on each one of those calls just to send 1 sample.

We use the DMA engine with timed transfers to send PWM audio output already, why not use that instead of rolling your own? Send in ping and pong buffers and the HW does all the work, only giving an IRQ when one buffer is free for the next one (which is also taken care of by the PWMAudio class).

And, obviously, having SYSCLK be an exact multiple of your desired output frequency would be best here. This is a synchronous device, so if it's not then there will be some jitter from the fractional clock division.

Earle, I am coding a project on an RP2040 where I want to devote the 2nd core to managing IRQ callbacks. Currently I have a home-rolled PWM driver that polls every X microseconds using hardware timers. I want to migrate to the PWMAudio library. What should I do to ensure that the interrupts occur only on the 2nd core? Any other considerations w.r.t. multicore usage I would need to think of?

[earlephilhower]

Call PWMAudio::begin from the 2nd core and everything will be managed there. The usual library restrictions are there, namely only write data to the object from the same core you started it on. The AudioBufferManager is 1-core IRQ protected, but it doesn't implement a multicore lock so working on the linked buffer lists isn't multicore safe.