ChibiOS Free Embedded RTOS

Thanks barthess!

Don't forget this line in i2c.h (and the one for the error callback):

typedef void (*i2ccallback_t)(I2CDriver *i2cp, const I2CSlaveConfig *i2cscfg);

Thanks for note. Fixed in rev. 3308

If we are talking about the chaining of devices, may be better to move slave address, and pointers to in/out buffers to slave config struct? Than in transport functions pass pointer to the slave config.

I don't like much having non-const configuration structures, in the HAL all configuration structures are consistently declared const. I think putting the addr into the configuration is a good idea, in most cases you never change it.

If you need to make it non-const then I would suggest to rename it to something like "I2CTransaction", its role is to describe a transaction with a peripheral so it would be appropriate. I would still try to make it non-writable even if not declared const so applications could still allocate those in flash.

Giovanni

Giovanni,
Hm... my offer:
For example, we have 13 tmp75 sensors on 1 bus.
We define 13 const SlaveConfigs in user mode (1 for each sensor) with callbacks' pointers, buffers' pointers and address.
Pass pointer to SlaveConfig in each transaction instead of passing buffers' pointers and address.

As results:
- both driver config and slave config(s) are constant
- we have convenient way to chaining lots of devices

I like it, I just am not sure about the buffer pointers, the application writer may want to change the pointer without having to define multiple configurations. For example imagine I am reading parts of an I2C EEPROM into a buffer, the configuration is the same but the rxptr would change after each read.

Giovanni

Badger (and other I2C users), what you think?

I think there are merits to both sides of the argument. Perhaps we should have a structure for each slave which contains const config options - (callback, address? although in some situations the i2c address is changeable by writing to the device, so it may be desirable to modify this) and also some user definable non-const data.

From my point of view, it is good to be able to store some sort of non-const data related to each slave device, not each driver (because of course there can be multiple devices for one driver), and to be able to access that easily from within the callback functions.

About storing non const data into a const structure. It is always possible to make the const structure extendable and add a pointer to a custom non-const structure.

Giovanni

Badger,
There is hook in the SlaveConfig to add some non constant fields related to slave device. It is easy to add similar hook to the driver config structure. On the other hand you can store data in global variable and analyze slave address field to select appropriate variable. What information you want to store?