[En-Nut-Discussion] DEV_XXX_NAME versus DEV_XXX.devname

[Harald Kipp]

Hi Uwe,

On 24.09.2012 14:11, Uwe Bonnes wrote:
> Hello,
> 
> in a lot of files additional to the definition or usage of DEV_XXX, there is
> also definition and usage of DEV_XXX_NAME. I think these definitions are
> redundant as DEV_XXX_NAME can also be written as DEV_XXX.dev_name. These
> redundants definitions clutter the code and there is a chance that they get
> out of sync. Is there any reason of the usage of this redundant definition?

Or, moving this further, why do we need dev_name at all? :-)

First of all, its by intention to decouple interface names from device
drivers. The names are used to select hardware interfaces, while the
NUTDEVICE structures are used to select the drivers. There may be more
than one driver for a single hardware interface, but in this case they
all have the same device name entry, so only one of them can be registered.

DEV_XXX_NAME is mainly intended as convenient definitions for our lousy
application samples, because, for example, it is not practical on all
target boards to have DEV_CONSOLE at "uart0".

Real world applications will typically register a specific driver for a
specific interface by hard-coding NutRegisterDevice(). However, the
interface may be selected by the user configuration. As an example: The
application registers dev_uart0, dev_uart1 etc. The user configuration
uses "uart0", "uart1" etc. to select the right interface for the
attached sensor. So, applications may/should not use DEV_XXX_NAME at all.

Of course, in our samples we could use DEV_XXX.dev_name. I just didn't
do that, because I clearly wanted to demonstrate, that NUTDEVICE and the
interface name are two different things. May be, it would be better to
have a function InitHardware, which calls all those OS-specific stuff
and completely ban NUTDEVICE from standard application code to make it
even clearer. In the future we may optionally have related
configurations in the Configurator and NutIdle will do all the device
registration. In that case the application will not even know such
OS-specific stuff like NUTDEVICE.

Finally there is one more point. Sometimes additional information is
added to the name string, like with PPP, the new SSL and, most
typically, file system drivers. I recently discovered, that for some targets

#define PPP_DEV_NAME    DEV_PPP.dev_name
#define DEV_FS_NAME     DEV_FS.dev_name

had been defined instead of

#ifdef BOARD_FOO
#define PPP_DEV_NAME    "uart1"
#define DEV_FS_NAME     "UROM"
#elif BOARD_BAR
#define PPP_DEV_NAME    "uart0"
#define DEV_FS_NAME     "MMC"
#endif

But in a few samples we use something like

_open(PPP_DEV_NAME ":" PPP_USER "/" PPP_PASS,...);
_open(DEV_FS_NAME ":logfile.txt",...);

to keep the code as simple as possible. The first definitions above
would require some more code.

Regarding your concern about running out of sync: In most cases this is
quite simple and I tried to straighten this a bit by creating
board-specific includes to be included into board.h. If that is done for
all boards, board.h will only define the most common items, if they
hadn't been specified in the board specific header.

I also discovered, that a few newer drivers now use "usart0" instead of
the historical "uart0" (note the extra s) for no obvious reason. This
further complicates board.h.

Regards,

Harald