The remaining chapters of this document compromise a simple tutorial for configuring and building eCos, building and running eCos tests, and finally building three stand-alone example programs which use the eCos API to perform some simple tasks.
You will need a properly installed eCos system, with the accompanying versions of the GNUPro tools. On Windows you will be using the bash command line interpreter that comes with Cygwin, with the environment variables set as described in the GNUPro documentation.
Most development projects using eCos would contain some (or most) of the following:
eCos is configured to provide the desired API (the inclusion of libc, uitron, and the disabling certain undesired funtions, etc.), and semantics (selecting scheduler, mutex behavior, etc.). See Configuring and Building eCos from Source .
It would normally make sense to enable eCos assertion checking at this time as well, to catch as many programming errors during the development phase as possible.
Note that it should not be necessary to spend much time on eCos configuration initially. It may be important to perform fine tuning to reduce the memory footprint and to improve performance when the product reaches a testable state.
While Red Hat strive to thoroughly test eCos, the vast number of configuration permutations mean that the particular configuration parameters used for your project may not have been tested.
Therefore, we advise running all the eCos tests after the project's eCos configuration has been determined. See Test Suites .
Obviously, this should be repeated if the configuration changes later on in the development process.
While your project is probably targeting a specific architecture and platform, possibly custom hardware, part of the application development may be possible to do using simulated or synthetic targets.
There are two primary reasons for doing this:
This is possible to do since all targets (including simulators and synthetic ones) provide the same basic API: that is, kernel, libc, libm, uitron, infra, and to some extent, HAL and IO.
Synthetic targets are especially suitable as they allow you to jury-rig simulations of elaborate devices by interaction with the host system, where an IO device API can hide the details from the application. When switching to hardware later in the development cycle, the IO driver is properly implemented. While this is possible to do, and has been done, it is not specifically documented or supported by Red Hat. It may become so later.
Therefore, select a simulator or synthetic target and use it for as long as possible doing application development. That is, configure for the selected target, build eCos, build the application and link with eCos, run and debug. Repeat the latter two steps.
Obviously, at some time you will have to switch to the intended target hardware, for example when adding target specific feature support, for memory footprint/performance characterization, and for final tuning of eCos and the application.
Repeat the build-run-debug-cycle while performing final tuning and debugging of application. Remember to disable eCos assertion checking, as it reduces performance.
It may be a useful to switch between this and the previous step repeatedly through the development process; use the simulator/synthetic target for actual development, and use the target hardware to continually check memory footprint and performance. There should be little cost in switching between the two targets when using two separate build trees.
Programming with eCos