-
Consider the following list of potential real-time control applications.
Classify each one as either hard real time or soft real time.
Carefully justify your answer in each case:
(a) a controller for a microwave oven;
Soft real time. The computational demands of the controller functions
will be minimal, and it will be easy for the controller to keep up
with the human user's inputs and output expectations.
(b) a controller for a car ignition timing system;
Hard real time. The engine shaft can rotate at up to 6000 revolutions
per minute (100 revolutions per second, or one revolution per milli-
second). Very fast response is required from the controller if it
is to keep up with typical engine speeds.
(c) a controller for an automated teller machine (ATM);
Soft real time. As in the case of the microwave oven, the computational
demands should be minimal with respect to interactions with the user.
The computer network to which the ATM is connected may impose strict
timing requirements. However, a network interface device will likely be
taking care of network timing, and so the controller will not be
burdened with fast response timing from the network.
(d) a controller for an assembly line robot;
Likely to be hard real time. Assembly line robots control heavy
machinery and parts that need to be positioned with great accuracy
with tightly controlled timing. This is a demanding application
which will likely require hard real time techniques. Certain less
demanding assembly line robot functions may only require soft
real time solutions (e.g. a lightly-loaded PC).
(e) a controller for a consumer video game console.
This is likely to be hard real time. Many PC games are soft real
time (with hard real time support from a graphics accelerator
subsystem) because the PC operating system (e.g. Windows (R))
is not designed for real-time use, but can be used for soft
real time problems. Video game consoles are designed to improve
upon the performance of PC games by providing specialized hard
real time hardware and software.
-
Briefly explain when it is acceptable to protect critical sections
by disabling interrupts.
What are the potential disadvantages of protecting critical sections
in this way?
Could the same protection be provided for critical sections if, instead of
disabling interrupts, one just disabled multitasking for a time?
Explain your answer.
Disabling interrupts is a fairly drastic way of protecting critical
sections since it directly affects the real-time performance of the
entire system. If the critical sections are relatively small, then
disabling interrupts for the entire critical section may be
acceptable. For longer critical sections, it would be better to
use a binary semaphore or a counting semaphore to protect the critical
section. In this way, interrupts would only need to be locked out
when the semaphore is first examined and (possibly) updated at the
entry point to the critical section.
Disabling multitasking might be an acceptable alternative to locking
out interrupts. This is true when none of the interrupt service routines
can corrupt a critical section, and when only other tasks can
cause corruption.
-
Briefly evaluate MicroC/OS-II with respect to portability, scalability,
and determinism in real-time applications.
Portability is excellent:
1) The kernel is written in standard ANSI C, which is widely supported
across different CPU architectures.
2) The CPU-specific aspects of the kernel are minimized and contained
within a small number of software modules.
Scalability is excellent:
1) The kernel's design is modular, so parts of the kernel can be
more easily left out or kept in, depending on the requirements of
the particular application.
2) It is easy to leave out unused portions of the kernel by simply
clearing switch variables in a configuration header file.
Determinism is excellent:
1) The strictly preemptive scheduling based on priorities, with no
more than one task per priority, ensures that high priority
activities will be handled first in a timely manner, regardless of
the workload at lower priorities.
2) The kernel's data structures can be accessed and updated in the
same amount of time, regardless of how many tasks may currently
be running in system. (This point could have been emphasized
more in the lectures).
-
Consider an asynchronous serial interface (not RS232C).
To maximize the efficiency of the proposed communication port, it is
desirable to maximize the length of the data frames.
Each data frame is to consist of one start bit, 1.5 stop bits, and some
as yet undetermined number of data bits.
The transmitter and receiver clocks are each accurate to about 0.03%
of the nominal 32.056 KHz frequency.
In addition, the clock frequencies are assumed to be relatively stable
over time (although their frequencies are likely to be different from
each other and different from the nominal frequency).
Assume that the frames are received with sufficient reliability if the
sampling point for each bit is within the middle 66% of the bit width.
Determine how long (including framing bits) the bit frames can be and
still have reliable communications.
The first step is to consider the worst case, which is a fastest-possible
transmitter sending to a slowest-possible receiver (or vice versa).
Let N represent the maximum allowable number of data bits in a frame.
Assume that the receiver clock is perfectly synchronized with the
transmitter clock at the mid-point of the initial start bit. The
stop bits are irrelevant to this problem.
With respect to the receiver, the transmitted bits will be arriving
roughly 0.06% too fast. At the maximum value of N, the two clocks
differ by 33% of a bit time. So we have:
N*(1/(32056000*1.0003)) = (N - 0.33)*(1/(32056000*0.9997)
Which implies:
32046383.2 * N = (32065616.8 * N) - 10581653.544
Therefore, N = 550.165
Rounded down to a whole bit, N = 550 bits.
In practice, it would be wise to further reduce the maximum data frame
length to have a bit more safety margin in the communication link.
-
In the RS323C standard, signals are provided that permit hardware flow control.
For example, the clear to send (CTS) input to a DTE can be used to
temporarily stop the flow of data from the DTE to the DCE (or another DTE).
This would be helpful if ever the DCE (or the second DTE) were being
overwhelmed with too much data.
An alternative means of flow control is software flow control.
An X-OFF ASCII character can be transmitted in the reverse data direction if
the data flow in the forward direction needs to be halted temporarily.
The flow of data can be restarted later by sending the X-ON ASCII
character in the reverse direction.
Briefly explain what would be some of the major potential advantages and
disadvantages of hardware flow control versus software flow control.
Hardware flow control is likely to be faster-reacting than software flow
control. Hardware flow control can react at hardware speeds. For
example, in the DUART a clear to send (CTS) can be configured that
directly inhibits the transmitter circuit. No software intervention
is required. However, in XON/XOFF-based flow control, the CPU must
typically execute software to handle the situations. The software is
going to take much longer to execute than the actions performed by
hardware flow control.
-
Each of the two serial channels in the DUART has a double buffer in the
transmit direction and a quadruple buffer in the receive direction.
What would be a reasonable explanation for making the buffer depth greater
in the receive direction than in the transmit direction?
The CPU that hosts the DUART has much more control over the rate that
data is transmitted compared to the data rate in the receive direction.
In order to minimize the chance of losing data, say due to processing
delays affecting the CPU, it is best to have more buffering in the
receive direction.