[En-Nut-Discussion] Any twibus/i2cbus migration strategy?

[Harald Kipp]

Hi Uwe,

On 18.02.2013 12:44, Uwe Bonnes wrote:

> This means, that at library compile time the information about the default
> twibus is needed. With our policy not to include board.h during library
> compile time, this defers defining DEF_TWIBUS in board.h, or otherwise
> library compile will fail with i2c drivers enabled.

I always felt, that something was wrong here. DEF_TWIBUS intend to do
two different things:

1. Keeping the original code intact (unchanged)
2. Specifying a default bus for each board

This combination cannot work. We have to solve this separately.

Furthermore, there is rarely something like a "default" TWI bus. If
multiple buses are used, they will have different devices connected to
them. So we do not need DEF_TWIBUS in this case, but RTC_TWIBUS,
EEPROM_TWIBUS etc.

> The use of TwMasterTransact() in the device drivers also defers the
> simultanious use of I2C devices on different I2C Busses of the device.

That's what the DEF_TWIBUS solution tried to solve. But it also
introduced new problems, as we can see now.


> Furthermore, the twibus driver also doesn't mix with other
> twibus implementations (Bitbanging or  perhaps in an FPGA) used in the same
> design.
> 
> For that, Harald added a i2cbus implementation for AT91SAM7, and me for GPIO
> Bitbanging (*) and I have a i2cbus driver for STM32F3 pending also.

DEF_TWIBUS was announced as a similar solution to NUTSPIBUS. But after
looking to the details I recognized, that this is not the case. So I
published my solution as early as possible to avoid more code based on
the DEF_TWIBUS solution. Due to lack of time, I failed to offer more
than the AT91 implementation. So it's nice to have your bitbanging
version. (Although it breaks the AT91 build, at least. Hint! Hint!)


> I think, the driver situation is not satisfying. However I don't see a sensible
> migration path. Changing all device drivers to use the i2cbus API
> that only needs to know the i2cbus ar runtime would be clearest. However I
> suspect there is tons of legacy code around that would break.

Actually we have to manage the following:

1. Keeping existing code intact, without requiring changes
2. Supporting boards with multiple I2C buses of different kinds

There is a lot of code based on the first TwMasterTransact version.
Unfortunately we have to expect, that users also already created code
based on DEF_TWIBUS. Probably not many, but if, they will appreciate
compatibility with later version. So, DEF_TWIBUS as well as

#define TwMasterTransact NutTwiMasterTranceive

should be kept for existing applications. (Btw. I really _hate_ this
typo, it should have been NutTwiMasterTransceive!) In that way
DEF_TWIBUS is correctly defined in dev/board.h.

On the other hand, Nut/OS drivers should use a configurable bus for each
device. My first suggestion would be to include

#include <cfg/twibus_XXX.h>

in each driver's C file (not the header), where XXX is replaced by the
device, e.g.

#include <cfg/twibus_rtc.h>

may contain

#define DEF_TWIBUS Stm32TwiBus_1

for the RTC driver of a device connected to the second I2C interface of
the STM32. I'm aware, that this would require several platform dependent
lists in the Configurator scripts. But right now I do not have a better
solution.

In long term, the drivers will use the latest NutI2cBusXXX() as soon as
this interface becomes available for all targets. Then we can remove
this Configurator hack and the related header files again and only keep
DEF_TWIBUS in board.h for legacy applications.

Regards,

Harald