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

[Uwe Bonnes]

>>>>> "Harald" == Harald Kipp <harald.kipp at egnite.de> writes:

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

Okay, I see, so for the app/i2ctest example we would need a SCAN_I2CBUS
define.

I think some working examples is worth as much as tons of explications.


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

    Harald> That's what the DEF_TWIBUS solution tried to solve. But it also
    Harald> 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.

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

I am a little sorry about my harsh mail from last week regarding
HW_GPIO. Actually HW_GPIO is not misused by any driver, but we need some
additional configuaration option to distinguish the state of the GPIO API on
the architecture. But this also brings up the GPIO discussions from last
year where such option was disagreed on

So to tackle the non-compile we have several track to follow
- May I introduce some configuration variable so architures can tag if
they have a GPIO API useable for the bitbanging drivers I introduce?
E.g. GGPIO (Generalized GPIO) or AGPIO (abstracted)
- Somebody give me a headstart how to set up Openocd with the turtelizer to
get debug and flash access to my sam7 board and I can test for the sam7 too.

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

    Harald> #include <cfg/twibus_XXX.h>

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

    Harald> #include <cfg/twibus_rtc.h>

    Harald> may contain

    Harald> #define DEF_TWIBUS Stm32TwiBus_1

Should this be seperate include file ? All I2C/TWI related files already
must include cfg/twi.h. Why not add in cfg/twi.h. Adding new includes needs
action on all platforms.

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

Looking at stm32, the  solution with defined I2C buses  in cfg/twi.h seems
reasonable and non-intrusive to other platforms.

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

Bye
-- 
Uwe Bonnes                bon at elektron.ikp.physik.tu-darmstadt.de

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