I have just isolated a bug in some code I’m debugging on a PIC24 project.  The code is using an API function in an ISR that runs at a priority higher than the kernel priority (1).  The priorities were setup because our AD has a very tight timing requirement for clocking the data in (if we take an interrupt in the middle we loose data).  The problem is the code right now is queuing up the data (a fair bit) from the ISR for external task processing and saving to an SD card.  This mechanism eventually crashes. So now I’m in a quandary, how best to handle this from an architectural standpoint?  Implementation as a queue was natural (as was a semaphore) but it appears that none of the OS centric solutions will work here since I can’t call them.  Valid assumption?  Am I stuck writing to a circular buffer I manage in the ISR and then having a task poll to see if new data has arrived?  Seems to defeat some of the reason I’m using an OS! Any help greatly appreciated, this has been quite a wild goose chase! Chuck

Since the interrupt is above configKERNEL_INTERRUPT_PRIORITY then the ISR can not user any FreeRTOS functions, so no queue to send data from ISR to task. You will need to fill a buffer in ram, and somehow signal the task the data is there, one trick would be to take some unused device, and have the A/D interrupt manually trigger it with the IF register, and have that interrupt set a semaphore, etc. Another option, if your processor supports it, is to use DMA to read the A/D and take an interrupt on buffer full, which would be less critical. (This may not be an option on your processor, I know some of the dsPIC33 have this, I don’t know if any of the PIC24s do.