Hi,
at the moment I have a task to sample the keypad and do the debouncing.
But after using the software timers to control LEDs, I think that perhaps using a task for just sampling a keypad or buttons is too much waste of resource? Is that correct?
Would it be more elegant to just use
What is the best practice out of the two?
Out of curiosity could you provide some practical examples of common tasks where software timers - specifically in RTOS - are a more elegant solution than using tasks (apart from obvious general timeouts, time delays)? I am wondering about some clever/unusual ways you might not normally think of using them for. Again, specifically in RTOS applications/setups.
If your application is small, then perhaps sampling the keyboard in a task is not a waste. Clearly it will not require much overhead and it is a small simple piece of code. But as resources get tight, you will want to do more work in each task as the overhead for each task can be significant. Generally the key sampling is done every 20ms or so and the key handler would generate a key related event every 100ms or so. This is easily a timer task and that allows a single task to do lots of different activities. This pattern is useful for lots of housekeeping activities like LED, buttons, sensor readings, low speed motors.
Where this pattern runs into trouble with timers is when the time required to execute all the callbacks exceeds the time available for the single timer task. Each timer callback essentially executes sequentially as their schedule arrives. If each callback takes 1ms to execute and you have 1000 of these tasks, you will be out of timer task time. Other tasks may still execute because they will preempt the timer task but the timer callbacks will start to operate erratically as FreeRTOS makes a best effort to maintain the schedule.
If you are running the timer task out of time, there is no way to prioritize one callback over another. This can be done with tasks. You could even emulate the timer tasks pattern by creating a user task and executing a number of activities in it. Then the user task could operate at a different priority and you would get some control over behavior when the CPU is running out of cycles.
I don’t think I have given you a nice list of neat things to do with timers. But hopefully I have given you some data to decide where to execute the functions needed by your application.
Thank you Joseph,
yes, that makes a lot of sense and does provide me with a method to better choose the strategy to implement software timer tasks by taking into account the callback length, frequency of calls, timer queue etc.
Very useful!
Although this post is in spanish, the examples are mostly in english, so you might find interesting how to use the software timers in such simple processes.