Comtrol eCos - Manual (Page 313)

Chapter 11. Porting Guide
The appropriate use of the mechanism is specified loosely by a policy. The general policy dictates that the vectors
are initialized in whole by ROM monitors (built for ROM or RAM), or by stand-alone applications.
For configurations relying on a ROM monitor environment, the policy is to allow initialization on a service by
service basis. The default is to initialize all services, except COMMS services since these are presumed to already
be carrying a communication session to the debugger / console which was used for launching the application. This
means that the bulk of the code gets tested in normal builds, and not just once in a blue moon when building new
stubs or a ROM configuration.
The configuration options are written to comply with this policy by default, but can be overridden by the user if
desired. Defaults are:
• For application development: the ROM monitor provides debugging and diagnostic IO services, the RAM appli-
cation relies on these by default.
• For production systems: the application contains all the necessary services.
Pros and Cons of Virtual Vectors
There are pros and cons associated with the use of virtual vectors. We do believe that the pros generally outweigh
the cons by a great margin, but there may be situations where the opposite is true.
The use of the services are implemented by way of macros, meaning that it is possible to circumvent the virtual
vectors if desired. There is (as yet) no implementation for doing this, but it is possible.
Here is a list of pros and cons:
Pro: Allows debugging without including stubs
This is the primary reason for using virtual vectors. It allows the ROM monitor to provide most of the debug-
ging infrastructure, requiring only the application to provide hooks for asynchronous debugger interrupts and
for accessing kernel thread information.
Pro: Allows debugging to be initiated from arbitrary channel
While this is only true where the application does not actively override the debugging channel setup, it is a
very nice feature during development. In particular it makes it possible to launch (and/or debug) applications
via Ethernet even though the application configuration does not contain networking support.
Pro: Image smaller due to services being provided by ROM monitor
All service functions except HAL IO are included in the default configuration. But if these are all disabled the
image for download will be a little smaller. Probably doesn’t matter much for regular development, but it is a
worthwhile saving for the 20000 daily tests run in the Red Hat eCos test farm.
Con: The vectors add a layer of indirection, increasing application size and reducing performance.
The size increase is a fraction of what is required to implement the services. So for RAM configurations there
is a net saving, while for ROM configurations there is a small overhead.
The performance loss means little for most of the services (of which the most commonly used is diagnostic
IO which happens via polled routines anyway).
209