how can we verify the rtos compliance of the HAL drivers ?

[Shrikant Lahane]

Posted on February 04, 2018 at 05:59

oliverbeirne

‌

How to verify that HAL drivers use atomic read modify write operations for multiple instance support? 

Do the low-level code call STREX LDREX instructions?

Does the time-out mechanism used to follow the rules of RTOS, for instance, will the timeout mechanism in the APIs of HAL drivers cause the calling task to enter a blocked state until the timeout period expires?  

Note: Above question is in reference to the document 

UM1725 User manual Description of STM32F4 HAL and LL drivers

Please explain and if possible give the references to the standard documents.

Thank you

Best regards

#rtos #stm32f4-hal-driver #stm32-free-rtos

[Tesla DeLorean]

Posted on February 04, 2018 at 15:23

These are really things you should validate to your own satisfaction.

By using the library you assume all responsibility for any failures or failing of the resultant code. Code is provided AS IS.

[Shrikant Lahane]

Posted on February 04, 2018 at 16:36

thank you for the reply.

but I did check the timeout mechanism used. It suggests that to implement the timeout mechanism the driver is actually polling instead of getting blocked. So should the claim made in the document of being RTOS compliant considered incorrect? since while timeouts the tasks must be blocked states.

[henry.dick]

Posted on February 04, 2018 at 18:10

'

How to verify that HAL drivers use atomic read modify write operations for multiple instance support?'

probably best asked of ST, if you cannot confirm by looking at the HAL source code.

[Tesla DeLorean]

Posted on February 04, 2018 at 18:47

>>

probably best asked of ST, if you cannot confirm by looking at the HAL source code.

One could certainly ask them, but they disclaim any/all liability, so any statement would be of no value in certification or legal proceedings. The best course of action is to do a code review, and inspect compiler output. I would definitely recommend running Lint, or MISRA type inspection tools against the source trees.

Atomic action is only of value to memory locations, not peripherals which act completely autonomously.

Code examples definitely exhibit blocking in interrupt context, and hard failure on errors. I would be worried about thread safety, and serialization of resources. On F7 implementations one would need to be self-aware of memory regions being used/allocated, and cache coherency issues, which can present dynamically, and not entirely discernible from static analysis of source code.

[Shrikant Lahane]

Posted on February 04, 2018 at 19:33

my question is does a task get blocked when HAL driver has timed-out or does it just waste instruction cycles in a while loop as can be seen.

does the HAL locking mechanism employ atomic read modify write mechanism while locking? does the assembly language code contain strex/ldrex instructions?

after investigating I concluded that it doesn't. I just want it to be verified.

[Pavel A.]

Posted on February 04, 2018 at 19:49

HAL_Delay() function by itself is blocking and wastes time. Yep.

The HAL library source (in F0 variant, v 1.9 at least) is strewn by something named HAL_LOCK but this is not defined as something sensible, and there are some comments that 'USE_RTOS' should not be defined with this lib... so it looks like mirageware in a desert...

--pa

[Shrikant Lahane]

Posted on February 05, 2018 at 03:21

so by blocking do you mean that the calling task/thread in the RTOS goes into a blocked state(Not running) and the task in the ready state starts executing next.

[Pavel A.]

Posted on February 05, 2018 at 16:04

Depends on RTOS. Interrupts should run; if the RTOS has preemptive scheduling it should work as well.

But generally, we get more or less what we've paid for 

--pa

[Tesla DeLorean]

Posted on February 05, 2018 at 17:04

The instruction use would be a function of the porting and the compiler.

I don't believe the RTOS is tightly integrated, but accommodated via HAL_Delay and HAL_GetTick providing yield points.