Fast system interrupt for Argon

Firmware
1

I am new to the particle platform and I am attempting to implement an FFT on the Argon to process some sensor data. To do this I need to have uniformly and accurately spaced samples from the ADC (preferably up towards 20 kS/s).

I know that I can use software timers and interrupts to get samples spaced at 1 ms, unfortunately this is clearly not fast enough for my purposes. A while back a library was developed for the particle photon/core called SparkIntervalTimer. It took advantage of the hardware timers (the ones responsible for managing PWM output) to get higher precision interrupts.

I was wondering if there was any way to implement something like this on the Argon, or if I could somehow port this library.

Thanks!

1 Like
2

I believe @peekay123 maintains the spark interval timer library. Last I heard, he was waiting for the particle engineers to finalize the exact number of hardware timers available to user code on mesh devices before updating the library.

2 Likes
3

For 20,000 samples per second, if you must use the Argon now, I’d use monolithic firmware (system part and user part combined with no barrier) and use the nRF52 hardware ADC DMA (EasyDMA). There’s currently no way to use it from regular modular user firmware, but that will get you the precise samples without the overhead of an interrupt on every sample.

On the Photon, ADC DMA can be used from user firmware without any system changes, and that’s what I’d recommend. This sample code shows how to do ADC DMA on the Photon.

You have to do some experimentation to determine what’s better for the FFT. The Argon has half the CPU clock speed, but it has hardware floating point, so it’s hard to say what would be better.

3 Likes
4

It may only be my personal impression, but got the feeling that the ADCs on the nRFs are performing somewhat worse than the STM32 ones (and they are not the greates either).

5

Is it your suggestion to use an external ADC? Designing the circuit around an ADC is not without its challenges and neither is the communications when reading at 20,000 samples per second especially if over any duration due to the other things that will be going on (cloud comms etc.) with either the Photon or Argon. Thus, you may need to have a co-processor that is dedicated to collecting the data samples into memory.

6

Awesome, thanks for all the replies guys. I ended up just going with the photon so that I could adapt @rickkas7 photonAudio code which also has the potential advantage of being able to offload some of the DSP computation to a server. I started with the Argon since I’m more comfortable with Nordic SOCs. But I think the photon will do the job just fine.

I decided against an external ADC since the design overhead is usually quite large, but in a later iteration of this device I think I might just bite the bullet.

Anyway,
Cheers!

1 Like
7

Any updates on the spark interval timer library being adapted to the Argon for faster operations?

8

New library to do ADC DMA on Gen 3 devices! Works on Device OS 1.3.1 and later on all Gen 3 devices (Argon, Boron, Xenon, B Series SoM). Sampling rates up to 200 kHz. Can sample a single pin or sequentially across multiple pins. Supports double buffers for continuous captures.

4 Likes
9

This is fantastic! Thank you rickkas7

10

It seems attempting to sample from 5 or more pins at a time put’s the device into SOS mode. Has someone ran across this?

	ret_code_t err = adc
		.withSampleFreqHz(22050)
		.withDoubleBuffer(SAMPLES_IN_BUFFER, buffer0, buffer1)
		.withResolution(NRF_SAADC_RESOLUTION_8BIT) 	
		.withSampleMultiplePins({A0, A1, A2, A3, A4, A5})
		.init();
11

Will this work to replace timing issues with wiegand?

1 Like