cancel
Showing results for 
Search instead for 
Did you mean: 

New to STM32 / CubeIDE, where to start for an I2C Slave?

silvan.rehm
Associate II

Hi There,

the goal is to get data from an MCU via I2C to a Raspberry Pi. I already have this working with ATMegas but would like to move to the STM32 Platfrom.

Seems I'm quite spoiled as all I needed to get I2C working was this:

void sendData(){
  byte buffer[32];
for(i = 0; i < 32; i++) {
    buffer[i] = i;
  }
Wire.write(buffer, 32);
 
Wire.begin(SLAVE_ADDRESS);
Wire.onRequest(sendData);

(the buffer would be filled with useful stuff of course).

When programming the MCU via the Platform IO the i2cdetect on the RPI detects it - wiring seems ok

Now I got myself set up with the new CubeIDE, using a SMT32F103C8T6 for now.

Got LEDs blinking, yay.

Did setup I2C1 for PB6&7 (loving the device configuration tool), set the slave address. Hoping this would be enough to detect it from the RPi.

Searching for Examples I started to realize it won't be 2 only 2 lines as I am used to. This is not a problem, the problem is:

Where to start? What is the 'propper' way to set up a I2C Slave which shares a bunch of floats via I2C?

1 REPLY 1
CArena
Associate II

Silvan,

I'm having a similar problem with an I2C slave example.

What I think I've worked out so far:

1) set up the LISTEN on the slave so that the slave address is recognized when it goes by on the wire.

2) When the listen call back is made, the direction is a parameter in the callback. That lets you pick either the transmit (if it's a read of the slave) or receive of the data (if it's a write).

3) "Reset" the device to set up the LISTEN for the next read/write.

What's happening in my case is the I2C data stops flowing when the slave isn't set to handle the next read or write: the hardware recognizes the address, but the interrupt isn't enabled fast enough to get the address recognition interrupt to fire. The clock gets stretched, and the I2C bus stops because the slave hasn't handled the recognition of its address.

Perhaps I need to raise the priority of the I2C interrupt so that it be higher than the SysTick interrupt? Gonna try that.

Chris