My setup: MSP430F5529 running at 25 MHz MCLK

embOS 3.82s



All:

I found that I had a probable "race" condition when I use a single-byte mailbox and follow up with OS_WakeTask in the interrupt service routine.

I also found that the OS_Delay( ) that I added to the front end of the Task (after the while...) was not as good as OS_Delayus( ).



So, what I have found is that my code runs very well with the following...



Inside of the interrupt service routine:

//-----------------------------------------------------



OS_EnterInterrupt();

...



msg = 1;

OS_PutMailCond1(&MBRX,&msg);

OS_WakeTask(&TCB...);



...



OS_LeaveInterrupt();

//---------------------------------------



Inside of the task being "awakened" -



static void xxxTask(void)
{
char i,InMsg;



// Clear all associated flags...
ClearAll();

while(1)
{
OS_Delayus(2000); // works better than OS_Delay(2);



...



Some questions:

1. Is there an actual "race" condition without adding the OS Delay? (It certainly seems like it - I can see differences in the way my code behaves.)

2. It also appears that OS_Delayus gives better "granularity" than OS_Delay. Is that true?

3. It also seems that I need to give enough time for the OS to process my message, and if I put too little delay, it definitely makes a difference.

4. My original code did not have the OS_WakeTask added, so I was processing interrupts a bit slower than I wanted, depending on the time at the end of

the task to determine when I would process an interrupt.



Using task events was not an option initially for this "ISR --> task" situation, but I may look into using it, especially if it seems like there is a race condition.



Thanks for any input you might have!

I can definitely say that embOS has been a beneficial part of my life on this product!





Regards,

Todd Anderson

I ended up moving away from this and using a Task Event instead. It turns out that I can go from ISR to executing inside of a task in under 20 Usec with a task event, and the Mailbox + WakeTask was taking Milliseconds.



Regards,

Todd Anderson