[En-Nut-Discussion] Any twibus/i2cbus migration strategy?
bon at elektron.ikp.physik.tu-darmstadt.de
Tue Feb 19 13:46:39 CET 2013
>>>>> "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
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
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
>> 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
Uwe Bonnes bon at elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
More information about the En-Nut-Discussion