My application does some real time control, and optionally writes data to a SD card using exFAT SdFat, SdioTeensy
The SD card may or may not be present in the Teensy 4.1 SD card socket, and it may get ejected/inserted by a user at any time. But real-time control shall always continue no matter what. And logging shall (re)commence as soon as a card is in.
I do the sd card tasks in loop(), all real-time tasks are timer interrupt driven. With a FIFO buffer in between.
My problem is that with no card inserted, when my code polls for a card, it blocks (stalls the flow for) Serial1 communication for about 1 second. I think the i/o on that serial port does not flow, but the thread that interfaces with Serial1.available(), Serial1.read(), Serial1.write() does continue ok.
Other serial port (Serial that connects to Monitor) keeps flowing without hiccups.
Also Serial2 does not seem to be affected and happily carries on.
I have set interrupt priority for LPUART6 to 32. That does not fix it.
I have also tried setting IRQ_SDHC1 priority to a much higher number than 6*16, but that also does not fix it.
My thinking is that it's related maybe to a limited number of DMA channels, and that SdioTeensy claims a DMA channel (for up to a full 100000 us while waiting for a response from a uSD card that's not there...) that Serial1 also needs. Or some other scarce Teensy hardware resource. But I cannot find it when I dig into the many library sources.
What could this be? Is it yet another interrupt that is associated with DMA?
Is there any other way to detect card present in a way that does not stop my Serial1 data flow for up to 1 second after calling sd.begin(SdioConfig(FIFO_SDIO))? Or should I refrain from repetitively doing sd.begin and sd.end calls?
The SD card may or may not be present in the Teensy 4.1 SD card socket, and it may get ejected/inserted by a user at any time. But real-time control shall always continue no matter what. And logging shall (re)commence as soon as a card is in.
I do the sd card tasks in loop(), all real-time tasks are timer interrupt driven. With a FIFO buffer in between.
My problem is that with no card inserted, when my code polls for a card, it blocks (stalls the flow for) Serial1 communication for about 1 second. I think the i/o on that serial port does not flow, but the thread that interfaces with Serial1.available(), Serial1.read(), Serial1.write() does continue ok.
Other serial port (Serial that connects to Monitor) keeps flowing without hiccups.
Also Serial2 does not seem to be affected and happily carries on.
I have set interrupt priority for LPUART6 to 32. That does not fix it.
I have also tried setting IRQ_SDHC1 priority to a much higher number than 6*16, but that also does not fix it.
My thinking is that it's related maybe to a limited number of DMA channels, and that SdioTeensy claims a DMA channel (for up to a full 100000 us while waiting for a response from a uSD card that's not there...) that Serial1 also needs. Or some other scarce Teensy hardware resource. But I cannot find it when I dig into the many library sources.
What could this be? Is it yet another interrupt that is associated with DMA?
Is there any other way to detect card present in a way that does not stop my Serial1 data flow for up to 1 second after calling sd.begin(SdioConfig(FIFO_SDIO))? Or should I refrain from repetitively doing sd.begin and sd.end calls?