SPI frequency too low for real-time data acquisition

bigdlin

Member
I am working on a project that requires sampling 32bit data at 30kHz on 64 channels. Currently, I am only able to push the sampling rate to be at 7.4kHz. Teensy4.1 is overclocked to 960 MHz and the SPI ckockin is 21M. Is there a way to feasibly achieve the desired sampling rate? Open to adding on a separate SPI driver if necessary but would appreciate suggestions.
 
You don't say what how many SPI devices or what type, but assuming there are at least 3, Teensy 4.0 has 3 x SPI, so you could at least triple your throughput by using them all.
 
4 devices, each with 16 channels, so 64 channels in total. using 2 SPIs, so 2 devices per SPI. Teensy runs serially so I don't think it matters how many SPI I'm running. Please let me know if I'm mistaken.
 
Maybe the SPI async functions can help use 2 or 3 SPI ports more effectively?

Most ADC chips have some overhead, like a command byte before the data transfer. Even with no overhead, 32 bits times 64 channels times 30 kHz sample rate is 61.44 Mbit/sec. You'll probably need to use all 3 ports in parallel.

What you'll actually do with so much data at that speed is also a good (difficult) question.
 
Maybe the SPI async functions can help use 2 or 3 SPI ports more effectively?

Most ADC chips have some overhead, like a command byte before the data transfer. Even with no overhead, 32 bits times 64 channels times 30 kHz sample rate is 61.44 Mbit/sec. You'll probably need to use all 3 ports in parallel.

What you'll actually do with so much data at that speed is also a good (difficult) question.
This sounds like the kind of problem I'm thinking about in my NYWWIP (Not-Yet-Working_Work-In-Progress). If I get it working, one T4.1 would handle two SPI converters and send the data to T4.1 #2 over a fast, block-oriented USB link with minimal foreground CPU overhead. T4.1 # 2 would handle two SPI converters and merge the data from the two systems into blocks written to SD card. The overall data rate, at about 8MB/second is well within the capabilities of the SD card write rates (with appropriate buffering). At that point, you add MTP to get the data to the PC and let MATLAB or Python sort out the results. Simulating this collection sounds like a good example program for when I get USB_block_xfer working.
 
You’ll probably need to go DMA SPI. With lots of interrupts handling. And a timer to get the 30 kHz sample trigger pulse. Can be done, i did something similar some time ago, and shared code for a T4_DMA_SPI class. A train of SPI ‘transactions’ needs to be defined in a table upfront.
What’s the data / SPI slave chip? Is it ADCs? MEMS? A camera?
Is it 3 or 4 wire SPI? Daisy chained or paralel?

link with code
 
Is the data actually 32bits? or is it a 24bit converter sending a 4byte result?

Depending on the converter, some will allow the result (eg ADC) to be sent as 3 bytes (24bits) instead of the 32 saying you 25% throughput.
 
This seems very curious and not the norm:
Screenshot 2024-02-08 153805.jpg


Typically the SPI bus is shared and additional CS lines are used to select the chip you want to talk to. Why are they doing it this way?

bigDlin do you have them wired this way? Is it working?

Also I meant to ask previously, have you tried running the SPI clock faster?
 
That's for full bandwidth for each chip I guess - more microcontrollers these days have quadSPI for instance.
 
@strud, Intan Tech uses opalkelly as the controller, so it can do 4 SPI ports. On my teensy I'm using 2 SPIs and 4 CSs. I did try to increase the SPI frequency. it'll read back junk when I increase it from 21-22MHz. Thats why I set 21MHz as the max speed. Might be a technical limitation of my design. Regardless, is there a recommendation on an external SPI controller to use to make my life easier?
 
Hi bigdlin,

For a data point, my board has no issue running the SPI clock at 50MHz for the ADC I'm using with a Teensy 4.1.
 
Back
Top