Understanding what is RT

Interface 2: 3.
Serial 40Mhz Control Sw
2.
Video 1.
Codec Packetise
and Transmit
RAM
Some more info about our hw devices
• The 802.11 chip has a parallel bus, and interrupts the CPU when it's
ready to send a packet
• Interface 1 – task 1 packetises the compressed image data and
outputs it to the 802.11 device for transmission
• We measured task 1 taking 6ms of CPU time, and due to the unusual
802.11 packet format, it's triggered by an external interrupt from the
peripheral every 19ms
• The task hogs the parallel bus for 2ms during this operation
• The camera is 320x240 resolution, with 8-bit greyscale pixels.
• It runs at 24 frames per second.
• The data for each frame is transferred serially 8-N-1 at 40MHz
• The data is then encoded using a H.263 video codec which we
measured as taking 8ms to compress an entire video frame and store
this to RAM
First, how should we handle the serial data?
320 x 240 76,800 pixels
8-bit greyscale means each pixel is a byte
8-N-1 1 start bit, 8 data bits, No parity and 1 stop bit which means 10-bits for
each byte transferred.
Transfer time 76,800 * 10 = 768,0000 / 40MHz = 19.2ms
If task 2 handled each byte as it comes in to the CPU it would be triggered
when the first byte arrived, and only receive a full frame 19.2ms later.
It then needs 8ms to compress this, so only finished 19.2+8=27.2ms later –
missing the 24ms deadline for the start of the next frame! So we should use
DMA...
• DMA is direct memory access – it's where the peripheral is allowed
(by the CPU) to send data directly to memory without it going
through the CPU first...
• So data transfers use (almost) no CPU time!!
• If we use DMA, the task is triggered every 24ms when a new frame
has arrived in RAM, then spends 8ms encoding it.
• The 802.11 chip interrupts the ARM when it receives a control packet.
Interface 3 - task 3 handles this.
• We measured task 3 as taking 5ms of CPU time
• These packets aren't periodic, but we found they were never more
frequent than once every 42ms
• But the handling for this MUST be complete within 36ms of being
received
• This task also hogs the parallel bus for 2ms
Summary:
• Task 1 is periodic every 19ms and requires 6ms of CPU time.
• Task 2 is periodic every 24ms, and requires 8ms of CPU time.
• Both must finish their current processing before being triggered
again.
• Task 3 needs 5ms of CPU time to execute, and we found it was never
more frequent every 42ms, but must complete within 36ms.
• Tasks 1 and 3 both lock the shared parallel bus for 2ms
First, determine the temporal scope of the tasks in
terms of period, CPU time and deadline
• Task 1 is periodic every 19ms and requires 6ms of CPU time.
• Task 2 is periodic every 24ms, and requires 8ms of CPU time.
• Both must finish their current processing before being triggered
again.
Since tasks 1 & 2 must finish before their next occurrence, their
deadlines are equivalent to their periods:

• And task 3 ?
• Task 3 needs 5ms of CPU time to execute, and we found it was never
more frequent every 42ms, but must complete within 36ms.
• Task 3 is aperiodic - for safety when scheduling we assume its
operating at its maximum rate:

Next, we assign priorities.

How do we calculate the temporal scope?
From analysis of the system spec and from measurement of prototype
code using timer/counters, logic analysers, etc..
If we are lucky we have access to a simulation environment (even
better if this is cycle-accurate then we can time off it!).
‘Amount of CPU time required to complete the task'. Don't forget to
assume/test the worst case:
• communication/signalling time
• combination of input factors
• assume all loops run to their maximum
• AVOID recursive code or potential infinite loops!!
Do we have sufficient CPU resources?
• A first guess would be to look at all tasks and their temporal scope
plus period:

• Only 40% of the CPU is used. Will the system work?

• Clearly, only 40% of the CPU is used, but the system does not work.
CPU Utilisation is therefore NOT a good metric!
• It seems that a straightforward assignment of most important task
having highest priority is not always optimal.....
• Actually, if we swap the priorities, all deadlines can be met:
There are many ways to assign priorities. A
few examples:
• Most important first
• In order of frequency (rate monotonic scheduling)
• In order of completion deadline (deadline monotonic scheduling)
• Ad-hoc
• quickest first, by analysis of shared resource accesses etc, random!