paco-torres wrote on Monday, November 11, 2019:
First, thank you all for the complete and fast replies! 
I continue replying to each one on individual reply posts.
paco-torres wrote on Monday, November 11, 2019:
First, thank you all for the complete and fast replies!
I continue replying to each one on individual reply posts.
paco-torres wrote on Monday, November 11, 2019:
I thought about it, but it is too complex because each and every task (28 tasks, the application has certain complexity) waits on different expressions in different moments. Although in the original code there are also flags (=event groups on FreeRTOS), semaphores, mutexes and queues, the task’s synchronization is strongly based on waiting for expressions of globals that represent the state of a subsystem, and that can be changed by other tasks. It is doable, but will imply so many changes that I think I’d better re-write from scratch rather than port.
paco-torres wrote on Monday, November 11, 2019:
That is a good approach Pete!
paco-torres wrote on Monday, November 11, 2019:
That is correct Richard, it is a macro in OSA. And yes, better to yield rather than delay. Then the scheduler checks for the expression and if true returns the processor to the task (priorities apart). The minimum latency would be two context switches plus the time taken by the scheduler to check for the expression, which is fast enough for the majority of non critical tasks.
paco-torres wrote on Monday, November 11, 2019:
OSA had eight priority levels, cooperative kernel and round robin scheduler, I did not use priorities in this application , so your guess is correct: I could use OS_Wait with peace of mind that no starvation would ever occur.
paco-torres wrote on Monday, November 11, 2019:
I think that I will take Pete’s suggestion + Richard’s comment and do a loop that yields until the condition is met, but just to be sure:
FreeRTOS does not allow waiting on anything but RTOS objects, does it?
richard_damon wrote on Monday, November 11, 2019:
The one option I can think in this situation is that the tasks that wait on conditions instead wait on an event group, and when woken ckeck the condition, and if not true go back to the wait. Tasks that change the state variables, notify the event group.
You could use a seperate bit in the event group for different variables, so a task would only wake up if a relevent variable was changed.