NetBurner Community Forum

The version of the bsp.c for the Coldfire MCF5272 has the following lines:
#if (TICKS_PER_SECOND >200)
#error TICKS_PER_SECOND too fast
#endif

#if (TICKS_PER_SECOND <10)
#error TICKS_PER_SECOND too slow
#endif

What I would like to know is what was used to determine these limits. In particular, I would like to know if the system might in fact work well with a time resolution of 2 milliseconds rather than 5 milliseconds.

Why do you need finer tick resolution?

The ONLY thing tick resolution sets is the granularity of time out.

It has nothing to do with normal task switching.

Increasing the number of ticks actually SLOWS things down as the system spends more time servicing the
timeout values. 90% of the non task specific RTOS overhead is directly proportional to the ticks per second.

If you have one specific task that needs finer time measurement then use one of the PIT timers or the
high resolution timer classes as added by Larry about a year ago.

specifically:
DWORD GetPreciseTime( void ) for a much finer timer value and
the PIT Application notes stored here:
http://www.netburner.com/support/techni ... ments.html

Ticks per second is set in constants.h the comments in that file:

/*

PLEASE READ THIS BEFORE MODIFYING TICKS_PER_SECOND

Before you change this value understand what changing it does.
Making it faster only slows things down. It does not speed up task switches,
If only changes the granularity of timedlays and timeouts.
Task switches happen much much fater than the tick interval. They happen as
soon as one task blocks or an interrupt /or task causes a higher priority task
to be unblocked. The Time tick has NOTHING to do with task switches.

If you change it to the maximum 200 you have increased the RTOS overhead by a factor
of 10 and have actually slowed your system.
*/

The faster the tick rate the more overhead the OS will impose on the system. The "execution time of OSTimeTick() is directly proportional to the number of tasks created in an application ".* Since there is no way to know in advance how many tasks an application will have I would assume some reasonable limits were used based on the clock rate of the processor and the fact that Micro-C/OS II (which the NB OS is derived from) recommends values between 10 and 100.

If you can't use interrupts for responsiveness, and can't coordinate dependent tasks with mailboxes or semaphores then possibly a high tick rate and the ability to put a task to sleep for a shorter period of time might have a benefit. Paul would know better than I do if this is true. The other thing I don't know is if OSTimeTickHook() has any code. If it does then the price of OSTimeTick() just got steeper. Your question is interesting because while the system overhead may increase by over an order of magnitude when the value goes from 20 to 200, I have no idea what the impact is on a typical application. If the Overhead is .001% then going to .01% is probably irrelevant. If the overhead is 1% then it's a pretty big deal.

*from 3.11 of MicroC/OS/II The Real-Time Kernel Second Edition - Labrosse

(I wrote most of this before I saw Paul's response - so I edited it somewhat, thinking some of the info might be of interest.)

[quote="pbreed"]Why do you need finer tick resolution?

The ONLY thing tick resolution sets is the granularity of time out.

Indeed that is precisely what I want, to have a task that times itself via OSTimeDly to run every 2 milliseconds, rather than some longer period. Is there some way to achieve this other than changing the tick resolution.

Take a look at the PIT timer example mentioned in my first post.

You should take a look at the timer utility that I have posted to the forum:
http://forum.embeddedethernet.com/viewt ... ?f=7&t=397
I use this quite often, mostly for calculating timing when optimizing code. I actually just updated this file today to the latest version. You will need a free DMA timer to use this utility. For a 2ms OSTimeDly-like delay you just call StopWatchDelay( 0.002 );. The problem with very short delays like this is that task switching will take up a larger percentage of your total CPU time. If you are doing delays any less then 1ms then you will be better off using the StopWatchPollingDelay function. This function will not task switch which also makes the delay more precise.

-Larry Gitlitz