I2C_HandleTypeDef structure for STM32F722ZETx doesn't have Device Address Anymore

[Jtron.11]

Would anyone knows why the STM32F7xx

in stm32f7xx_hal_i2c.h structure I2C_HandleTypeDef doesn't have

 __IO uint32_t       Devaddress;   /*!< I2C Target device address        */

 __IO uint32_t       Memaddress;   /*!< I2C Target memory address        */

 __IO uint32_t       MemaddSize;   /*!< I2C Target memory address size     */

Is there any substitute function to query for the I2C device address?

[Jtron.11]

Agree the master not sitting there and wait for the message. My context discussion focus on the I2C bus only. And if we have to one slave to return the message from the master, it will defeat the purpose using interrupt method

[Pavel A.]

> it will defeat the purpose using interrupt method

Not at all. The callback receives the I2C instance as parameter.

If you run two master operations on two host controllers in parallel, just keep separate instances of slave address per controller.

[Jtron.11]

Pavel and TDK,

May be I don't understand the operation correctly. Please correct me if I am wrong.

Let say I am using STM32 as the master, I2C1 bus has 3 slaves sensors, and if I am using HAL_I2C_Mem_Read_IT() to read back the data from three sensors.

The logic I check for the bus is HAL_I2C_STATE_READY then I use the Read_IT() to read sensor 1, then sensor 2, then sensor 3.

What are you and TDK saying is my callback will in turn execute as sequence the data receiving back from sensor 1, sensor 2, and sensor 3?

The bus will not be READY if I didn't receiving back data from any sensor hence the callback will not be called?

[Pavel A.]

> What are you and TDK saying is my callback will in turn execute as sequence the data receiving back from sensor 1, sensor 2, and sensor 3?

I guess it is so, because only one slave (the addressed one) can be active at any time. The master always knows which slave it talks to.

> The bus will not be READY if I didn't receiving back data from any sensor hence the callback will not be called?

Well, if some I2C device does not respond, you need to think on the recovery. Try to poll it again, try send N zero bytes to flush the bus... this can get complicated.