[En-Nut-Discussion] Include <dev/board.h> in TWI devices like dev/at24c.c?
bon at elektron.ikp.physik.tu-darmstadt.de
Wed Jan 30 11:34:35 CET 2013
>>>>> "Harald" == Harald Kipp <harald.kipp at egnite.de> writes:
Harald> Hi Uwe, On 29.01.2013 16:22, Uwe Bonnes wrote:
>> some board define DEF_TWIBUS in include/dev/board.h or a file
>> included from board.h.
>> However nut/dev/at24c.c nut/dev/eeprom.c nut/dev/mma745x.c
>> don't include dev/board.h. Should the c-files above include board.h
>> or are the boards wrong to define DEF_TWIBUS in board.h
Harald> states, that dev/board.h is for inclusion in application code
Harald> only. I vaguely remember, that using dev/board.h in Nut/OS
Harald> system code could result in strange dependencies regarding the
Harald> sequence of header file references.
Harald> Anyway, why would a Nut/OS driver code need DEF_TWIBUS? Only, if
Harald> it is based on the old API with the hard coded interface, right?
Harald> IMHO, this is not a board-dependent feature.
The devices include twif.h and use commands like
TwMasterTransact( I2C_SLA_SHT21, &cmd, 1, NULL, 0, 10);
TwMasterTransact resolves in twif.h to
#define TwMasterTransact( sla, txd, txl, rxd, rxs, tmo)\
NutTwiMasterTranceive(&DEF_TWIBUS, sla, txd, txl, rxd, rxs, tmo)
so DEF_TWIBUS is hard coded.
It seems that now of the TWI device drivers in nut/dev use the new API so
Lets look at the sht21 driver. Probably
should be changes in
int ShtInit(NUTTWIBUS *bus)
and then the new api should be used. Would that be a right fix? If yes, I
would try to go for a fix.
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