ChibiOS Free Embedded RTOS

We are using this multi-master I2C driver now on a daily basis in a multi-master I2C network consisting of TI MSP430 (bare metal) and chibios nodes.
It's been rock solid for us.
The kludge of using one of the STM32 counter/timers to detect repeated starts on the I2C bus works beautifully.

I'd be happy to take detailed questions regarding a port to chibios 3.0, but I don't have time now to work on it myself.
So, yes, by all means, go for it! I'll support you as best I can.

genosensor wrote:We are using this multi-master I2C driver now on a daily basis in a multi-master I2C network consisting of TI MSP430 (bare metal) and chibios nodes.
It's been rock solid for us.
The kludge of using one of the STM32 counter/timers to detect repeated starts on the I2C bus works beautifully.

I'd be happy to take detailed questions regarding a port to chibios 3.0, but I don't have time now to work on it myself.
So, yes, by all means, go for it! I'll support you as best I can.

Thankyou for the encouragement!

Are you able to point me to the latest source? The repository link you give in this thread seems to be a straight copy of ChibiOS - no i2c slave code in the obvious place. I've got a zip file I got from somewhere where all the files are dated 9th June 2014, including ChibiOS 2.6.1, which is clearly your code and has the relevant files.

Also interested to hear that you're using multi-master - not a popular use case!

The I2C slave/multimaster support is in the i2cslave branch of the git repo.


The most recent few commits were to add support for more timers and a custom board.
The tag i2cslave_clean marks the last generic commit for the I2C driver.
So, you might want to base your port on:


I'd suggest you build and run the i2cslave and i2cmaster i2ctest projects before starting port the driver to chibios 3.0

Found it, thanks - looks like I just missed it this time.

Ignore - answered my own question after digging deeper!

Got the basics going; master mode 'just worked', so haven't looked in detail yet.
Slave mode took a little more effort, but now seems stable under reasonable conditions. Will need some more checking of error handling.
I've got to concentrate on actually using the driver for a bit, so posting the updated driver and a slave test project here in case anyone wants to test.
(Very little changed from genosensor's original work, other than converting to V3)

Hi,

We need to validate the API more than the actual implementation. The question is, is the API reasonably complete for any I2C slave application? I don't have much experience in that specific use case.

Giovanni

Initial impression is that the API is good.

Should be able to comment better in a week or so, once I've written some 'real' software to use it.

It's great to see development of an I2C slave driver.

But I do have concerns with the generality of the API and its flexibility. In particular, it looks like the current implementation requires that any message received by the slave from the master, or send as a reply to the master, must fit entirely in a RAM buffer.

In many cases the slave may be working with messages much larger than the system RAM. For instance, you might have an I2C slave which acts as a controller for a graphics LCD and can receive an entire screen full of pixels in a single I2C write operation. Suppose this slave device interfaced via a parallel I/O bus to a graphics LCD that has its own internal framebuffer memory. The slave MCU may not have enough RAM to buffer the entire I2C message, nor would want to (added latency for no benefit), if it could instead stream those bytes to the LCD as they are received, either as single bytes or as chunks of some maximum size.

Other instances where you don't know the size of the data include acting as an EEPROM-type device, or a network interface (imagine a slave that implemented a TCP networking protocol, where the master could stream data to it over I2C).

Is there a way to allow for reads and writes of indefinite size? The slave should also be able to NAK any received byte as well, e.g. if an invalid command code is received.

A different model would be to have a "receive" function that gives a callback after the buffer has been filled, then the application can continue the receive, send a stop or take some other action.

Much more similar to the UART driver but:
1) Unlike the I2C master approach which has no callbacks.
2) Harder to implement.

Giovanni