search

ARM-software / CMSIS_5

CMSIS Version 5 Development Repository
http://arm-software.github.io/CMSIS_5/index.html
Apache License 2.0
1.32k stars 1.08k forks source link

NVIC Priority in CMSIS Driver #299

Closed wpramadi closed 6 years ago

wpramadi commented 6 years ago

Hi, I'm using CMSIS Driver(with STM32) and CMSIS RTOS2(with FreeRTOS) for my project. The CMSIS Driver (whether it is SPI/USART) will trigger a callback and pass an event flag when it's complete some data transfer or an error has occurs. This callback is executed from ISR context and I usually raise a flag (osThreadFlagSet) so I can execute the rest outside the ISR. For some case it works well but sometimes the flag never reach the thread. After looking into the driver it looks like the driver never set the NVIC priority. I remember that the NVIC priority must be set to a certain value in order for the signaling between ISR and the thread works in FreeRTOS. I set NVIC priority as 15 before it enable it and now it works.

I'm not sure if it's the correct way though, are you guys going to look on this problem?

mgiaco commented 6 years ago

@wpramadi My question is a little bit offtopic. But I found that on my search about CMSIS-Driver and FreeRTOS and STM32. I was wondering if someone using this... Can you share any basic project to see which versions you use? many thanks

wpramadi commented 6 years ago

Here some version details from the RTE component page:

I was wondering as well if people really adopting this standards. I'm planning to build libraries on top of this CMSIS standard.

mgiaco commented 6 years ago

@wpramadi Okay many thanks. But you are using Keil - right?

wpramadi commented 6 years ago

@mgiaco nope, I'm using Atollic. I have to deal with missing linker script manually and add USE_HAL_DRIVER symbol everytime the RTE components updating the project in Atollic.

JonatanAntoni commented 6 years ago

Hi @wpramadi,

Thanks for getting in touch regarding this issue.

In fact CMSIS-Driver is only a thin API layer that can be mapped to whatever hardware underneath. Typically we (and various silicon vendors) provide these wrappers along with the CMSIS Device Family Packs (DFP). The actual implementation is taken from the silicon vendors libraries, i.e. Cube for STM.

It depends on the actual driver implementation whether interrupt priorities are considered during initialization and/or power up. In case of STM you might use CubeMX to generate the low level initialization code needed. Or you might prefer to handcraft this portion. Please consider getting in touch with the Cube community as well.

Regarding the current use cases for CMSIS-Driver APIs there has not been any need to control the interrupt priorities through the API, yet. Typical scenarios are all kind of middleware (communication) stacks, i.e. TCP/IP, CAN, File System, aso. All of them just rely on a proper ISR configuration.

@mgiaco: A growing amount of silicon, middleware and tool vendors are currently adopting CMSIS-Pack and CMSIS-Driver. This should make interoperability much easier to maintain.

Please feel free to share your ideas about how we might improve the user experience.

Best, Jonatan

wpramadi commented 6 years ago

Hi @JonatanAntoni,

I agree that apart from using FreeRTOS flags/semaphore in ISR, this kind of issue will not appear. I think I'll deal with this priority issue with custom changes on the driver for now.

As for improving user experience, the CMSIS driver API feels a bit weird to me but I think it just a matter of personal preferences on defining API. I just started using this CMSIS driver last month and still exploring what's good and what's missing. Next time I'll post separately if I already have a good proposal for the API improvement.

It's quite clear now so I'll close this issue. Thanks for your feedback.

JonatanAntoni commented 6 years ago

Hi @wpramadi,

Thanks for sharing our thoughts.

The ISR configuration is always an issue. I.e. CMSIS-RTOS2 reference implementation RTX5 requires a proper interrupt priority configuration as well. The simplest case should be a hard coded interrupt initialization that is done during startup. In this case all application code (including drivers and middleware) simply assume a proper interrupt configuration and keep the hands off it. For sure if you have a more complex scenario you might need drivers to take care of their interrupt configuration.

Looking forward to get your feedback.

-Jonatan