[En-Nut-Discussion] RFC: New driver interface for TWI, I2C and others

[Ulrich Prinz]

Hi all!

I'd like to have your comments for the following thing:

Why not initializing any driver for a multiply appearing hardware with a
driver descriptor struct?

We already have that for USART, I added it for SPI in ARM and will have
that available for Cortex for all serial interfaces.

I already added it for AT24C EEPROMs (if you encountered the difference
to the old eeprom driver).

So with any interface you register you provide a descriptive bus struct.

The bus struct is of same basic structure as it already exists for the
USARTs but modified to the needs of the bus it is for.

In AVR and ARM USARTs are made of two files. usart1.c defines the init
routines and all defines that name everything for the functions. These
defines can be modified by nutconf.
Then it _includes_ the usart.c and compiles all the code dependent on
the defines. For USART2 there is a usart2.c that again _includes_
usart.c again.

If your chip provides 5 USARTs, it gets quite expensive in count of
FLASH used.

The solution I'd like to discuss is to make multiple c-includes-c obsolete.

Let the discussion start!

---------- Some private opinions ----------

If you now say, that there is a problem by having all options available
the single driver is bigger then two separate drivers, I agree. On the
other hand you can use nutconf to disable some features at all if they
are not needed.

So if you use IRDA you can enable it and the code includes the IRDA
routines and all USARTs can use IRDA if configured for it via ioctl.
But as the basic buffer functions and the interrupt routines are 98% the
same, you only add 2% of code instead of 102% by duplicating the
optimized driver.

If you say that this adds some if the else things to the code, yes and
it may be a problem for AVR but there is power enough for any
ARM/Cortex. And even for AVR I'd like to see where it would give a real
performance impact.

Ulrich