jorsborn wrote on Saturday, April 20, 2013:
Thanks for the input! I’ll try to give a bit more information about what I envision for the tasks. It seems straight forward but I want to avoid any pitfalls…
Task 1 blocks and holds the mutex until an average ADC value is greater than or equal to some value. When it receives user input notification it ignores it (but still needs to know of the user input). When the ADC value reaches the trheshold, it will relinquish the mutex.
Task 2 and 3 are similar in that they contain state machines. Of the 5 possible user input buttons, two of them advance the states inside the task and the others cause the task to release the mutex. The process of releasing the mutex is rather quick (10 ms) and so wouldn’t cause any noticeable delay from the users perspective.
Task 4 contains a bit of code that once executed runs for a good 30 seconds. This bit of code is triggered based on an external interrupt (using semaphore?). Once triggered, it should not relinquish the mutex until done. So, task 4 has an idle state where it does a few things and it has a triggered state where it can’t be interrupted.
A few of the tasks (2,3 and 4) share access to a particular piece of hardware. However, as long as they cleanup before giving up the Mutex this shouldn’t be a problem at all.
Task 1 should be able to ‘command’ the other tasks to give up the mutex EXCEPT when task 4 has been ‘triggered’ and is doing its thing.