Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 9 of 9

Thread: Teensy 4.1 - Data flow from parallel data sources to SD card

  1. #1
    Junior Member
    Join Date
    Jan 2021
    Posts
    5

    Teensy 4.1 - Data flow from parallel data sources to SD card

    I'm working on a concept for a high-speed data acquisition device using the Teensy 4.1 and Maxim Integrated's MAX1448 ADC chip. The ADC provides data in a 10-bit parallel format, with one output pin for each bit. I'd like to read in this data and write it to an SD card. The ideal case would involve writing the time of conversion (via the timer/counter used to set the ADC clock) and the 10 bits of data to a file on the SD card. I've considered trying to serialize the data before it reaches the Teensy, but many serializers give an LVDS output, which isn't supported by the Teensy 4.1. I've attached a very basic diagram of the process I'm looking at.

    Is the Teensy 4.1 capable of serializing data like this? Or is there a better option rather than using 10 GPIO pins (one for each bit)?

    Attachment 23580
    Attached Thumbnails Attached Thumbnails Click image for larger version. 

Name:	ADC-SD PATH v2.jpg 
Views:	11 
Size:	20.8 KB 
ID:	23581  

  2. #2
    Senior Member
    Join Date
    Apr 2020
    Location
    DFW area in Texas
    Posts
    230
    @landshark42:

    You mention high-speed data acquisition, so I understand that minimizing time between samples is probably high on the list of important requirements here. Could using a shift register to take in the parallel bits & allowing the Teensy to clock them in serially thru a single pin provide any advantage over having to read 10 separate pins & mask/shift/combine them?? Just trying to think outside the box here . . .

    Mark J Culross
    KD5RXT

  3. #3
    Including the conversion time is a wasted effort. The ADC requires a clock input with very low jitter which means that you know (or should know) the timing precisely. Use that clock to trigger the DMAC which reads the data in parallel, putting it into a buffer. When the buffer is full, switch to the next (you will want as much buffer space as possible) and schedule the full buffer for writing to the SD card.

  4. #4
    Junior Member
    Join Date
    Jan 2021
    Posts
    5
    I like the concept of combining the data on the front end. Am I correct in thinking that the data read process would depend on my CPU clock speed and that each bit read will take one clock cycle? I'm wondering how to make sure I don't end up with bits of data "piling up" at the GPIO pins. In my example above, I have CPU at 600 MHz and ADC at 75 MHz. In this case, I'll have a new batch of ADC data after 8 CPU clock cycles.

  5. #5
    Junior Member
    Join Date
    Jan 2021
    Posts
    5
    Quote Originally Posted by UhClem View Post
    Including the conversion time is a wasted effort. The ADC requires a clock input with very low jitter which means that you know (or should know) the timing precisely. Use that clock to trigger the DMAC which reads the data in parallel, putting it into a buffer. When the buffer is full, switch to the next (you will want as much buffer space as possible) and schedule the full buffer for writing to the SD card.
    When working out the concept, I was thinking about getting an output similar to what I get from an oscilloscope in the lab. From those, we work with .csv files with both time and voltage for each data point. You are correct that I'd know the timing. In my example at least, it would be every 8th CPU clock cycle from the initial trigger event. My main concern would be to make sure that the bits are properly separated between conversion events, but I imagine that can be done in the coding process.

  6. #6
    Senior Member
    Join Date
    Jul 2014
    Posts
    3,125
    Quote Originally Posted by landshark42 View Post
    In my example above, I have CPU at 600 MHz and ADC at 75 MHz. In this case, I'll have a new batch of ADC data after 8 CPU clock cycles.
    so serializing it upfront would give you 750MBit/s. that does not fit your Clock speed.
    serializing it in Teensy does not change the situation.
    Even if you pass directly onto microSD you would need a microSD click speed of al least 150 MHz and I double you can achieve this.

  7. #7
    Junior Member
    Join Date
    Jan 2021
    Posts
    5
    Quote Originally Posted by WMXZ View Post
    so serializing it upfront would give you 750MBit/s. that does not fit your Clock speed.
    serializing it in Teensy does not change the situation.
    Even if you pass directly onto microSD you would need a microSD click speed of al least 150 MHz and I double you can achieve this.
    Isn't the M7 processor capable of two instructions per clock cycle? If I use two serializers/shift registers, each assigned to 5 bits, I would need 375 Mbps for each input pin. Assuming that the processor is able to successfully execute the read instruction on both pins in one cycle, that is well below the 600 MHz clock speed.

    If the processor can't reliably execute two instructions per clock cycle, then it looks like overclocking and cooling would be required to reach the speeds I'm targeting.

    Regarding the microSD, the RT1062 manual and data sheet both indicate that the SDIO is capable of up to 208 MHz for 832 Mbps across the 4 data lines D[0..3]. I imagine the CPU would have to do some rearranging of the data to split it across those 4 lines, but it looks to me like it should be possible on the SD end.

  8. #8
    Why in the world would you serialize the data? I could see doing it if you were short on I/O but you aren't. Even at 75MSPS that fast processor is going to be hard pressed to read and do something with that data which is why you must use DMA.

    As for that 208MHz spec on the SD port, that assumes that the particular SD card supports it and the code does as well. I have no idea if the code does but it wasn't that long ago that the library for the Teensy 3.6 didn't even bother to switch from 25MHz to 50Mhz. Using higher speeds requires switching the signal levels as well as the clock. Then of course the SD card cannot write data at 150MB/s.

    If you really need to capture data at this speed and in quantity, you should be using a FPGA connected to a mess of SDRAM.

  9. #9
    Senior Member
    Join Date
    Jul 2014
    Posts
    3,125
    Quote Originally Posted by UhClem View Post

    If you really need to capture data at this speed and in quantity, you should be using a FPGA connected to a mess of SDRAM.
    Agree with that

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •