Is it possible?: Two wire communication bus with ESP32 as a slave?

[michaelboatboy]

Question:
Does anybody know of a way to communicate to set up a two wire bus with ESP32 as a slave?

Why I want this:
I’m building a robot arm with six axises. Each axis has a custom motor driver/controller ESP32 board that I have been designing and programming months.

What I have tried:
I designed it to use I2C as the communication protocol. Little did I know that there is not a working ESP32 I2c slave library. I tried using uart as a bus but could not reliably turn off the TX pin when not in use.

What I haven’t tried:
I know 3 wire SPI works by tying the Miso and Mosi together. Would it be possible to remove the CS pin by using addressing?

What I know I could do as last resort:
I could use the SPI 3 wire and solder on a chip select pin to each esp32 motor driver.
I could also switch my entire program to Arduino instead but I have already spent months on this micropython program and am not fluent in Arduino

If anybody has any ideas for how I can connect each esp32 in a bus with two wires, I would greatly appreciate the help!

[jomasnash]

I Don't know if your controller is also a esp32. If so, can you not use websockets?
Otherwise you can consider RS485, or implement i2c slave yourself.

[michaelboatboy]

Thanks, I did design the esp32 board to have a pcb antena but I cut it off for space. I did try and find a RS485 library but didn’t know that it was just UART which is what I ended up doing.

[rkompass]

This is a recurring question. I'm no expert in it.

With googling I found this (in German, I attach a translation with deepl.com).
esp_als_i2c_slave_en.pdf.
From my first impression this is polling the pins in MP bytecode, so rather slow. Seems to be able to follow a 100Hz clock rate though.
Would be interesting if you could speed things up using Viper, for example. Quite interesting read anyway.

This is no full satisfactory solution, of course.
See this RFC (3935) for the state of slave i2c and Damiens concepts what a good/lasting implementation should provide. At present there seems i2c slave officially implemented only for the STM32, e.g. with Pyboard.

Apart from this there are inofficial solutions for the RP2 Pico, which should work well, given that you might employ the PIO machinery.

There was an implementation for the ESP32 by Loboris, for an earlier version of the firmware. Someone with ESP32 expertise might extract the code and see if it is compatible with recent firmware.
It would not be in agreement with the proposed API, however, and this may be a reason nobody did this.

Also the question appears if SoftI2C, which works quite well, cannot be extended in a minimal way to slave mode.

What I have tried:
I designed it to use I2C as the communication protocol. Little did I know that there is not a working ESP32 I2c slave library. I tried using uart as a bus but could not reliably turn off the TX pin when not in use.

Using UART might be much easier. Recently there was even a callback implemented which would be fired, when there are messages received. You might be able to access the TX pin as ordinary pin in parallel to UART mode. I would at least try this.

[michaelboatboy]

Thanks, I did find that I2C implementation in German but was scared to use it because it used softspi and I needed to control 6 steppers at once with high speeds. I ended up figuring a way out to use UART like you mentioned.

[peterhinch]

Using UART might be much easier.

I agree with that - in spades. UART communication is highly reliable. If you're using asyncio the StreamReader and StreamWriter objects "just work".

You mention turning off the TX pin. That is not necessary. When a UART is idling the pin is high. The receiver recognises this state as an idle state and produces no output until data is received.

[michaelboatboy]

I was thinking that the idle state would interfere with other slaves trying to use that TX line so I set the output of the tx line to high impedance by changing the pin to input while not transmitting which seems to work well.

[shariltumin]

If all seven of your MCUs are esp32 (one controller and six motor drivers), I have a few suggestions:

1. espnow: controller sends broadcast. The motor drivers listen and respond.
2. UDP: controller as AP, motor drivers connect to AP. Controller sends UDP broadcast.
3. As @jomasnash, RS484-TTL(UART): controller schedules which motor-driver can send.

[michaelboatboy]

Thanks yall for your ideas and help! I finally got this working using UART. The master esp32 would send commands each with an ID of the slave and the slave with the correct ID would respond. The problem was that each slave had set the TX bus to idle (high) when not transmitting preventing the other slaves from talking. By setting the TX pin to high impedance (input mode) it stopped that. I had to set it back though and reinitialize UART unfortunately every transition but it works. Here is the UART slave code I used.

#--------------------------------------------------------------------
#This class is the UART slave that will be used to communicate to the master which would be a different
#microcontroller that would be controlling this servo
#UART_PORT - the software UART port used for this object
#TX - the transmision pin
#RX - the receiving pin
#BAUDRATE - the baudrate used for UART communiation
#-------------------------------------------------------------------- 
class UART_SLAVE:
    def __init__(self, UART_PORT, TX, RX, BAUDRATE=115200):
        from machine import UART
        self.debug_mode = 1
        self.buffer = ""  # Buffer to accumulate incoming data
        self.tx = TX
        self.rx = RX
        self.baudrate = BAUDRATE
        self.uart_port = UART_PORT
        # Control the TX pin (Initially set to high impedance mode)
        self.tx_pin = Pin(self.tx, Pin.OUT)  # Set TX pin as input (high impedance initially)
        self.rx_pin = Pin(self.rx, Pin.IN)  # Set TX pin as input (high impedance initially)

        self.uart = UART(self.uart_port, baudrate=self.baudrate, tx=self.tx_pin, rx=self.rx_pin,rxbuf=256)
        self.tx_pin.init(Pin.IN)

#--------------------------------------------------------------------
#debug level one messages
#--------------------------------------------------------------------        
    def d1print(self,text):
        if self.debug_mode > 0:
            print(f'>>>UART Slave|{text}<<<')        
#-----------------------------------------------h---------------------
#functionality that updates the UART communication process that needs to be updated every cycle
#--------------------------------------------------------------------     
    def update_uart(self, func):

        if self.uart.any():
            raw_data = self.uart.read()  # Read all available data
            if raw_data:
                # Decode raw_data only if it's bytes, otherwise use it directly
                if isinstance(raw_data, bytes):
                    try:
                        raw_data = raw_data.decode()  # Convert bytes to string
                    except:
                        self.d1print(f"Unicode Error: {raw_data}")
                        return False
                
                self.buffer += raw_data  # Accumulate data in the buffer
                
                # Process all complete messages (delimited by '\n')
                while '\n' in self.buffer:
                    message, self.buffer = self.buffer.split('\n', 1)
                    self.d1print(f"Received: {message.strip()}")
                    data = func(message.strip())  # Process the message
                    if data:
                        self.d1print(f"sending: {data}")
                        self.tx_pin.init(Pin.OUT)
                        self.uart = UART(self.uart_port, baudrate=self.baudrate, tx=self.tx_pin, rx=self.rx_pin,rxbuf=256)
                        self.uart.write(data.encode() if isinstance(data, str) else data)#writing data
                        self.tx_pin.init(Pin.IN)
            return True

        return False

[rkompass]

Nice. Thanks for the feedback and for sharing the code.
So the double-control of the TX pin for switching between high impedance Pin.IN and UART-Pin.OUT is working!

In case that you still are interested in changing and trying out other solutions:
Peter wrote:

You mention turning off the TX pin. That is not necessary. When a UART is idling the pin is high.

That leaves the possiblility to employ an open-drain circuit, perhaps using extra pull-up resistors, exactly like with I2C lines.
UART idling would then already be high impedance.
Assuming the UART init of the pin does not change the IN/OUT mode, you might try to change
self.tx_pin.init(Pin.OUT) to self.tx_pin.init(Pin.OPEN_DRAIN, pull=Pin.PULL_UP) and perhaps add an extra pull-up resistor.
The self.tx_pin.init(Pin.IN) below then might be removed.

Also: instead of self.uart = UART(self.uart_port, baudrate=self.baudrate, tx=self.tx_pin, rx=self.rx_pin,rxbuf=256) every time: Isn't there an init function that you may use instead, like self.uart.init(self.uart_port, baudrate=self.baudrate, tx=self.tx_pin, rx=self.rx_pin,rxbuf=256), perhaps only self.uart.init(tx=self.tx_pin)?

[michaelboatboy]

Thank you for the ideas, i guess i didn't quite rap my head around what he meant. That makes sense and I will definitely try than and let y'all know if it works!

[rkompass]

I had a look into the sources and did a short test:

from machine import Pin

# All these three Pins should be connected together.

p17 = Pin(17, Pin.OPEN_DRAIN, pull=Pin.PULL_UP)   # This sets to GPIO_MODE_INPUT_OUTPUT_OD and GPIO_PULLUP_ENABLE
p18 = Pin(18, Pin.OPEN_DRAIN, pull=Pin.PULL_UP)
p5 = Pin(5, Pin.IN)

p17(1); p18(1); print(f'p17(1); p18(1); --> p5()={p5()}')
p17(0); p18(1); print(f'p17(0); p18(1); --> p5()={p5()}')
p17(1); p18(0); print(f'p17(1); p18(0); --> p5()={p5()}')
p17(0); p18(0); print(f'p17(0); p18(0); --> p5()={p5()}')
print()

# Because p17 and p18 are also inputs, they see the pull-down of other connected pins:
p17(1); p18(1); print(f'p17(1); p18(1); --> p17()={p17()}, p18()={p18()}')
p17(0); p18(1); print(f'p17(0); p18(1); --> p17()={p17()}, p18()={p18()}')
p17(1); p18(0); print(f'p17(1); p18(0); --> p17()={p17()}, p18()={p18()}')
p17(0); p18(0); print(f'p17(0); p18(0); --> p17()={p17()}, p18()={p18()}')

gives the output:

p17(1); p18(1); --> p5()=1
p17(0); p18(1); --> p5()=0
p17(1); p18(0); --> p5()=0
p17(0); p18(0); --> p5()=0

p17(1); p18(1); --> p17()=1, p18()=1
p17(0); p18(1); --> p17()=0, p18()=0
p17(1); p18(0); --> p17()=0, p18()=0
p17(0); p18(0); --> p17()=0, p18()=0

so the above setting to GPIO_MODE_INPUT_OUTPUT_OD and GPIO_PULLUP_ENABLE seems to work well.

I had some doubt, because this mode is not in the documentation.