In both STM32Fx ports, we can see that both functions ‘EXTI15_10_IRQHandler’ and ‘HAL_GPIO_EXTI_Callback’ are defined with no possibility left to be removed through compilation configuration.
This library can be integrated in projects where these functions are already defined. Would it make sense to make it configurable at compile time to ease integration?
FreeRTOS doesn’t have a STM32Fx port, as that just uses the ARM_CM4F/ARM_CM4MPU ports.
You are likely seeing code provided by the STM Cube, which would be under the control of ST Micro, or a demo project that is intended to be edited if used as a base.
In Lab-Project-FreeRTOS-FAT, you can find several ports like STM32F4xx. Sorry, I cannot put link in my comment since I am a new user.
And if you read the description of the Laboratory Projects, they are not general “libraries” to be just included in another project, but are example projects to be used to base other projects on, and thus all that code is EXPECTED to be edited, and thus adding configuration defines to remove stuff isn’t needed. They are just example starting points to build your project from.
Hi
In here:
There is a STM32F4XX port:
The HAL_GPIO_EXTI_IRQHandler function is provided by STM as part of their hardware abstraction layer. You may need to reach out to them if you need custom behavior from this call.
The EXTI15_10_IRQHandler function can is part of the provided portable (port) layer and can be modified or extended to how you see fit.
Most likely, these definitions are modified to suit the needs of FreeRTOS-FAT. You are not supposed to compile the files from ST HAL. Can you exclude the following ST HAL files (the ones included in your STMCube generated project) from your project:
Also make sure that this path appears before the ST HAL path in your include search directories list. This is needed to ensure that the header files in the portable directory are used as opposed to the STMCube generated ones.
Thanks for the explanation.
I am actually not looking for a custom behaviour of this function. I am interested in having the possibility to have the implementation surrounded by ifndef/endif directives.
Since the handler EXTI15_10_IRQHandler can be used to manage other interrupt sources, it looks weird to me to have it in ff_sddisk.c. Similarly to what I described above, I am looking for a way to alter the behaviour of the library without modifying the source code.
To summarize, I would like to have the possibility to redefine both EXTI15_10_IRQHandler and HAL_GPIO_EXTI_IRQHandler in a place I think is better without the need to modify the source code of the library. A possibility could be to update the library with indef/endif surrounding the two functions.
Thanks for the explanation.
That is what I am currently doing in my project: file from ST HAL are effectively removed from the compilation.
The two files you mention are the not the problematic ones - ff_sddisk.c is. The fact that both EXTI15_10_IRQHandler and HAL_GPIO_EXTI_IRQHandler are defined in it prevents me from defining them somewhere else without modifying the source code. For instance, EXTI15_10_IRQHandler can be used to handle interrupt sources from other modules so I would like to have the possibility to define in a file I think is better for the project architecture.
can’t you attribute the existing implementations as weak so they can be overridden with your custom implementation?
Thank you for correcting!
Seems reasonable to me. Would you like to raise a PR?
Sure - I’ll do it shortly!
To my memory, ff_sddisk.c is the interface file that is supposed to be defined by the application to connect the FAT driver to the hardware. It is intended to be totally overwritten as needed (or if your hardware is close to the demo, you might be able to just slightly edit it).