Once again dealing with the FreeRTOS/KDS/KSDK combination.
I just tested that new configuration, whereby one task receives commands and another does the processing.
There seem to be multiple things wrong, but here's the biggie:
I set out to use binary semaphores. One task waits on the command-has-been-received semaphore, and the other sets the semaphore when a command comes in. There's a second semaphore involved, for dealing with likely future complications.
For good and sufficient reasons, these should be binary semaphores, or counting semaphores that can't count above 1.
Well... the KSDK OS Abstraction doesn't do that. It does, however, do mutexes*... which, according to the FreeRTOS documentation, are close enough for my purposes. So I write it to use mutexes.
It doesn't work. The processing loop waits once, then buzzes around.
The abstraction layer is being helpful. If the calling task already owns the mutex, it returns immediately with error status.
Great. Looks like I need to bypass the abstraction layer and call the FreeRTOS binary-semaphore functions directly. Or the mutex functions, even.
What I need is a binary semaphore, such that if it's currently zero, the calling task will always wait for someone else to come along and set it. This Should Just Work.
(Yeah, maybe if I'm very careful I can get away with using all-purpose counting semaphores. Binary semaphores are safer in this context, and more conceptually appropriate given that they're associated with single message buffers.)
* Not to be confused with mutoids.
Comments