Schedulability analysis:
Worst case:
SERIAL_TOP
SONAR_ECHO
SONAR_DELAY
Pt = .83ms. At such low utilizations it is clear that we can run all of the other tasks at least once in one Pt period. So we know we won't fall behind on total work. But is this a strong enough statement? There are some critical deadlines that affect performance and quality.
Key deadlines:
1. INIT hi --> ECHO enabled > 500us
This is ensured by the SONAR_ECHO task. T2 is first used to count out 500us,
then it is used to capture the time of flight for the signal. We probably need
to add some offset to the T2 capture reading to account for the first 500us.
2. T2 Overflow --> Capture Mode Enabled (SONAR_DELAY) < (minimum time
of flight-.5ms) = .33ms
This is probably our tightest deadline. The worst case latency to SONAR_DELAY is
R(SERIAL_TOP) which is dominated by the isr_send_signal() system call. We are
probably okay. 330us is 880 machine cycles at 32MHz. Subtract the 20 machines
cycles that the OS adds to interrupt latency to get 860 available machine cycles
for R(SERIAL_TOP).
3. ECHO hi --> time of flight captured
This is done in hardware using capture mode so the guaranteed latency is at the
clock cycle level. The input sample rate determine the impact on precision. Not
sure if ECHO is sampled on machine cycles or clock cycles. Even at 32Mhz/12 our
distance error due to sampling rate is at most .0001 meters!
4. ECHO hi --> INIT hi for next measurement ... time from end of one
measurement to start of another.
This is a soft deadline, the sooner the better. More readings in less time. The
worst case time to completion of SONAR_BOT from ECHO-hi is indefinite if the
queue is full and the host does not send an acknowledgement. However, the system
is designed so that the queue can never be full (M causes the queue to be reset
and all pending measurements to be abandoned), and the queue is large enough for
a full complement of measurements and the average.
The best way to determine the worst case is with a call tree, though a timing diagram would help to visualize events. Worst case is: (RI followed closely by ECHO-hi) that would lead to the the following execution sequence: SERIAL_TOP->RECV_BOT->SEND_BOT, SONAR_TOP->SONAR_BOT. We have to account for the execution times of each routine as well as the three context switches that occur. Since we have limited stack use, we can assume ~200 machine cycles / switch, which dominates the run time. So the worst case is on the order of 600 machine cycles or .225ms between measurements. But, usually much less. Note that the OS time tick is likely to be much longer than the execution time of the routines so we don't consider its affects.
Finally, we have to process incoming characters before the next can arrive...we have 833ms to do it. That is plenty. But it is a hard deadline.
Issues:
Clearly stating the deadlines. Quantify them.
Coding style: Make your code scale independent...
Other points