Page 223 - Mechatronics with Experiments

MICROCONTROLLERS 209
debugged on the target hardware. Debugging tools (hardware and software) are
a very important part of an embedded system development suite. Unlike desktop
applications, real-time embedded applications must be debugged and I/O signals
must be checked for worst case conditions.
8. The developer must know the details of the embedded system hardware (bus archi-
tecture, registers, memory map, interrupt system), since the application software
development is influenced by the hardware resources of the embedded computer.
9. Interrupts play a very important role in almost all embedded controller applications.
It is through the interrupts that the embedded controller interacts with the controlled
process and reacts to events in real-time.
10. As the complexity increases, embedded systems require a real-time operating system
(RTOS). RTOS provides already tested I/O and resource management software tools.
For instance, Ethernet communication may be provided by RTOS functions instead
of being written by ourselves. Furthermore, RTOS can provide task scheduling,
guaranteed interrupt latency, and resource availability.

Perhaps the most significant factors that differentiate embedded computers from
desktop computers are the real-time requirement, limited resources, and smaller physical
size. The real-time performance of an embedded system is defined by how fast it responds
to interrupts and how fast it can switch tasks.
Programming for a real-time application using a microcontroller/DSP, versus pro-
gramming for a non-real time application such as using a desktop PC, has the following
differences:
1. Memory resources in a desktop PC are very large and conserving memory is not
a concern for the programmer. Whereas memory resources in microcontrollers are
limited and memory space should be used carefully in order to not exceed that avail-
able. In real-time programming, depending on the microcontroller/DSP type and the
development environment we use, the development environment at the compilation
and link time may allow us to decide how to utilize the available memory for variables
and constants, in order to best fit the application program into the available memory.
2. Computational time requirements are also not much of a concern in non-real time
PC applications. Whereas, in real-time applications, everything must run in real-time
and our program must be able to react to events in-time and in real-time. Therefore,
long delays or long loops can be a problem in real-time applications. In real-time
programming, we make use of interrupt-driven event handling to make sure the
microcontroller responds to external “interrupt” events fast.
3. In real-time applications, safety is of great importance. If something unexpected
happens, we need to define an ordered way of ending current program execution and
be able to restart in a timely and defined order. In desktop applications, the so-called
“blue screen” condition (a system failure) may simply be solved by rebooting the
system and waiting for a few minutes. In real-time systems, waiting for a few minutes,
even for a few seconds, may not be acceptable.
4. In real-time programming involving real-world hardware I/Os, the application soft-
ware deals with reading and writing of bits, that is the status of a switch or turn
ON/OFF a light. Data and registers are accessed in such a way that we refer to spe-
cific bits for read and write operations. We can think of I/O operations as read/write
operations for a table of bits which corresponds to the I/O. In other words, all of
the I/O data is simply the values of a set of registers and their bits. For instance,
configuring and reading an ADC involves writing to a set of configuration registers