Are there resources to more easily understand peripheral versions used across families?

[unicycle]

I use a lot of STM32s in my work. The reference manuals, datasheets and so on are excellent but often contain a lot of near repetition between families. What I mean is that the details of the registers for (say) GPIO are often identical. But not always or not quite. It seems clear that there are multiple different versions of the silicon blocks used for various peripherals, depending on the family (as you'd expect). For example, GPIO features appear identical for F0 and F4; G4 is almost the same, but has an extra BRR register; F1 is very different. DMAs for F0, F4 and G4 are significantly different from each other. And so on.

This makes writing portable drivers a bit awkward. For fun, I like to write drivers directly from the reference manual - no CMSIS or other dependency. But will the code I write for some peripheral on F0 be reusable on a G0, or an L4, or whatever? It is hard to be sure. Now, I could just rewrite drivers for each family (like HAL, I guess) but would prefer to avoid unnecessary repetition.

I was wondering if there is a resource which can make it simple to understand which families of parts use which versions of peripherals. I'm imagining a feature matrix or some such: All F0 and F4 GPIO is GPIOx, but F1 uses GPIOy, ... And/or something which compares and contrasts all the different flavours. I haven't found an applicition note for this. Maybe the data is not publicly available or just doesn't exist.

I have tried trawling the various SVD files with a script to collate such data, but found some inconsistencies in register and field naming.

Thanks.

[waclawek.jan]

While the idea of "portable drivers" in mcu is foolish and fundamentally flawed, the requirement for *porting* code for peripherals (which very incorrectly might be described as drivers) is a very legitimate one. But the requirement for description of differences between IP's implementations in various STM32 models belongs firmly to the Frequently Ignored Requests By ST.

> inconsistencies in register and field naming

Oh yes, that too.

JW

[unicycle]

Foolish? Maybe. It is simple enough to define a portable API for, say, a UART, PWM output or digital input. It seems reasonable to call an implementation of that API a "driver". In my case, it's a self-contained class whose constructor automatically infers which RCC clock bit enables the peripheral, and which IRQ needs to be enabled and registered. This is achieved with run time or compile time lookups based on the base address of the peripheral. I see that Zephyr has a single driver file for all STM32 GPIO. It is full of #ifdefs and is linked with different STM32 HAL implementations according to platform. A bit of a mess, but it does work.

What I'm really after is what Julien FAUCHER referred to in your link. I would like something like an SVD file for each device, but with much richer information. Basically all the tables and whatnot from the various documents could be encoded (e.g. all the AF stuff, which RCC clock bits relate to a peripheral, ...), along with any other useful data such as peripheral versions. Such a resource would allow much more automation and would empower anyone wishing to create new tools or libraries.

I don't know to what extent existing device-specific CMSIS headers are already generated (by vendors), but I have in mind generating a much more information-rich alternative, perhaps even as a build step, which would feed into the driver code. It could, for example, generate the lookups matching peripherals to RCC clock bits. The aim is to ease porting.

A pity ST are apparently not willing to play.

[waclawek.jan]

> It is simple enough to define a portable API for, say, a UART, PWM output or digital input.

Yes, but why. It's been done many times, the last time I checked it was called Arduino.

Oh yes, I forgot the thrill of reinventing the wheel... (no irony, guilty as charged, been there)

Don't get me wrong, arduinoids do have their own place in the grand scheme of things; but it's always, invariably and inevitably a dumbing down all the available options to some common denominator, arbitrarily deemed as "the most useful one". And that's simply wasted time, if you ask me. MIcrocontrollers are great exactly because of the opposite of "abstractions" and "APIfication": because of the infinite number of ways how you can use them.

(Btw. Cube/HAL purports to fulfill the same perceived "need".)

> What I'm really after

I know what you are after. The answer to your titular question is simply "no".

(A small hint: you can look at the CubeMX xml-s. After initial joy - this is it! - disappointment follows. How do I know...)

(And there are *some* appnotes dealing with differences of implementations, at least for RTC and SPI, lazy to look them up now).

> A pity ST are apparently not willing to play.

Play? No, it's damn' serious work. Read, money.

Again, don't get me wrong. It's me who pointed you to the Idea in question, and you'll find me among its signators.

JW

[unicycle]

Actually it was my own independent idea many years ago. I spent some time developing a SQLite database based around the F4 Reference Manual and related documents. I put a great deal of effort into scraping data out of the CubeMX xml files at the time, but these are imperfect secondary sources of information, and are intimately tied to the HAL implementation rather than library-agnostic. It was a good demonstrator, and I used it as the data source for a simple GUI to configure and generate code for my own class library. But that's as far as it got.

It sounds like you might have been down this path, too. 😉

Edit: if you are interested, my pie-in-the-sky ideas are here:https://cppformortals.com/2020/03/05/datasheets-in-databases/

[Pavel A.]

@Community member​ have you seen this? https://github.com/STMicroelectronics/STM32_open_pin_data

[unicycle]

Thanks. I was unaware of that. I recall parsing files like this a while back, but from a Cube installation.