Comtrol eCos - Manual (Page 747)

Overview
Name
The eCos synthetic target — Overview
Description
Usually eCos runs on either a custom piece of hardware, specially designed to meet the needs of a specific applica-
tion, or on a development board of some sort that is available before the final hardware. Such boards have a number
of things in common:
1. Obviously there has to be at least one processor to do the work. Often this will be a 32-bit processor, but it
can be smaller or larger. Processor speed will vary widely, depending on the expected needs of the application.
However the exact processor being used tends not to matter very much for most of the development process:
the use of languages such as C or C++ means that the compiler will handle those details.
2. There needs to be memory for code and for data. A typical system will have two different types of memory.
There will be some non-volatile memory such as flash, EPROM or masked ROM. There will also be some
volatile memory such as DRAM or SRAM. Often the code for the final application will reside in the non-
volatile memory and all of the RAM will be available for data. However updating non-volatile memory requires
a non-trivial amount of effort, so for much of the development process it is more convenient to burn suitable
firmware, for example RedBoot, into the non-volatile memory and then use that to load the application being
debugged into RAM, alongside the application data and a small area reserved for use by the firmware.
3. The platform must provide certain mimimal I/O facilities. Most eCos configurations require a clock signal
of some sort. There must also be some way of outputting diagnostics to the user, often but not always via
a serial port. Unless special debug hardware is being used, source level debugging will require bidirectional
communication between a host machine and the target hardware, usually via a serial port or an ethernet device.
4. All the above is not actually very useful yet because there is no way for the embedded device to interact with
the rest of the world, except by generating diagnostics. Therefore an embedded device will have additional
I/O hardware. This may be fairly standard hardware such as an ethernet or USB interface, or special hardware
designed specifically for the intended application, or quite often some combination. Standard hardware such as
ethernet or USB may be supported by eCos device drivers and protocol stacks, whereas the special hardware
will be driven directly by application code.
Much of the above can be emulated on a typical PC running Linux. Instead of running the embedded application
being developed on a target board of some sort, it can be run as a Linux process. The processor will be the PC’s
own processor, for example an x86, and the memory will be the process’ address space. Some I/O facilities can
be emulated directly through system calls. For example clock hardware can be emulated by setting up a
SIGALRM
signal, which will cause the process to be interrupted at regular intervals. This emulation of real hardware will not
be particularly accurate, the number of cpu cycles available to the eCos application between clock ticks will vary
widely depending on what else is running on the PC, but for much development work it will be good enough.
Other I/O facilities are provided through an I/O auxiliary process, ecosynth, that gets spawned by the eCos appli-
cation during startup. When an eCos device driver wants to perform some I/O operation, for example send out an
ethernet packet, it sends a request to the I/O auxiliary. That is an ordinary Linux application so it has ready access
to all normal Linux I/O facilities. To emulate a device interrupt the I/O auxiliary can raise a
SIGIO signal within
the eCos application. The HAL’s interrupt subsystem installs a signal handler for this, which will then invoke the
643