Is there support for I2C slave and or Multi-master modes? we would like to integrate with a 400kHz multi-master bus.
Currently, I2C is master-only. The hardware can in theory do I2C slave, but we haven’t got round to plumbing it through to a Squirrel API yet.
Peter
In multi-master mode any of the masters must know when the bus is free:
There are I2C environments where multiple masters are driving the bus.
In such case each device needs to be able to cooperate with the fact that another device is currently talking and the bus is therefore busy.
This translates into:
a) Being able to follow arbitration logic. If two devices start to communicate at the same time the one writing more zeros to the bus (or the slower device) wins the arbitration and the other device immediately discontinues any operation on the bus.
b) Bus busy detection. Each device must detect an ongoing bus communication and must not interrupt it. This is achieved by recognizing traffic and waiting for a stop condition to appear before starting to talk on the bus.
If you plan to use a multimaster device on a bus it is essential that all masters are multimasters. A single-master is simply a device, which does not understand the above mechanisms. If a singlemaster and a multimaster are connected, the singlemaster may well interrupt the multimaster causing unpredictable results.
From: http://www.i2c-bus.org/MultiMaster/
In this case I think the solution is “easy”.
The imp allows to change the function of any pin “on the fly”:
In addition to acting as a GPIO, each pin on the Imp can be configured to one of several hardware specialized functions. While pins may only have one function at a time, they may be reconfigured during run-time to change that function. For example, a pin may first be configured as a DAC and then reconfigured as an ADC. Additionally, not all the pins in a hardware function need to be assigned to that function. For example, pins 8 and 9 could be used as uart1289 and pins 1 and 2 could be used as i2c12.
Source: http://devwiki.electricimp.com/doku.php?id=imppinmux
In this case the solution is to set the pin 1 or 8 (SCL) as digital input and “listen” the activity on the bus for a minimum time to ensure that’s free, then change the configuration of the pins and start to communicate.
Obviosly the other masters over the bus must be capable to auto-sensing the activity as well, but this is explicit in the standard itself with the “bus busy detection”.
Dimitri
In theory multi-master should just work (I believe the I2C block in the SOC supports this), but I’ve never, ever seen this work well in any system I’ve come across…
I believe multi-master could work on slow and not too busy environments. If the frequency of communications between the different masters and the slaves is not too high, there is the time fo ranyone to keep “listening” the bus fo an amount of time adeguate. And this time should be probably different for the different masters. I guess if two masters are both listening for let’s say 10ms then is unlikely but theorically possible that both will start listening at the same time and transmitting at the same time as well, as they think the channel is free.
So the bus busy detection should be based on different, or even better random monitoring time.
@Hugo, according to the datasheet you remember right:
2.2.21 Inter-integrated circuit interface (I²C)
Up to three I2
C bus interfaces can operate in multimaster and slave modes. They can
support the Standard- and Fast-modes. They support the 7/10-bit addressing mode and the
7-bit dual addressing mode (as slave). A hardware CRC generation/verification is
embedded.
They can be served by DMA and they support SMBus 2.0/PMBus.
Maybe the “bus busy detection” could become a function in the APIs in one of the future versions of the firmware.