cancel
Showing results for 
Search instead for 
Did you mean: 

What's the best way for inter-STM32 devices communication?

SDomb
Associate

I'm a bit lost, so asking here. I'm currently writing the firmware for the device based on STM32F103RCT6 processor. I'd like to be able to have one master device and multiple slave devices, connect them and use the master device for managing other devices' settings. My initial idea was the following:

  1. I do not have separate firmwares for master and slave devices. I detect the master device by the fact that it's connected to the PC via USB (successfull).
  2. I connect all devices between each other using the I2C bus (specifically, the second I2C bus for this processor).
  3. Slaves wait for the master to initiate the transaction, master receives all the needed information from slaves.
  4. Master enumerates devices one-by-one by sending a message to the default I2C address of the slave devices and changes it's address to unique one.
  5. Next it requests the data needed and receives data from slaves using the unique addresses for each slave.

The idea was great, however:

  1. I wasn't able to make the I2C communication between master and slave stable when using the HAL_I2C_MasterReceive and HAL_I2C_SlaveSend methods. Even if I just continously send the same request from master and just handle it on the slave side (so I do not have a situation when both slave and master try to receive the data), it works only during some time. Next the bus stucks and I cannot transmit or receive the data and even resetting the I2C handle with HAL_I2C_DeInit + MX_I2C2_Init.
  2. Same happens if I try to first receive from master on the slave side and next immediately send reply to master from slave. I understand that most probably it's not clear what happens if I don't share the code, but let's assume that I first wait in a while() on the slave side, detect if any message from master is received, switch to waiting in a while() on the master side and try sending the reply from slave. It's just so unstable that I can't make 2 requests with a reply in a row.

So, questions:

  1. Will such approach work at all? I haven't tested it with multiple slaves and now I start thinking that it won't work with multiple slaves having the same address initially because of the address collisions.
  2. Which bus to use to achieve such kind of a communication between devices? I can't use SPI because all buses are alread occupied by other peripherals, and as I understand in case I have unlimited number of devices without a fixed count, I can't use it anyway. Here I need to understand the principle of organizing such a device network because now I think that my whole approach is wrong.

Any help / advice is greatly appreciated.

1 REPLY 1
TDK
Guru

1)

You've identified the issue. Slaves can't have the same address in I2C. There are ways to resolve bus contention like this but they're outside of the standard I2C tools. You could have each slave respond to the initial call with its unique identifier, and then for each bit, if the SDA line is driven low by another slave, drop off of the communication. This would let you assign unique addresses.

>  I understand that most probably it's not clear what happens if I don't share the code

Activity on the bus taken with a logic analyzer or scope may be more useful than the code.

2)

I2C or CAN are probably best, depending on your speed requirements.

If you feel a post has answered your question, please click "Accept as Solution".