Do you prefer the low layer (LL) APIs or CMSIS?

If by CMSIS you mean using the symbols defined in the CMSIS-mandated device headers (and not using SPL, as there are users who confuse CMSIS with SPL), then I vote for that.

The reason is, that I see no point in what's effectively is just renaming the registers and in most cases pretending that there are function calls where a single register or a register bit/bitfield is changed. That's just an unnecessary hindrance, as for the user, mapping between the "library" and the RM has to be established.

Unfortunately, in the CMSIS-mandated device headers, ST fails to provide symbols for values for registers bitfields (yet does this haphazardly in the various "libraries").

My personal view, arguable.

JW

"do you prefer the low layer (LL) APIs or direct register access by means of the CMSIS? "

the wrong way to use any vendor library is to incorporate such libraries directly into your code. once you do that, your code is no longer portable. instead, I often use a layer that sits in between my application code and whatever libraries, mine or others, LL or SPL. with this approach, you don't have to worry about (LL)API or CMSIS.

@henry.dick​ 

You are talking about a hardware abstraction layer (ST's cube HAL is not a real abstraction layer). I'm not asking about HAL APIs, but which approach (CMSIS vs LL) people use in order to implement a HAL. A good software architecture always has got a HAL for the middleware (and application layers). However, in the end each HAL uses either direct register access (by CMSIS), something like ST's cube HAL, or the LL APIs.

https://www.beningo.com/embedded-basics-apis-vs-hals/

> A good software architecture always has got a HAL for the middleware (and application layers).

... and I thought you are genuinely interested.

JW

I am genuinely interested in whether people prefer the CMSIS or the LL Apis.

"and I thought you are genuinely interested."

​

Apparently some of us are not really interested in things we insisted that we are interested in, :-)​