Hi Ab
1) In some newer project packages there is a define
MONITOR_PERFORMANCE. This allows a hardware timer to be used to measure the time taken for each task to run, plus the time spent in idle. Via the command line menu the information can be displayed for all tasks, including the CPU load in %. Since you are working with the STR9, which is not being further maintained due to its unpopularity, you will not have this new code. I will send you a different package so that you can can see the code that is used - as long as you can configure a HW timer in a similar fashion this will work on your processor.
2) The uTasker scheduler is a co-operative scheduler and so doesn't perform context switches. The philosopy is based on state-event operation and the use of interrupts for high priority work and some prioritising. There are advantages and disadvantages with different scheduling strategies, but experience has shown that the used method enables a high percentage of embedded projects to be realised simpler and with less risk using this method, resulting in much lower use of resources and also very good response times, when used correctly.
In addition, it has been suprising to learn that many (professional) developers prefer not to to use any operating system in embedded designs. Of course they still (usually) need some form of scheduling loop, so the uTasker schedule gives a more formal solution to such users who otherwise prefer to rather have nothing at all.
Embedded systems can be designed and developed using different techniques and the actual operating system/scheduling strategy used doesn't necessarily say much about the final solution. The final solution can be very good - or very bad - using every possible strategy. A good solution is of course to be strived for and, as mentioned above, can very often be achieved faster and more efficiently using the co-operative strategy; in some cases it may be the other way around so it is always up to the embedded software designer to decide what is best suited to a particular case and design the system accordingly. It is felt that the uTasker strategy offers many advantages and so it was decided to follow this strategy - if every embedded operating system, worked the same and could only be compared by the number of machine instructions to perform a context switch it would make life very restrictive - different people prefer different strategies and that is why the uTasker project is there, to offer a certain style for those who find it suits them.
It is not to be forgotten that the heart of the project is also the simulator. The goal is to allow users to save time developing/testing/debugging real systems. The simulator and the scheduler together are what can make big development time differences in comparision to convertional methods.Regards
Mark
P.S. There are various other discussions about this - see, for example,
http://www.utasker.com/forum/index.php?topic=846.0