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

[Ulrich Prinz]

Hi!

Am 27.04.2011 12:20, schrieb 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.
> 
It fully ok! I just need to add a more or less completely new
architecture and so I stumbled over all those tiny holes and things that
rest there from the past and try to byte you in the ankle.

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

It isn't wired code! The code isn't bad at all and I never said that.
But it is hard to port to other devices and, as time changes, but not
the AVR, it may become ineffective for other architectures while it is
still the best way for AVR.
> 
> 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.
> 
Provisorien halten immer am längsten :) SCNR

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

This isn't the wrong way. I rewrote the some driver three times on the
AT91, like you might remember. I made the mistake to start by just
copying some existing code :)
> 
> 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.
> 
Hehe, the code exists and I (re-)start the discussion again as a merge
preparation. If there are people enough that can tell me why to do this
an not that, I will listen, learn and accept and modify my code
accordingly. But if not, the new code will come and no one can say he
hasn't been warned :)

On the other hand, the TWI driver in the branch shows how it could work.
Keep AVR mostly untouched, and upgrade all ARM/Cortex to one level.
1) Rename new functions according a naming style (nutTw NutSpi NutUsart).
2) Write new drivers to bus convention (NUTTWIBUS, NUTSPIBUS...)
3) Create a default setup that links old functions to new functions for
the bigger and newer architectures that can spare some RAM and power.

With the new At24c driver you can still cal eeinit()... it works!
With ARM or Cortex you can still call TwMasterTransact() it works. You
just nees nutconf to tell which is the eeprom address for the default
EEPROM and you need to select one of the I2C systems to be the default one.

Then we're free on the ARM/Cortex but the AVR still works and the sample
code is working too. I assume that the sample code might even get easier
to be adapted to new platforms as you just save the new config in
nutconf an dthere you are. No line to be modified and no #ifdef is
needed to be added.

Ulrich