Re: (Big) problems achieving fair scheduling of a semaphore ISR producer - thread consumer case

Paul Sokolovsky

Hello Erwan,

On Mon, 10 Apr 2017 17:18:13 +0200
Erwan Gouriou <> wrote:


About stm32 driver and Cube HAL, I'd like to mention that a Low
Level cube
API is now available
on almost all stm32 families (LL). This API intends to be lightweight
and modular and hence have
a better fit with Zephyr architecture.

I'd like to start implementing drivers with this LL API soon.
It would still be a HAL (hence I understand some people would still
I appreciate the response.

We discussed the HAL issue at the OpenIoT Summit, and well, both sides
have good arguments. I appreciate arguments of SoC vendors, the main
ones being that it allows to support entire families and groups of
families, and that it allows to reuse code which already undergone
prolonged development and (some level of) testing. But it's indeed not
a good situation when using HAL causes additional artifacts in Zephyr
drivers, like arguably discovered by Daniel in STM32 UART poll-out

I had a look at (few) LL functions, and saw they're indeed lightweight,
so using them sounds like a good plan.

but would allow to have
a driver implementation closer to zephyr needs, removing a part of
redundant functionalities and still
allow to implement (as far as possible) stm32 generic drivers.

This won't solve current issue (as I understood), but I hope it could
help to simplify things on stm32 side.
So, the current biggest issue, as I see it, is that Zephyr doesn't seem
to provide a well-established baseline for the behavior of various
subsystems, in the case discussed - UART console. This in turns leads
to artifacts and deviations in driver implementations for different
SoCs - simply because there's no good integration test for all the
different calls.

I also received reply that the subsystem is known to work for large
amounts of data, pointing e.g. tests/bluetooth/tester/ . Indeed, it
works with the current implementation, but only due to specially
constructed protocol, so that testcase doesn't expose
deficiencies. (Un)fortunately, exposing it's easy - with just a
clipboard paste into a terminal application, with mere UART echo
running on the device side. (And that's just a testcase, the actual
issue is non-reliability with more generic UART protocols, than e.g.
used by tests/bluetooth/tester).

So, I propose to establish *that* as a UART console baseline, and
indeed, it will require changes down to the level of SoC UART
drivers. An initial draft patch for STM32 was posted:


Best Regards,
Paul | Open source software for ARM SoCs
Follow Linaro:!/linaroorg -

Join to automatically receive all group messages.