2024-01-24 10:03 PM
In my project, my MCU (F411) uses I2C HAL API routinely to read from a sensor device.
When some event happens, my interrupt handler will use I2C API to read from different register from that device; so my question is:
Solved! Go to Solution.
2024-01-24 10:51 PM
Probably not in the way you need it to be.
If interacting from multiple interrupts and callbacks you probably want to serialize or queue operations you want to perform. ie you complete one slave command or operation and then sequence to the next.
2024-01-24 10:51 PM
Probably not in the way you need it to be.
If interacting from multiple interrupts and callbacks you probably want to serialize or queue operations you want to perform. ie you complete one slave command or operation and then sequence to the next.
2024-01-24 11:27 PM
Thx for your advice.
I am curious to know:
2024-01-25 07:03 AM
The compiler doesn't schedule anything, it'll call what you told it to call. Calling I2C from the main thread and the IRQ is not advisable. If the main thread is in the middle of an I2C call, the IRQ call will fail (at best) or corrupt what was going on (at worst). There is a locking mechanism but it is not robust.
2024-01-25 04:43 PM
If it's not the compiler, then it's the MCU itself, isn't it?
I imagine that MCU is doing I2C operation, if IRQ occurs, it pauses I2C in the middle of somewhere, and responds. If in the IRQ there is another I2C call, it leads to big trouble: not only new I2C call fails, but also the existing I2C is disrupted.
I guess that's why it is advised that IRQ function is as slim as possible.
Thx. @TDK
2024-01-25 05:18 PM
>If it's not the compiler, then it's the MCU itself, isn't it?
It's the programmer. The person who designs the code. A bug between the chair and the keyboard, as they used to call this ~ 30 years ago))
2024-01-29 11:08 PM
We are not bug, but bug creator.😁