pyb.I2C.SLAVE can't discover.

[water]

I create a I2C slave via:

Code: Select all

i2c = pyb.I2C(1, pyb.I2C.SLAVE, addr = 0x43)

then connect PB6(scl), PB7(sda), GND to other board, but i2c scan result is empty on other board, and I try to connect it to RPi's I2C also.

What step I missing ?

[pythoncoder]

Using slave mode is tricky because the slave must be set up to receive in order for it to respond to the master. This presents difficulties synchronising the code on slave and master. In general it is much easier to use a UART.

However if you need to use slave mode there is this driver which enables an I2C interface to provide a bidirectional UART-like interface, but it does require extra wires for synchronisation.

[water]

I2C design to 2-wire, I'm curious how to test when writing this docutment:
http://docs.micropython.org/en/latest/l ... b.I2C.html


What's purpose of pyb.I2C.SLAVE ?
And the pyb.I2C() big different between machine.I2C().

[pythoncoder]

...
What's purpose of pyb.I2C.SLAVE ?

It can be used, but it requires attention to detail because the slave will only respond to the master if it's in read mode. So you need to design a protocol to ensure the master only tries to access the slave when the slave is ready to receive. That is what the driver that I mentioned does.

...
And the pyb.I2C() big different between machine.I2C().

The machine module is designed to support a wide range of physical hardware; most platforms don't support slave mode. So machine does not offer it. Pyboard hardware does support it, hence MicroPython support is in the Pyboard specific pyb.

For most purposes you are far better off using a UART to achieve a 2-wire plus ground interface. Why do you want to use I2C slave mode?

[water]

I want to let pyboard works as I2C slave like SSD1306, BME280 ... , when receive command, do something, why those devices can do that with 2-wires ?

[pythoncoder]

Those devices are silicon chips and use dedicated circuitry to handle the interface. The circuitry is active whenever the device is powered up.

As a processor, the Pyboard requires code to be driving the interface. Aside from my approach of using a synchronisation protocol, another way may be to use threading with one thread dedicated to handling the interface. I haven't tried this, but it would be an interesting thing to attempt.