One STM32 I2C controller with multiple I2C STM32 slaves

[saraverbeecke]

I was looking for a robust implementation of one controller, multiple slaves I2C setup on a stm32f411 and came across @peterhinch's wonderful library for handling this in an async context. I tested it on one master with one slave (both stm32f411) and it worked fine. Now I was wondering if this can be used with multiple slaves with no additional latency (since there still is a blocking portion)?

[peterhinch]

I think this would be difficult. If you look at the design section of the docs the initialisation code would need to be adapted. A bigger difficulty is synchronisation. Counter-intuitively transfers are initiated by the I2C slave. The challenge would be to ensure that multiple slaves do not attempt to do this concurrently.

[saraverbeecke]

Thanks Peter for the info. I'll look into it a little deeper.

[peterhinch]

Another communications option is syncom. This is point to point, but you could have multiple link instances on one platform. It is asynchronous, full duplex and cross platform. It can optionally detect an outage in an endpoint and issue a hardware reset.

It does have some significant drawbacks. It uses bit banging so is slow, and each link uses four GPIO lines.

[saraverbeecke]

Oh ok I didn't saw that doc yet on your repo. Speed is not so my concern so it may be come in handy. Especially it is usable in a pure async context. Do you think it can handle a lot of slaves (let's say 32?)

[peterhinch]

I think you'd run out of GPIO pins (4*32=128).

On further thought multi-drop I2C might be possible if there were only one initiator (I2C slave), with multiple responders (I2C masters). There would need to be a class (say Multiplexer) which opened multiple channels (Initiator instances) and took control of the process of interrupting the responders. I can see this becoming fairly involved.

There are a couple of issues with 32 responders: each requires 2 GPIO lines plus the two for the bus - 66 GPIOs! Secondly there may be electrical issues with an I2C bus having so many nodes. You might need strong pullups and possibly a low clock rate to deal with capacitance. I have no experience with that many nodes: perhaps someone else can advise.

You might want to consider CAN bus which is a proper multi-master bus on two wires. I have no experience of this - it seems only to be supported on STM but if this looks like it could meet your needs a specific query might raise some knowledgeable responses.

[saraverbeecke]

Indeed CAN looks promising then however I don't have experience in that as well...
I was reading through your docs regarding asyncio threading and asyncio context (THREADING.md).

1. Could the approach in the chapter "Taming Blocking Functions" work for the i2c.recv() blocking call?
2. Do you know how the dma=True in the init of the pyb.I2C works? Does it mean that the i2c data can be buffered temporary until the i2c.recv() runs or does the i2c.recv() has to run to enable the controller to be able to send data? I'm stuck in my head thinking wrongly that it acts like uart...

[peterhinch]

1. Yes - with the caveat that threading is relatively heavy on resources.
2. I'm not sure - I've never experimented with the option. When the pyb module was developed there was an ambition to create nonblocking interfaces for I2C, SPI, DAC, ADC etc. I suspect that the dma option was a prelude to that.

[saraverbeecke]

@peterhinch thank you for your answers.
I tested the unblocking mechanism but this seems not to work and I have no idea why. In my code snippet below (included both controller and peripheral side).
The pyboard running the controller code just sends a message each second.
On the peripheral side, the dummy running coroutine should be running multiple times before the next I2C data is received. The dummy function runs only one time between the receiver coroutine...

# CONTROLLER ###########
from pyb import I2C
import time


i2c = I2C(1)
i2c.init(I2C.MASTER, baudrate=400_000)
while True:
    i2c.send("test")
    time.sleep(1)

#########################



# PERIPHERAL ############
from pyb import I2C
import uasyncio as asyncio
from threadsafe import Message
import _thread


async def unblock(func, *args, **kwargs):
    def wrap(func, message, args, kwargs):
        message.set(func(*args, **kwargs))  # Run the blocking function.
    msg = Message()
    _thread.start_new_thread(wrap, (func, msg, args, kwargs))
    return await msg

async def receiver():
    while True:
        try:
            data = await unblock(i2c.recv, 4, timeout=1000)
            if data:
                print(data)
        except Exception as e:
            if e.args[0] == 110:  # ETIMEDOUT
                pass
            else:
                print(e)

async def some_other_task():
    while True:
        print("foo")
        await asyncio.sleep_ms(250)

try:
    i2c = I2C(1)
    i2c.init(I2C.SLAVE, addr=0x42)
    loop = asyncio.get_event_loop()
    asyncio.create_task(some_other_task())
    asyncio.create_task(receiver())
    loop.run_forever()
except KeyboardInterrupt:
    print("Event loop interrupted by user.")
except Exception as e:
    print(e)
finally:
    asyncio.new_event_loop()
    i2c.deinit()
    print("Done.")

#########################

Output:

foo
b'test'
foo
b'test'
foo
b'test'
foo
b'test'
foo
b'test'
foo
b'test'

[peterhinch]

What this seems to suggest is that I2C.recv may be locking up the entire CPU, disabling the threading mechanism. If this is the case I would regard it as a firmware bug.

You could test this theory by starting the following in another thread:

def test_function():
    while True:
        print("Test")
        time.sleep_ms(250)

If this fails to run concurrently then the above theory looks correct.

[saraverbeecke]

Running it in another thread fails to run concurrently.

[peterhinch]

You could raise an issue. You'd need a minimal reproducer: one thread trying to read from I2C while the other prints regular messages. I guess this might demonstrate the bug even if nothing were connected to the I2C interface.

I don't know how much priority this would have with the maintainers.

Meanwhile, if the read locks up the CPU, I can see no way to achieve concurrency.