[En-Nut-Discussion] RFC: New driver interface for TWI, I2C and others
harald.kipp at egnite.de
Wed Apr 27 12:20:51 CEST 2011
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
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.
More information about the En-Nut-Discussion