Questions
How do I know that the taskDelay function takes a number of milliseconds as its parameter? You don’t. In fact, it doesn’t. The taskDelay function in VxWorks, like the equivalent delay function in most RTOSs, takes the number of system ticks as its parameter. The length of time represented by each system tick is something you can usually control when you set up the system.
How accurate are the delays produced by taskDelay function? They are accurate to the nearest system tick. The RTOS works by setting up a single hardware timer to interrupt periodically, say, every millisecond, and bases all timings on that interrupt. This timer is often called the heartbeat timer. For example, if one of your tasks passes 3 totaskDelay, that task will block until the heartbeat timer interrupts three times The first timer interrupt may come almost immediately after the call to taskDelay or it may come after just under one tick time or after any amount of time between those two extremes. The task will therefore be blocked for a period of time that is between just a hair more than two system ticks and just a hair less than three.(Note that the task will unblock when the delay time expires; when it will run depends as always upon what other, higher-priority tasks are competing for the microprocessor at that time.)
How does the RTOS know how to set up the timer hardware on my particular hardware? As we discussed earlier, it is common for microprocessors used in embedded systems to have timers in them. Since RTOSs, like other operating systems, are microprocessor-dependent, the engineers writing the RTOS know what kind of microprocessor the RTOS will run on and can therefore program the timer on it. If you are using nonstandard timer hardware, then you may have to write your own timer setup software and timer interrupt routine. The RTOS will have an entry point for your interrupt routine to call every time the timer expires. Many RTOS vendors provide board support packages or BSPs, which contain driver software for common hardware components – such as timers - and instructions and model code to help you write driver software for any special hardware you are using.
What is a “normal" length for the system tick? There really isn’t one. The advantage of a short system tick is that you get accurate timings. The disadvantage is that the microprocessor must execute the timer interrupt routine frequently. Since the hardware timer that controls the system-tick usually runs all the time, whether or not any task has requested timing services, a short system tick can decrease system throughput quite considerably by increasing the amount of microprocessor time spent in the timer interrupt routine. Real - time system designers must make this trade-off.
What if my system needs extremely accurate timing? You have two choices. One is to make the system tick short enough that RTOS timings fit your definition of “extremely accurate”. The second is to use a separate hardware timer for those timings that must be extremely accurate. It is not uncommon to design an embedded system that uses dedicated timers for a few accurate timings and uses the RTOS functions for the many other timings that need not be so accurate. The advantage of the RTOS timing functions is that one hardware timer times any number of operations simultaneously.
Other Timing Services
Most RTOSs offer an array of other timing services, all of them based on the system tick. For example, most allow you to limit how long a task will wait for a message from a queue or a mailbox, how long a task will wait for a semaphore, and so on. Although these services are occasionally useful, exercise some caution. For example, if you set a time limit when your high - priority task attempts to get a semaphore and if that time limit expires, then your task does not have the semaphore and cannot access the shared data. Then you’ll have to write code to allow your task to recover. Before writing this code which is likely to be difficult, since your task needs to use the data but can’t - it may make sense to ask whether there might not be a better design. If your high-priority task is in such a hurry that it cannot wait for the semaphore, perhaps it would make more sense to send instructions about using the shared data through a mailbox to a lower-priority task and let the higher-priority task get on with its other work.
A rather more useful service offered by many RTOSs is to call the function of your choice after a given number of system ticks. Depending upon the RTOS, your function may be called directly from the timer interrupt service routine, or it may be called from a special, high-priority task within the RTOS.
