[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
and then in the driver you call (ThisIFn is the number of the interface):
memcpy(ThisMAC, bsp_getenv(ETHMAC1+ThisIFn), sizeof(ThisMAC));
and in the bsp_getenv:
char* bsp_getenv(uint Request)
case WHATEVER YOU HAVE PARAMETERS:
Take MAC1 address fromever you like,
return its address
while bsp_getenv(...) is BSP specific implementation.
Is it not enough OK?
On Monday November 9 2009, Thomas D?rfler wrote:
> 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
> 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.
> 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