RTEMS with post-boot code.

[Robin Kirkham]

> On Wed, 29 Oct 1997, Robin Kirkham wrote:
> 
> > On the whole, having used vxWorks for many years, I find the RTEMS way of
> > bundling the application with whatever parts of an OS it requires into a
> > single executable unit is in many ways cleaner and easier. Maybe it's not
> > so good for repeated compile/test/debug cycles, but it is much better for
> > managing systems in the field. (It is also the traditional embedded systems
> > approach).
> 
> It is easier but forces you to relink the entire application and download
> it.

It gives me time to think (seriously!). But I am also improving my downloading
tools...

> GNU ld has some options to do something like "use address -- not
> object code from this file".  I think using that, you could reuse the code
> for RTEMS (and maybe other things like C library routines) which are
> linked into  the monitor.

I think this may be possible but I don't think it is a lot of help. If I
understand you correctly, it amounts to doing the relocation fixups on a
to-be-later-loaded module, using the symbol values of an already-linked
executable RTEMS with monitor. This is OK until the base executable gets
changed, then all the loadable modules need to be fixed-up again to suit it.

You would also have to contrive things so that just about every RTEMS and
C library function was linked into the base executable, just in case a
loadable wants it.

> The key problem you will have to face is that RTEMS, the BSP, all device
> drivers, etc will be in the ROM monitor and already initialized when your
> application code is downloaded.  So it will have to be configured to
> include your application requirements.  Plus you have to know what to
> invoke in the downloaded image to do its application initialization.

This is an issue in RTEMS, which by design I think favours off-line
configuration and static linking. In vxWorks all kernel and user objects are
on the heap, and there are no initial or buil-in limits to the number of any
of them. This makes the dynamic linking easier. You can invoke any function
(by name to its command shell) to start the application.

Robin Kirkham			CSIRO Manufacturing Science and Technology
Project Engineer		Locked Bag 9, Preston 3072, Australia
robin.kirkham at mlb.dmt.csiro.au	Phone: +61 3 9662-7756  Fax: +61 3 9662-7851