rtel wrote on Thursday, October 10, 2013:
All are valid techniques, which is best really depends on the constraints of your system, and how you communicate these events to tasks that are using the touch interface.
If the periodic processing is self contained, and just updates local data value, then how long will it take?
If it is very fast, maybe triggered from a touch input interrupt that just has to update some data (like “button x depressed” flag) without ever having to block, then an ISR would be all that was needed.
If the periodic processing never needed to enter the blocked state then a software timer would be a light touch way of doing it - providing you are using other timers in your system already. Using software timers requires the creation of a daemon task (that is done by the kernel automatically), and if your touch interface that is the only thing using software timers then you may as well just create your own task and not use software timers.
If the periodic processing has to run indefinitely, or ever has to enter into the Blocked state, then you would have to perform the polling from a task - that would be your only option.
You could also consider adding polling into the idle task using the idle task hook function - if the rest of your application allows the idle task to run frequently enough to service the touch interface at the required rate. If the idle task is used then you cannot enter the blocked state, but the hook function will get called repeatedly allowing the use of state machine that maintains state across calls.