2015-10-20 02:34 AM
Hello,
I updated ST library and got huge delay during I2C transfers when I have some errors. previously I manage timeouts in my firmware now some timeout hardcoded for example:#define I2C_TIMEOUT_FLAG ((uint32_t)35) /* 35 ms */
#define I2C_TIMEOUT_ADDR_SLAVE ((uint32_t)10000) /* 10 s */
#define I2C_TIMEOUT_BUSY_FLAG ((uint32_t)10000) /* 10 s */
Can you explain, why ST added it?
Previous library version used function argument.
Do you have plans remove this? Because if I use this function whith RTOS in HI priority task when happaned error will block all system on 10sec. it is not permissible.
BR,
Denis Krasutski
2015-10-26 09:15 AM
Hi krasutski.denis,
I2C_TIMEOUT_ADDR_SLAVE and I2C_TIMEOUT_BUSY_FLAG are calculated as following:(1/(minimum frequence=1Hz)) * 10 bits=10sWhich is the maximum value that can reach the timeout.By consequence, you can change it according to your application's frequency.''I updated ST library''what do you mean by this? do you mean you updated your firmware package or you moved from SPL to HAL?-Shahrzad-
2015-10-26 09:47 AM
As I read it, he's saying that in ~V1.8.0 you added a hard coded delay, that some prior version of same said Cube library did not.
2015-10-26 10:05 AM
I2C_TIMEOUT_BUSY_FLAG isn't in V1.3.0, use your source control tools to figure out when it was added.
STM32Cube_FW_F4_V1.3.0\Drivers\STM32F4xx_HAL_Driver\Src\stm32f4xx_hal_i2c.c2015-10-29 12:26 AM
>what do you mean by this? do you mean you updated your firmware package or you moved from SPL to HAL?
-Shahrzad-
I have changed HAL version.>By consequence, you can change it according to your application's frequency.
I adhere to the concept does not edit the Thirdparty library