Shown here in the block diagram is how Timer_A or Timer_B drives the SYS/BIOS time base. In this case, Timer_A or Timer_B is configured to be driven by a DCO or crystal and in turn, asserts an interrupt to the MSP430 CPU at a configurable rate, which is often 1 kHz so that the interrupt occurs once every one millisecond. The SYS/BIOS timer module handles this interrupt and in turn, posts a software interrupt to the SYS/BIOS Clock module. The SYS/BIOS Clock module allows a developer to create any number of virtual timers that are all driven by a single hardware timer, and that can invoke an application’s function to execute at any specified interval. In addition to invoking application functions at periodic intervals, the SYS/BIOS Clock module also is used for kernel objects that have a timeout period associated with them. For example, if an application has a BIOS task that is pending on a semaphore with a timeout of 5 milliseconds, the kernel will create a corresponding one-shot timer object that will elapse at 5 milliseconds. Now, there is a problem with the design as TI has presented it, and some developers who are more experienced MSP430 software designers may have already seen it. The problem is that, MSP430 devices are typically used in applications that demand very low power consumption. If the SYS/BIOS heartbeat is defined to be 1 KHz, then that means that the MSP430 will need to wake up from low power mode once every millisecond in order to service this interrupt. That might be OK if real work needs to happen every millisecond, but if, for example, the developer only has a semaphore that times out after, say 5 milliseconds, then that means ones device will need to be pulled out of low power mode an extra 4 times in which it does nothing but increment the timer module and go back to sleep. For the developer who is thinking that one could deal with this by simply changing the BIOS heartbeat to 5 milliseconds, think about the pitfalls and complexity of that approach. Anyone who changes the timeout value in a, for example, Semaphore_pend call, will also need to realize that one needs to change the heartbeat rate to accommodate it, making ones code very complex and unmaintainable. It is these kind of complex interactions between hardware and software that a real time operating really can bring a benefit.