Using Teensy 4.0 as a USB to SPI bridge

Status
Not open for further replies.
My use case requires me to send Computer (USB) -> Teensy 4.0 -> SPI -> Peripheral I am attempting to send data over USB (potentially USB serial or is there any other way). My data transfer requirement is sending 40,16-bit data, 4000 times a second, which translates to around 2.56Mbits per second.

I plan to cache ~1 second of data, which is 2560000 bits or 320 Kilobytes or 312.5 Kibibytes

I am looking for guidance regarding:

  1. Caching mechanism (mutex), and 1024 bytes of RAM availability, parallelly transfer data from USB to Teensy 4.0 to SPI. i.e. Threading within Teensy / Arduino.
  2. How to effectively transfer 320kb of data per second over USB to teensy 4.0?
  3. Text-based serial transfer or hex bytes? Any links or articles. Encoding methods, USB frame size optimization.
  4. Is there any other language to program Teensy 4.0 for this purpose that could be more effective than Arduino (TeensyDuino)?

Sorry apologies for the basic questions, I am new to Arduino based programming.
 
0. USB is the fastest way to get data into a Teensy 4.x - haven't tested that direction - but the Teensy 4.x can send to PC at 6 to 20+ MB/sec - depending on the PC's ability to keep up.
1. Running T_4.0 might have 500-800KB of RAM depending on the sketch ... perhaps more - but it is split between 512KB each in RAM1 and RAM2
1.a A Teensy 4.1 (RAM the same) can add an 8MByte ram chip (or two) that could store at that rate - though writing to it to buffer, while reading the buffer to transmit may tax the needed throughput.
2. 320KB per second into the Teensy should be trivial.
3. USB Frame size is 512 bytes AFAIK. Text may be larger - but either should pass fast enough in that range - it may depend on having it formatted as needed for direct transmission without conversion
4. Arduino / TeensyDuino is just an organized uniform platform using of C/cpp code with ASM as needed. Leaving that platform will discard available working libraries and not likely be any more effective.

Not sure what the SPI device at hand is and how fast it can consume the data, and beyond one or 3 seconds to fill 1024KB the run time is expected to be? Also that would need to be set up to run in an interruptible or non blocking fashion to maximize the USB reception and storage.

Reading 320KB/sec is 625 blocks of 512 bytes read per second. Receiving and transferring those blocks to storage for SPI to transmit will take some amount of time. That could be set up and confirmed to work and managed and then gauging the CPU resources consumed.

The hard part will be keeping the SPI bus reliably taking that data at speed, while letting the USB data be stored. That could SPI part also be tested as above - just transmitting the same data over and over and then gauging the CPU resources consumed.

If both can run at the same time that is a good start - then making sure any data coming in faster then going out would have to be resolved through safe buffering.
 
0. USB is the fastest way to get data into a Teensy 4.x - haven't tested that direction - but the Teensy 4.x can send to PC at 6 to 20+ MB/sec - depending on the PC's ability to keep up.
1. Running T_4.0 might have 500-800KB of RAM depending on the sketch ... perhaps more - but it is split between 512KB each in RAM1 and RAM2
1.a A Teensy 4.1 (RAM the same) can add an 8MByte ram chip (or two) that could store at that rate - though writing to it to buffer, while reading the buffer to transmit may tax the needed throughput.
2. 320KB per second into the Teensy should be trivial.
3. USB Frame size is 512 bytes AFAIK. Text may be larger - but either should pass fast enough in that range - it may depend on having it formatted as needed for direct transmission without conversion
4. Arduino / TeensyDuino is just an organized uniform platform using of C/cpp code with ASM as needed. Leaving that platform will discard available working libraries and not likely be any more effective.

Not sure what the SPI device at hand is and how fast it can consume the data, and beyond one or 3 seconds to fill 1024KB the run time is expected to be? Also that would need to be set up to run in an interruptible or non blocking fashion to maximize the USB reception and storage.

Reading 320KB/sec is 625 blocks of 512 bytes read per second. Receiving and transferring those blocks to storage for SPI to transmit will take some amount of time. That could be set up and confirmed to work and managed and then gauging the CPU resources consumed.

The hard part will be keeping the SPI bus reliably taking that data at speed, while letting the USB data be stored. That could SPI part also be tested as above - just transmitting the same data over and over and then gauging the CPU resources consumed.

If both can run at the same time that is a good start - then making sure any data coming in faster then going out would have to be resolved through safe buffering.

@defragster: Thank you for your detailed response. I am glad that the chip choice is pretty in line with the requirements. Though I should ask a clarifying question regarding the caching. the one-second cache was arbitrary. I thought caching would be required to get USB in line,Ideally, I would like the cache to be as minimal as required, to minimize latency. With regard to my downstream device, it is an AD5370, which can consume data at 50mhz over SPI, i.e. 50 mbits / sec.
 
Status
Not open for further replies.
Back
Top