I have spent some time porting FREERTOS to avrXmega. I also wrote a graphic lib with touch support. I want to proceed with purting it all together but some things are not as obvious. My touch lib requires polling every 20 to 50 msec. I wish to have your advice on how to implement it best.
1) a task for touch
2) a soft timer
3) a hw timer wirh ISR.
I do realise that this also depends on the application priorities and goals, but as a general rule what are the points I need to consider to reach a conclusion?
Nearly the same question could stand for the methode to update the graphics, but this is a bit more complicated imho... so to start I will just stick with the touch library polling.
I hope this is not too much to ask.
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.
Hey Richard, thank you for the ideas.
Some words about the touch processing:
It works in 2 phases:
1) Check if there is touch. If yes, then reset the state machine to count x consequent
touch(true) states, with a period of 2 to 5 millisec. Between these 5 checks, the control is returned to the OS. The important thing here is that in this phase -if there is a touch - the touch-task period maybe decreased down to 2 to 5 milliseconds for 2 to 5 calls.... ( 5 to 2 , 2 to 5 means any combination that allows for 10 milliseconds of filtering).
In any case , this phase lasts only a few microseconds to process, just to check a pin, and update a variable or 2.
When the first phase is satisfied the state machine enters phase 2.
2) communicate with sensor, get touch coordinates and save them in a touch-event queue, then return controll to OS. When the touch procedure is called again (within reasonable time , say 10 to 30 millisecs) if there is still touch(true) it is aquired, compared to previous, and maybe save as touch-drag event on the queue.
Otherwise if the touch is lifted, the state machine is reset to state 1.
The processing in phase 2 is critical for about 400 microSeconds, that is the time needed to get data from the touch(over spi), plus some cycles to update 2 integers with the coords. That is of course if there is touch data. If noone is touching the screen, then it is less than 10 microseconds. I would avoid using ISR directly from the touch sensor: filtering the noise after a touch event is 3 to 10 milliseconds long, so it would complicate things with the state machine. SO if I will be using any ISR approach, it would be either the tick hook ( with a 1/20 proc local static counter), or any other hardware timer dedicated.
I am still trying to "See" all 3 ways in my head before I try anything. But now the forum has some numbers from me to consider. ANd of course all 3 implementations will need tunning. But since there is a critical period of 400microsecnds, maybe this changes the best choise.