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

[Uwe Bonnes]

Hello,

all our I2C device drivers use TwMasterTransact() and friends to access the
chip. In twif.h, TwMasterTransact() resolves to
#define TwMasterTransact( sla, txd, txl, rxd, rxs, tmo)\
        NutTwiMasterTranceive(&DEF_TWIBUS, sla, txd, txl, rxd, rxs, tmo)

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.

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

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.

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.

Any ideas?
-- 
Uwe Bonnes                bon at elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------