Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
Sleep rework, RTOS API for bare metal, wait deprecations #10104
A chunk of work bringing together connected themes.
Points for discussion:
With this PR, you can take blinky, add
Pull request type
@kjbracey-arm see that
Doesn't work in general, unfortunately. The ARM architecture doesn't let you just run arbitrary code between LDREX and STREX - any intervening memory writes (such as storing stuff to the stack) could make the STREX fail, potentially causing a deadlock.
Thus the C code as it currently stands is already technically dodgy, as we can't be sure the compiler won't be putting any stores in, and a compiler warning about the dodginess is being suppressed with a pragma. LDREX/STREX should only really be used in assembler - the C intrinsics are deprecated. Putting in a callback would greatly increase the chance of failure at low optimisation levels as it would be inclined to push a return address to the stack.
So, if I were to do anything, I would be taking the LDREX/STREX intrinsics out, converting either to inline assembler or complete op compiler intrinsics. Compilers do these days have intrinsics for these ops, but afaict, they insist on them being SMP-compatible, thus adding DMB instructions we don't need.
Certainly it would make sense to reduce boilerplate by using macros to generate the code chunks.
The C/C++ general pattern for arbitrary ops, which doesn't suffer from the LDREX/STREX problem is:
There the LDREX/STREX pair is contained in the exchange, and you can have your code as complex as you like in the loop. I guess that construct could be wrapped into a "callback" pattern, but I don't fancy inventing a new style different from the standard.
Should do. The only static things are the "thread flags" for the main thread, and the SysTimer, and they should be stripped if no-one uses them.
There is a code cost of actually doing the sleep - when you change blinky from
In a bootloader type build or secure library, you'd presumably never call sleep or anything time related, so it should all stay out.
I am interested in learning about RTOS API for baremetal builds - what subset we want to provide? What is 3b7ddc5ceab29ffc96006c3cc58361f7be313f7f achieving ? RTOS API for baremetal - two worlds unite? It's large change, commit msg might help to understand the goal.
Do we have design document for this RTOS API? (would do some reading before I dig into implementation details)