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:
- 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.
- If the microcontroller approach is sound, can you recommend a make/model?