Teensy 4.1--Interrupts or polling, and internal SD card

Status
Not open for further replies.
I need to acquire data from a 16 bit parallel ADC card at 250K samples/sec and stream to an SD card. The ADC card is driven by an external oscillator. I have currently running an Arduino Due, which is driven by interrupts from the ADC board. The Due fills its memory then writes the data to an SD card on an Adafruit data logging shield. The Due fails if I try to write to the SD card while recording.

This is acceptable, but not ideal, because I am interested in the spectrum of the input, rather than a continuous recording.* I would like to replace the Due with the teensy 4.1.

Question: What is happening with the 4.1 processor during a write to the internal SD card?

1. Will an interrupt during the WRITE disrupt the process?
2. If, instead of using an interrupt, I poll the ADC board, how long will the processor be unavailable? (Less than 4 uSec?)

Thanks.


*The original motivation was insight into what my dog is hearing: She hears frequencies above 50 kHz. The transducer is a Knowles MEMS microphone relatively flat past 80 kHz.
 
It depends on the library. On the 3.6 I can write about the same amount of data (and more) using my own interrupt driven code. (Warning: I use Forth rather than C.) I use the SDHC DMA system while the library does not. (Not sure about the 4.1 version.)

An interrupt will just slow the write process down if polled I/O is being used. If DMA is used the only effect is to slow down the code that runs before and after the DMA transfer but that doesn't matter much.
 
Thanks for the response.

I am trying very hard to avoid delving into the SDHC code.

Interrupts won't affect polling unless the ISR is longer than the sample interval. Then I lose a sample. I suspect that with the 4.1 speed, it would be OK, but I need a spec. I definitely don't want dueling interrupts.

Given that I already have the Due handling the ADC board, the sensible thing is to just add in the second processor. It's kludgey, but the whole thing is hardly elegant already.
 
I need to acquire data from a 16 bit parallel ADC card at 250K samples/sec...

Question: What is happening with the 4.1 processor during a write to the internal SD card?

1. Will an interrupt during the WRITE disrupt the process?
2. If, instead of using an interrupt, I poll the ADC board, how long will the processor be unavailable? (Less than 4 uSec?)

I think we've stepped into the twilight zone here. While I've acquired and stored a lot of ADC data at high rates with the T4.1, it has never been with a 16-bit parallel interface. I've used the internal ADC of the T4.1 and SPI-connected 16-bit ADCs, but never a 16-bit parallel ADC--even one that allowed me to read two 8-bit parallel bytes.

That said, you will have problems with longer recordings as the SD card---even using the much faster SDFat 2.0b library-- as writing does occasionally block interrupts for more than the 4 microseconds you need to do continuous logging--not often, but just often enough to be a problem.

If a 16-second snapshot is enough to do your analysis, you could log 4096 samples to the 8MB PSRAM on the T4.1, then save that to the SD card as a block after the sampling is done. (16 seconds x 500KB/second = 8MB) You're still on your own in figuring out how to connect that ADC to the T4.1,

To answer your question #1, the SDFat 2.0b code is very tolerant of interrupts during the write process. However it does occasionally disable interrupts for more that 4 microseconds.
 
Thanks for the reply.

Don't know about twilight zone, but often in the fog.

Parallel isn't hard except for getting all the blankety-blank wires sorted out. And, I don't have to figure out the SPI interface to some ADC board.
Based on another thread here, there do seem to be 16 contiguous bits on the 4.1. The Due has 16 bits on one register, but not contiguous--two blocks. A couple of bit-shifts fixes that. My next attempt will probably use a serial connection and try to be more compact.

The ADC is a Linear Technologies LTC1608 Demo board.

You've answered my question: the SDFAT code isn't going to be compatible with continuous write. However, you have reminded me of how much data I can store in a megabyte. Or, 500. So, it's write to RAM, Stop, Write to SD.

That's easier anyway.

Thanks.
 
The SDFAT code that I have looked at doesn't disable interrupts. At least at the SD interface level. I can't think of any good reason to disable them in any case.

For a parallel interface I would seriously consider using DMA to input the data. That may require a little glue logic for that particular ADC. Use a timer output to start conversions and you just have to sit back and wait for the DMAC to signal full blocks.
 
=UhClem;252729]The SDFAT code that I have looked at doesn't disable interrupts. At least at the SD interface level. I can't think of any good reason to disable them in any case.

UhClem is correct. I looked in the SDFat 2.0b code and interrupts are masked in only one place and that for about two instructions. That would not account for any sampling jitter.

I think the USB serial link was more likely the cause of sampling jitter I saw in some programs. If I don't poll for USB Serial input or send any output while sampling, I don't see any anomalies in collection timing that is controlled by an interval timer.
 
UhClem is correct. I looked in the SDFat 2.0b code and interrupts are masked in only one place and that for about two instructions. That would not account for any sampling jitter.

The problem I had with the Due was that the program worked some of the time, but occasionally hung the machine. I assumed my interrupt was occasionally falling in the middle of something critical with the SD code. Likely, it could be fixed, but I didn't pursue further.
 
Status
Not open for further replies.
Back
Top