I am converting a medical research instrument from Photon to Gen3 processors. The sampling rate for the original version was based on a software time and struggled to be able to record above 100 Hz without timing jitter.
A revised version using the double buffered DMA technique resolved those issues and was a treat to use at sampling rates up to 500 Hz (and way beyond but 500 Hz was my limit of interest.
I have commenced testing the original software timing variant on Gen3 processors but initial indications are that this is going to suffer worse jitter than the Photon, presumably because of the slower clock speed.
I am in need of the DMA capability on the Gen3 processors but this requires access to a different HAL. Is this likely to happen in the near future?
On the STM32 devices the STM standard peripheral library was available to user firmware, which made it possible to directly access many hardware features. In particular, it made the ADCs easy to access at the hardware level.
On nRF52 devices, the build process is different. The SoftDevices aren’t available to user firmware, which makes it difficult to access the hardware devices directly. The nRF52 has nice ADC DMA support using EasyDMA, but you can’t get to it.
You can access it directly using monolithic firmware. Since both the system part and user part are linked into a single binary, you can access the SoftDevice and hardware from user firmware.
As time goes on, more SoftDevice APIs will be exposed through the HAL (hardware abstraction layer). BLE will be the first, followed by NFC. It’s possible that ADC DMA could be added in the future, but it’s not on the immediate roadmap.
That is a serious blow. I will continue evaluating the software timing variant but may need to explore more exotic solutions.
One would be to use a Photon as a data acquisition processor handing off the data to a Boron for housekeeping (controlling a 4DSystems display, writing to SD card and talking to the external world via 3G/LTE. That has the advantage of providing isolation between time critical collection and interruptions from eternal events. However it introduces the question of the most effective way to get the data from the Photon to Boron. Any pointers you can give would be appreciated.
Second would be to abandon the Particle environment entirely and move to other development environments for nRF52 or ESP32. Not my first choice but I will keep my options open.`
I’m looking for this as well. I’m attracted to the Argon due to the floating point hardware as well as it’s Ethernet capabilities. Staying on the Photon would mean being at the whim of potentially unreliable wifi for a performance-critical application.