joehinkle wrote on Saturday, July 21, 2018:
The title is misleading so let me explain
I have a task that reads data from an SD card and feeds a I2S DAC.
original code looked like this and it worked … but
Audio task
{
while(1)
{
xTaskNotifyWait(…) … wait for I2S Interrupt to release
read data from SD card and ready buffers for next I2S package
}
}
I2S Interrupt uses xTaskNotifyFromISR() to release loop in Audio task … this occurs every 25 msec
The above code works very well with SD card read routines polling for status status.
I have found that the first SD card read following a period of no SD card activity (that period is 10 msec) that the SD card can take 3 msec or longer to prodive the sector. 3 msec of spinning doing polling is an unacceptable amount of wasted time.
So I changed the SD card routines to wait (also using a xTaskNotifyWait() ) until the SDHC interrupt first indicating the sector was acquired.
My problem … the SD card reads can delay the SD data acquisition process beyond the 25 msec I2S period so when I enter the xTaskNotifyWait() for the SD card - it returns immediatly because the I2S interrupt had issued its xTaskNotifyFromISR().
Is there a way to implement two task notification events without having them interact? (SD xTaskNotifyWait() only responds to SD xTaskNotifyFromISR() and main audio loop xTaskNotifyWait() only respond to IS2 xTaskNotifyFromISR()?
I hope I explained this so it makes sense.
My one thought is to look at the xTaskNotifyWait() in the SD routine and if it shows I2S then set a flag and re-issue the xTaskNotifyWait. Upon leaving the SD routines check for the flag and if set … bypass the Audio xTaskNotifyWait() … is there a better way?
Thanks.
Joe