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

[Harald Kipp]

Hi Ulrich,

On 4/27/2011 12:09 AM, Ulrich Prinz wrote:

> 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.

As I am the creator of at least half of the drivers, I should be the 
responsible guy in the first place. Frankly, my main focus is more on 
those topics, which are completely missing today, like IPv6 and wireless 
communications. Anyway, as my time allows, I'll be most happy to help 
with testing, nagging, fixing etc.

The intention of this email is, to provide some more background 
information. Although, I write this from memory, it should fairly well 
describe the history.

The UART driver had been always most time critical when used for 
networks, e.g. PPP or BTnut.

I created the intial UART support for AVR. Although including C source 
into another C source is an absolute no-go for me, I couldn't find 
another solution. The important requirement is, that the compiler can 
identify the register address as a constant. Otherwise it won't be 
possible to make use of AVR bit-set and bit-test instructions.

That's the reason for this weird code.

The first ARM port I created was for the GameBoy, there was no need for 
an UART driver, because standard output goes to the screen. :-)

Later a quick port (within few weeks only) was provided for the SAM7X. 
Its contributor used the most simple way: Copy and paste. Nevertheless, 
the port ran astonishing well and got established in the way we have it 
until today.

Using the AVR driver as a template was the first mistake. It was a 
maintenance nightmare with all this duplicate code.

To fix this, I created a new version of the driver, trying to move as 
much code as possible to a common source. The result is dev/usart.c, 
which provided a more general framework.

Actually this was the second mistake, because it further supports the 
badly done AT91 driver. It would have been better to leave the AVR 
driver and create a new, optimized driver for ARM targets.

> Let the discussion start!

IMHO, almost any Nut/OS driver has its design flaws. Even the SPI bus 
driver, on which I spent a great deal of time for the design and of 
which I'm a little bit proud.

There had been several discussion threads in this list about new driver 
structures. Specifically Ole never got tired to promote new solutions. 
Or has he become fed up now? ;-) I really wish and hope, that all these 
discussion and proposals will finally in more real code.


Regards,

Harald