Re: [ECOS] Are the HALs in the eCos repository meant for deployment?

[Bart Veer <bartv at ecoscentric dot com>]

>>>>> "Oyvind" == =?ISO-8859-1?Q?=D8yvind Harboe?= <ISO-8859-1> writes:

    Oyvind> Are the HALs in the eCos repository meant for deployment?
    Oyvind> I would expect the average PCB to be somewhat/quite
    Oyvind> similar to an exisiting development board. I would *not*
    Oyvind> expect that the average product(hardware/software) would
    Oyvind> use some HAL completely unmodified.

There is a range of scenarios.

Some evaluation boards may provide all the peripherals needed for the
target application, quite possibly with a few too spare. For smallish
volumes it will be a lot more cost-efficient to buy a number of the
eval boards than to design a custom board. Of course cost
effectiveness will depend in part on whether the eval board costs a
few tens of dollars or a few thousand.

If the eval board does not quite have all the I/O facilities needed,
it may be easy to add some via an expansion connector. If the board
exposes the I2C SDA and SCL lines then it may be quite easy to fit a
daughter board hooked up to those lines, ditto for an SPI bus. Or you
could have something like a PC-compatible board with various PCI
plug-in cards. Often it will be possible to handle the extra I/O
facilities entirely in application space with no need for any HAL
modifications, e.g. extra I2C device objects can be instantiated
within application code.

Sometimes the eval board will not be appropriate, e.g. its footprint
may be too large for the intended application. If so a new board may
be designed but based on the schematics of the eval board. This saves
a lot of h/w design effort and reduces the risk of running into
previously undiscovered h/w bugs. The existing platform HAL may work
unchanged on the new h/w, with any extra I/O facilities again handled
within application space, Or it may be necessary to make minor tweaks,
e.g. change the linker script support to reflect a larger amount of
RAM and change the ROM startup code with different SDRAM controller
register values. You may also want a different ecos.db entry, a new
target which specifies the same platform HAL but e.g. removes the
ethernet device driver because that device is no longer accessible.

Or it may be desirable to design a completely new board. This is
particularly likely for high-volume cost-sensitive applications. Again
it may still be possible to reuse an existing eval board platform HAL,
but it is now more likely that a new platform HAL will be appropriate.
It depends in large part on how well the platform HAL and higher level
HALs were written, i.e. how well they can cope with minor board
variations, and that in turn depends in part on the h/w design.

There is an awful lot of variety in the embedded space - hence the
need for a configurable operating system.

    Oyvind> Rather than tweaking an existing HAL (often a couple of
    Oyvind> changes are sufficient), I would recommend to copy the
    Oyvind> existing HAL to a seperate repository(including the
    Oyvind> section in the ecos.db) and then placing that HAL before
    Oyvind> the snapshot of the eCos CVS HEAD. Renaming the HAL,
    Oyvind> although I would encourage it, isn't stricly required and
    Oyvind> probably not a lot of effort to rename at some later
    Oyvind> stage.

If that is how you want to work, that is fine - subject to graphical
configtool limitations. If other people prefer to copy a platform HAL
within the existing hierarchy, that is fine too. If yet other people
prefer to munge an existing platform HAL, either by adding configury
or by simply breaking the HAL for the original board, that is fine too
- although obviously any changes that break things are unlikely to
make it back into the master repository. I have no particular desire
to shoehorn people into exactly one way of doing things, except when
absolutely necessary to maintain a coherent and maintainable
architecture for the configuration system.

(Note this does not justify any major reorganization of the master
eCos repository that could make life more complicated for novice users
etc.)

Bart

-- 
Bart Veer                       eCos Configuration Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss