[En-Nut-Discussion] Include <dev/board.h> in TWI devices like dev/at24c.c?

[Uwe Bonnes]

>>>>> "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
    >> nut/dev/sht21.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> http://www.ethernut.de/api-beta/board_8h.html

    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
long. 

Lets look at the sht21 driver. Probably

int ShtInit(void)

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.

Bye

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

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