2024-04-27 12:37 AM - edited 2024-04-27 12:38 AM
Solved! Go to Solution.
2024-04-27 01:37 PM
I2C is very slow in microcontroller terms. The processor could do thousands of machine instructions in the time it takes to do an I2C transfer.
The “base” functions (without _IT, without _DMA) are ”blocking” - they do not return until the requested action is complete. During the transfer the processor is largely sitting idle.
Where you do have something else for the processor to do at the same time as the slow I2C transfer, you can use the _IT or _ DMA version of the call. The processor will return immediately so you can tell it to do other things. But until you get a callback/interrupt telling you that the I2C transfer is complete, you can’t do anything else with I2C - that bit of hardware is busy.
This should explain why you don’t see all the requested transactions when the first call is an interrupt one. Incidentally I assume those functions return a value. This would normally be HAL_OK but they should give an error code if the I2C is still busy with an earlier transaction.
I should add that I don’t use HAL because I don’t find enough documentation about how to use it. My needs are rarely close enough to the examples, and automatically-generated “help” files give no greater insight than reading the source code.
2024-04-27 01:37 PM
I2C is very slow in microcontroller terms. The processor could do thousands of machine instructions in the time it takes to do an I2C transfer.
The “base” functions (without _IT, without _DMA) are ”blocking” - they do not return until the requested action is complete. During the transfer the processor is largely sitting idle.
Where you do have something else for the processor to do at the same time as the slow I2C transfer, you can use the _IT or _ DMA version of the call. The processor will return immediately so you can tell it to do other things. But until you get a callback/interrupt telling you that the I2C transfer is complete, you can’t do anything else with I2C - that bit of hardware is busy.
This should explain why you don’t see all the requested transactions when the first call is an interrupt one. Incidentally I assume those functions return a value. This would normally be HAL_OK but they should give an error code if the I2C is still busy with an earlier transaction.
I should add that I don’t use HAL because I don’t find enough documentation about how to use it. My needs are rarely close enough to the examples, and automatically-generated “help” files give no greater insight than reading the source code.
2024-04-29 11:02 PM
ThankYou ! @Danish1 for the reply. So if I want to send or receive using Interrupts or DMA, what should I do. Only polling method will not be sufficient in all the cases. So could you direct me towards what should be done, to make I2C work using the Interrupt method?DMA Method.
2024-04-30 12:35 AM - edited 2024-04-30 12:36 AM
I strongly recommend the Reference Manual for your STM32. This is the best source of documentation for the peripherals ST place around the arm processor core. It has an entire chapter on I2C, and another on DMA. But I will admit that its completeness does give a steep learning-curve. You should also have access to the Programming Manual which describes the arm core and the peripherals that Arm designed; this might help you understand interrupt-handling.
@vbk22398 wrote:ThankYou ! @Danish1 for the reply. So if I want to send or receive using Interrupts or DMA, what should I do. Only polling method will not be sufficient in all the cases. So could you direct me towards what should be done, to make I2C work using the Interrupt method?DMA Method.
And there you have described the problem as I see it. I am not aware of documentation that tells us how to use the HAL libraries. The best we have are examples of their use - for example (I didn't pick up which stm32 microcontroller you're using) looking in STM32Cube_FW_F4_V1.25.2 (the version I happen to have downloaded, back from 2021) we have Projects\STM32F429I-Discovery\Examples\I2C the following directories:
Careful study of the source-code in those examples might give you enough information on how to use the HAL calls in interrupt or DMA modes. But you'll probably have to do quite a few experiments to verify that your understanding is correct. And just hope that you have covered "unexpected" failures that didn't turn up during your tests.