Mity CPU Platforms » MityDSP-L138 (ARM9 Based Platforms)

Hi Richard,

How are you creating the Semaphore? Zero initialization value?

Is it possible your routine that is pending is running slower than the 5 ms PRD timer (and you are effectively falling behind)? Are your timer routines running under interrupt service contexts (it shouldn't matter, just curious). You cannot pend on a semaphore from within an ISR, I am assuming you have a separate thread that is running the pend routine?

I will check with some users of this code here and try to see if they are using the semaphore notification feature and get back to you.

-Mike

Hi Mike,
I will check on the initialization value. I was calling the SEM_pend function immediately after requesting the DMA operation initially so that I wouldn't leave the routine before the transfer had completed. The last question was one that may have some bearing. I was calling the SEM_pend inside of the 5ms routine. I wasn't clear on whether that would effectively be running at interrupt level or not.

Thanks,
rich

If I did want to be sure that the operation had completed before moving on, is there an alternative approach. In this case polling would probably be ok, but I didn't see any methods in the class to support polling.
-rb

If you are calling SEM_pend() from within an ISR, you need to use a zero timeout. You could do a

while(SEM_pend(sem,0)) {}

For the type of processing you are doing, we normally decouple the processing phase from the data collection phase (and ping-pong the input data) in order to allow overlap of the data capture and the processing. E.G., kick the EDMA off in the PRD ISR, then run a high priority thread that basically sits on the semaphore and processes immediately following a DMA completion. E.G.

PRD_Handle()
{
    ReadFromFIFO(..., mysem);
}

EDMA_Handler()
{
    while(SEM_pend(mysem, SYS_FOREVER))
    {
        // process data
    }
}

Typically, we kick off the DMA from an ISR and pend for it in a task. Pending from within an ISR is not allowed. You could kick off the DMA from with the timer function, and pend for the semaphore within a monitoring task. This will avoid the problem of pending in the ISR, and allows the task switch to occur at the same time as the DMA transfer is happening, so the overhead to do the task switch would be (at least partially) covered by the transfer time. Set the priority of the DMA monitoring task pretty high so it doesn't get blocked by a lower priority task.

Dave

Mike and I apparently were typing simultaneously! Good thing we both came up with the same answer!
Dave

Great! Thanks very much guys. This should get me on the right track.