Using requirements planning in embedded systems design: Part 6 – Determining your system’s task timing parameters
At this point in this article and in this series, there should also be a quick mention of the system clock. Once the system tick has been determined, a hardware mechanism within the microcontroller will be needed to measure it accurately. Typically, this job falls to one of the system’s hardware timers.
The timers in small microcontrollers usually have the option to either run from a dedicated crystal oscillator or from the main microcontroller oscillator. If a dedicated oscillator is available, then the oscillator frequency must be set at a 256 multiple of the desired system tick frequency.
In our example, that would be 512 kHz, or 256 times 1/.5 ms. If the system clock is employed, a pre- or postscaler will be needed to allow the system clock to operate in the megahertz range.
Assuming a prescaler based on powers of two, that means a 1.024 MHz, 2.048 MHz, 4.096 MHz, 8.192 MHz, or 16.384MHz oscillator. If none of these options are available, then an interrupt routine can be built around the timer, for the purposes of preloading the timer with a countdown value.
This value is chosen so that the timer will overflow at the same rate as the desired tick. Note that an interrupt routine is needed for this job because there will very probably be task combinations that will periodically overrun the system tick. An interrupt routine is the only way to guarantee a consistent time delay between the roll-over and the preload of the timer.
For our example, we will use a 4.096-MHz main system clock and a divide-by-8 prescaler to generate the appropriate timer roll-over rate for our system tick, and avoid the interrupt option.
Once a suitable timing tick is chosen, the skip rates for all of the system tasks can be calculated. This value will be used by software timers which will hold off execution of the state machine associated with the task, for X number of cycles.
This slows the execution of the state machine, so its operation is within its desired timing. Using the timing information from our alarm clock design, and assuming the modified Task1 scan timing, Table 3-5 below is constructed.
Note the values in parentheses following the skip rates. These are the skip rates for the maximum times. Assuming that the optimum time is not the maximum, then these values constitute the amount of leeway that is still available in the task’s timing. We noted this information for its potential use later in the design, when we define the priority handlers.
Table 3.5
Up to this point in the design, we have assumed that the system would use a rigid timing system that regulates the timing of the software loop holding the task state machines. However, there is another option for systems that are not required to comply with specific timing requirements. The option is to run the system without a timing control.
By far, the first option using a rigid timing control is the most common. However, in rare instances, when the timing tolerances are very broad or nonexistent, the second option can be implemented.
Now as a designer, you may ask, “What is the advantage to a completely unregulated system and what possible design could possibly operate without some regulation?”
The truth is, no system can operate completely without timing regulation, but some systems can operate by only regulating the functions that actually require specific timing. The other tasks in the system are run at the maximum speed of the main system loop.
For example, consider a simple user interface terminal with a display and keyboard. Button presses on the keyboard result in ASCII data being sent to the host system, and data received from the host is scanned onto the display. The only functions in the system that require specific timing are the serial transmit and receive functions interfacing with the host system.
The display and keyboard scanning rates only have to comply with a reasonable minimum scanning rate. In this example, the serial input and output tasks are typically regulated by the baud rate of the serial interface.
The control, display scanning, and keyboard scanning tasks could then be run at the fastest rate possible given the microcontroller clock frequency. The rate at which these three tasks operate would be variable, based on the execution time of each task on each pass through the system loop.
However, as long as the minimum scanning rates are achieved, the system should operate properly. The advantage to this type of system is that it operates more efficiently and more quickly than regulated systems.
There is no dead time at the end of each cycle as the system waits for the next tick; the system just jumps back to the top of the loop and starts into the next task. This saves program memory, complexity, and it means that every available system instruction cycle is used to perform a system function.
As a result, the system is very efficient, and will outperform a more rigidly regulated system. The only downside is that the tasks within the loop cannot use the loop timing to regulate their operation. Instead, they must rely on hardware-based timer systems for accurate timing.
The major downside to this system is that it requires a hardware timer for every software-timed function, and only works well for systems with few, if any, routines with strict timing requirements.
Loading comments... Write a comment