0
\$\begingroup\$

I'm prototyping a data acquisition device which interfaces with 64 discrete inputs; 32 analogue and 32 digital (user-configurable as either ON/OFF measurement or frequency/duty measurement). I'm targeting a maximum sample frequency of 1000Hz per channel, so 64,000 samples per second across the device.

I'm currently prototyping with a generic ARM-based embedded Linux device (Raspberry Pi, Beaglebone, etc.). Analogue inputs are read and serialised by SPI-based ADCs, with the digital inputs interfacing directly with the device's GPIOs and read via sysfs.

I'm finding that the time to measure all 64 channels within a GUI-based Linux OS is too long and presents enormous amounts of jitter (execution time of a single sample of all 64 channels can range from <1ms to ~10ms). I'm currently experimenting with different threading approaches, but I believe the core issue is trying to execute time-sensitive readings within a non-RTOS environment.

As such, I'm contemplating introducing a dedicated DAQ microcontroller into the design, which will interface with the 64 inputs, store intermediate readings in a buffer, then routinely pass the data to the OS (via one of the standard high speed interfaces).

My questions are as follows:

  1. Is there any point continuing with the Linux-based acquisition approach for a 64ksps requirement? Even if I could manage the sampling rate, I believe the jitter would still make this option untenable.
  2. If the microcontroller approach is sound, can you recommend a make/model?
\$\endgroup\$
1
\$\begingroup\$

64 ksps is nothing for a Pi, should be good on Beagle too, but not in userspace.

Jitter might be troublesome even in kernel mode, at least on SPI where the SPI master is allowed it's own queue. On GPIO it should not be an issue as long as you do it carefully. Would be easier with parallel DACs and GPIO I believe, but then hobbyist boards usually don't have that many pins.

A viable approach seems to be writing the data acquisition in a kernel module and forwarding it via the IIO subsystem. IIO has features which allow forwarding a circular buffer of samples to userspace but I have not used them myself (only used read on request).

Another approach is SoCs which have both a Cortex-A and a microcontroller, like the Sitara present in Beagle Black or some SoCs in the i.MX series. Take a look at PRUDAQ - the only active component outside BBB is the ADC. The advantage of this approach is that the two processors share their RAM making transmission easier.

\$\endgroup\$
  • \$\begingroup\$ Thank you Jan, that was a very informative response. I'm reading into IIO at the moment, this is a new concept to me, but certainly seems like a viable option. I'll actually be migrating to an i.MX device in the near future, so I'll bear that in mind as well. \$\endgroup\$ – jars121 Jun 6 '18 at 7:49
  • \$\begingroup\$ @jars121 in particular the 6 SoloX has a Cortex-M4F included in the SoC. 6UL or 6ULL should have one too but I'm not too sure. There should also be something in 7 or 8 series but I don't know about that. \$\endgroup\$ – Jan Dorniak Jun 6 '18 at 10:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.