[En-Nut-Discussion] Missing possibility in the I2CBUS API

Harald Kipp harald.kipp at egnite.de
Fri May 3 13:42:33 CEST 2013


Hi Uwe,

On 19.02.2013 16:34, Uwe Bonnes wrote:
>>>>>> "Harald" == Harald Kipp <harald.kipp at egnite.de> writes:

>     Harald> NutI2cBusTransact(bus, list, list_len)
> 
>     Harald> If the hardware is able to do this in one transaction, it can be
>     Harald> done.  Otherwise the driver must use several start-stop
>     Harald> transactions to execute the list.
> 
> Yes, I think we need to be able to (also) supply a list of transactions.
> 
> What about adding
> NutI2cBusTransact(bus, list, list_len)
> 
> and keeping
> 
> NutI2cMasterTransceive(NUTI2C_SLAVE *slave, const void *wdat, int wlen,\
> void *rdat, int rsiz)
> which would set up the arguments to finally call NutI2cBusTransact()?

Looks promising to me.


>         rc = (*bus->bus_transceive) (slave, &msg);
>         /* Release the bus. */
>         NutEventPost(&bus->bus_mutex);
>         /* Return the number of bytes received. */
>         if (rc == 0)
>           rc = msg.msg_ridx;
>     }
>     return rc;
> 
> In your approach, the device driver in the case of failure must write
> the failurereason to msg.msg_ridx and so we loose the number of bytes
> successfully transferred.

Looks more correct to me than the current implementation. I think I also
already stumbled here, but hasn't got time to fix it.

As I tried to express in my response to Ulrich, the i2cbus interface is
quite new and probably not in wide use right now. That's our chance to
make it fit to various requirements before we enter the "backward
compatibility maintenance hell". I'm ready to test any of your changes.

Regards,

Harald



More information about the En-Nut-Discussion mailing list