XferOptions for I2C slave. Are they a useless appendix of the HAL-Driver

[laserfaser]

Hello my friends,

I am trying to setup an I2C slave that is being addressed with a read-request and then answers a fixed number of bytes. I was trying to find out what the XferOptions do, but after I could not find out I went through the HAL-driver code myself and found no location where they are actually being used. The basic procedure is, that interrupts are being generated by the hardware, set some flags, and in the TX-Slave part of the code, nowhere the XferOptions are used (am I right?). So I dont know what to do with them, just write anything in? Is this a "Bug" in that sense that the lib asks you for a parameter that is never being used?

 

void HAL_I2C_AddrCallback(I2C_HandleTypeDef *hi2c, uint8_t TransferDirection, uint16_t AddrMatchCode){
	if (TransferDirection == I2C_DIRECTION_TRANSMIT) // if the master wants to transmit the data
		{
			//HAL_I2C_Slave_Seq_Receive_IT(hi2c, &dummy_in, 1, I2C_FIRST_FRAME);
			RINGBUFFER_reset();
		}
	else{
		RINGBUFFER_dequeue(&data);

		//TODO: put into dataOutArr
		HAL_I2C_Slave_Seq_Transmit_IT(hi2c, (uint8_t*)&data, 9, ???);
	}
}

 

 

[TDK]

> Is this a "Bug" in that sense that the lib asks you for a parameter that is never being used?

They are used in the IRQ handlers. For example, here:

stm32f1xx_hal_driver/Src/stm32f1xx_hal_i2c.c at 6ca7fc40cc862623dc05b33b0014789c1fbbbb86 · STMicroelectronics/stm32f1xx_hal_driver (github.com)

 

> So I dont know what to do with them, just write anything in?

They are used by the IRQ handlers to know which stage the communication is in, how many bytes you're sending. The various values are shown here:

stm32f1xx_hal_driver/Src/stm32f1xx_hal_i2c.c at 6ca7fc40cc862623dc05b33b0014789c1fbbbb86 · STMicroelectronics/stm32f1xx_hal_driver (github.com)

Generally you probably want I2C_LAST_FRAME. There aren't many examples out there for this call to I2C, but here is one, perhaps you can use it as a guide.

STM32CubeU0/Projects/NUCLEO-U083RC/Examples/I2C/I2C_TwoBoards_RestartAdvComIT/Src/main.c at 6452b2170313f522b4a3372054d2462b77d890d1 · STMicroelectronics/STM32CubeU0 (github.com)

 

[laserfaser]

Thats what I'm saying: They aren't. When you go to your mentioned IRQ routine, it looks, what caused the interrupt, in what mode we are and so on. But when you closely look into all functions called by the slave-part of the irq-handler-function, none of them uses the xferoptions given to them by the i2c-handle. You only pointed me to the line where the interrupt-part starts, that is, when an interrupt ist being sensed, this function is called. It looks what mode we are in, what functions to call depending on what caused the interrupt and so on, and then calls various functions, down to user-implemented functions. Yet, in none of them there is any usage of Xferoptions. Xfercount, sure, it is used intrinsically to count-down how many bytes to send, but not Xferoptions. Or am I missing something here? No offense, I politely disagree with you. Please tell me where I am wrong.

[TDK]

> But when you closely look into all functions called by the slave-part of the irq-handler-function, none of them uses the xferoptions given to them by the i2c-handle.

Ahh, so slave-specific functions. You could be correct here. I didn't dig down that far.

At the least, it checks for validity of the parameter within HAL_I2C_Slave_Seq_Transmit_IT.

[laserfaser]

Yes, slave specific. I was specifically asking for the

HAL_I2C_Slave_Seq_Transmit_IT

function. But good, so it is not that I am not understanding something here but just maybe a remainder of something it used to do or something. So I will go ahead and not worry too much about it. Lol my man, thanks. I will try to make it work and if I was wrong and Xferoptions does something I did not see, I will tell you here. Maybe it helps someone in the future, wondering about the same things here.