µTasker Forum
µTasker Forum => µTasker general => Topic started by: ewan on December 03, 2008, 09:20:28 PM
-
Mark,
What is the general means of dealing with a task that consumes a lot of CPU time? In my case, 3 seconds of computation.
Thanks,
Ewan.
-
Hi Ewan
If you have a task which is heavily consuming CPU power there are several thinks to consider.
1. Is it a problem for the overall system? 3s is quite a long time and it may cause Ethernet input overruns to occur (more frequently than normally) and reaction times to other task will suffer. Although this will make things slower it doesn't mean that they fail - for example a web page may take longer to respond and it may have a TCP repetition but it still will complete.
2. Reaction critical things can still operate in interrupts. For example, the UART will still receive (not miss interrupts) even if a task is taking a long time (although it may require a longer queue to collect more characters). It may be possible to put some other time-critical things into interrupts rather than run them from tasks (as long as the interrupts are adequately short).
3. Is it possible to break up the 3s of task processing into smaller parts? For example if a job is being repeated 1000000 times it may be possible to do just one repeat and then exit the task to allow others to run and then immediately return (polling mode for this period of time) until the job has been completed. Then switch back to event driven mode on completion. This will then not cause any noticeable slowness of the complete system.
Often long processing times are associated with loops and one method which has been used is to schedule the system within such loops (calling uTaskerSchedule() - which is complete re-entrant). This is quite similar to 3 but doesn't require the task to be quit (which may require saving of information for it to be able continue later). The restriction is that the task doing this should not be scheduled during this interval (no timers or messages) since it then re-enters and this can become critical. Also it will get messy if there is more than one task doing this 'special' scheduling at the same time. The uTasker simulator doesn't support this operation but it does work correctly on real HW.
This is however a disadvantage of not having pre-emptive operation (see the following for more background and also reasons to why this method is still preferred: http://www.utasker.com/forum/index.php?topic=59.msg235#msg235) and in some cases it may be advisable to chose a pre-emptive solution to overcome the (possible) restriction. On the other hand there are often quite simple and elegant workarounds which are still possible up, depending on the specific case.
The basic idea of the uTasker operation is simplicity since it is surprising how many quite complicated projects can be solved with a 'simple' solution. By keeping the solution simple, risks are also avoided - some simple project can otherwise become over-complex and fail due to the fact that they have bugs or weaknesses due to pre-emptive operation which is not absolutely required. At the other extreme a very complex project may truly need a more complex solution, so it turns out that there is never a single tool, platform or solution which fulfills all requirements.
One idea to extend the usefulness (percentage coverage of projects which are truly suited) is to allow a time consuming calculation (something that can not be simply broken down to loops as discussed above) to be put on a 'back-burner'. This would be a single task which enjoys its own stack and operates in a similar way to pre-emptive tasks, possibly being allocated time-slices of CPU power to work its way through its job. This may allows a simple solution for one such complicated and time consuming process in a system without the complete system being required to adhere to new rules to allow complete pre-emptive operation, with its advantages and possible disadvantages...this is however only an idea at the moment...
See whether you get any ideas to solve your particular case from above.
Good luck.
Regards
Mark