Using requirements planning in embedded systems design: Part 6 – Determining your system’s task timing parameters
One of the key points in the design methodology described in this series of articles is that it must generate real-time programming. So, it follows that the analysis of the system’s timing requirements should be part of the system’s design.
In this last part in a six part series, we will examine the timing requirements of each of the software functions in the various tasks, and from this information, determine a timing system that will meet the system’s needs.
The first step is to list all the timing specifications from the requirements document. Note, if the functions grouped into a task have different requirements, then the specifications for each function should be included separately.
Now is also a good time to review the reasons for combining the function to verify that they should really be in a common task. In the example shown following in Figure 3.14, the timing requirements for our alarm clock design example are listed.
Entries for both the event-to-event timing and response timing are included in the time domain. If the timing requirement is listed in the form of a frequency, it should be converted to the time domain at this time for easier comparison with the other timing requirements.
Figure 3.14. Timing requirements listed in the form of frequency
Task1 Display
360Hz +20/-0 2.635 - 2.777mS
Alarm flash 0-50mS following time update (1Hz)
50% duty cycle +/-10%
Blank 909.9mS to 1111.1mS +/-0 overall
Sync to Time update
Response to Blank 8mS maximum
Task2 TimeBase
1sec +/-0 overall relative to internal or 60Hz
timebase switchover must occur within 8mS of
presence or absence of 5th pulse
Task3 Buttons
Button bounce is 100mS
Debounce is 50mS
Response to decoded command 34mS maximum
Auto Repeat 909.9mS to 1111.1mS +/-0 overall
Sync to time update 0-50mS following time update
Task4 AlarmControl
Alarm response to time increment, 100mS
maximum including tone startup
Snooze response time 50mS including tone shutoff
Task5 AlarmTone
Alarm Tone .454mS min, .5mS typ, .555mS max
Modulation 454mS min, 500mS typ, 555mS max
event to event
492mS min, 500mS typ, 510mS max
overall
Task6 Error Task
no timing specified.
From this information an overall timing chart for the individual tasks of the system can be compiled. This should list all optimum, minimum, and maximum timing values for both event-to-event and response timing requirements. Any notes concerning exceptions to the timing requirement should also be included.
Table 3.4
All the information needed to determine the system tick is now present. The system tick is the maximum common time increment, which fits the timing requirements of all the tasks in the system. The tick chosen must be the largest increment of time that will be divided into all of the timing requirements an integer number of times.
While this sounds simple, it seldom is in practice. Timing requirements are seldom integer multiples of each other, so the only solution is to choose a tick that fits most of the requirements, and fits within the tolerance of all the rest.
When a suitable tick is found, it should be noted in large letters at the bottom of the chart. This number is the heartbeat of the system and will be at the very center of all timing decisions from this point on.
The best tick for our alarm clock is 250 microseconds. Sometimes even the tolerances on the timing specifications will not allow a reasonable size tick that will fit every requirement. When this happens, the designer is left with a limited number of options:
Option #1: The designer can review the timing requirements for the system, looking for values that can be changed without changing the operation of the system. Timing requirements for display scanning, keyboard scanning, tone generation, and others maybe a matter of esthetics rather than an externally imposed requirement. The only real requirement may only be that they have consistent timing.
If the timing for one of these functions is the hard to fit value, experiment with the timing requirements for these functions. Often this will suggest other tick increments that may fit within the requirements of all the functions.
For example, the timing for the scanning routine in our example is 2.635 ms to 2.777 ms. However, if it were reduced to 2.5 ms for the minimum, then the system Tick could be increased from 250_S to 500_S. This still scans the displays at a greater than 60-Hz rate, so no flicker would be introduced.
Option #2: The second option is to consider moving some of the more difficult tasks to accommodate tasks to a timer-based interrupt. The interrupt can be configured to operate at a faster rate that accommodates the difficult tasks, and frees up the balance of the tasks to operate at a different rate.
(Note: if a task is moved to an interrupt, communications to and from the task will require either a semaphore or buffer protocol. This is because the task will be completely asynchronous to the other tasks, much as the tasks in a preemptive operating system. So, additional handshaking is required to prevent the transmission of partially updated communications variables, in the event that the timer interrupt falls in the middle of a task’s update.)
Option #3: Consider using a tick that is smaller than the smallest task timing increment. Sometimes, using a tick that is 1/2 or 1/3 of the smallest task timing increment will create integer multiples for hard to accommodate tasks.
(Note: This option will decrease the time available in each pass of the system and increase the scheduling job for the priority handler, so it is not generally recommended. If fact, the original tick value of 250_S was obtained using this option. However, shifting the display timing would eliminate the need for a smaller tick, so it was chosen instead.)
Loading comments... Write a comment