RTEMS, Bootloaders and HW parameters

[Thomas Dörfler]

Peter,

in a way you are right. I don't want to invent things again, if existing
code already does what it should do. On the other hand, I would like to
make this API as usable as possible. This includes:

- putting data into the right format. E.g. it may be nice to get
ethernet IP and MAC adresses already in the proper network data format,
not a string. the same is true for baud rates etc.

- being as versatile as possible

- include handling for bootloader/configuration/default values

I don't know micromonitor, but what I have seen as the interface package
seems quite nice. So I can actually add the following code to my network
driver:

...
   macstr = umon_getenv("ETHMAC1");
...

But there are still various things that may have to be adapted in the
network driver, if I use it on a different board (with a same/similar
microcontroller), e.g.

- the environment variable name may differ (because this board only has
one ethernet IF it is called "ETHMAC")

- the environment variable is not set at all because this board gets its
MAC address from a different location (e.g. bunrt into a dedicated chip)

- the ethernet address must be taken from an specific storage (e.g.
application specific EEPROM) instead of from the bootloader

... and many other things that may be different. Up to now, this is
treated in the networking(/console/clock...) driver and it must be
adopted to different board to get its information. What I want to add is
a BSP/board specific code module, that is responsible for collecting
that data, wherever it can be taken from. And then ALL drivers can
simply query that information in a uniform fashion.

So I think this a bit beyond a simple "getenv" call. For most cases it
may be mapped to it, but not always.

wkr,
Thomas.


Peter Dufault wrote:
> 
> On Nov 9, 2009, at 4:02 , Thomas Dörfler wrote:
> 
>> I am always a bit suspect if one particular implementation is used as a
>> general API.
> 
> I'm only sometimes a bit suspect when one particular implementation is
> used as a general API.
> 
> I hate it when an API is modified only by doing something like
> prepending "rtems_" to the front of it (or by replacing "umon_" with
> "rtems_").  If, for example, the uMON API is perfectly adequate for what
> is needed now and in the foreseeable future and if it is used on the
> majority of the boards using such a facility then go ahead and
> standardize on it.
> 
> I'm not saying this is the case, you have to use your good judgement,
> but I've seen too many examples of mulltiplying APIs for no good reason
> not to point this out.
> 
> Peter


-- 

--------------------------------------------
Embedded Brains GmbH
Thomas Doerfler        Obere Lagerstrasse 30
D-82178 Puchheim       Germany
email: Thomas.Doerfler at embedded-brains.de
Phone: +49-89-18908079-2
Fax:   +49-89-18908079-9