Bare metal STM32 programming

Related to the the forum.
dannyf
Posts: 25
Joined: Sat Jul 04, 2020 7:46 pm

Re: Bare metal STM32 programming

Post by dannyf »

the cubemx code generator
I guess there are differing flavors of "bare metal".

racemaniac
Posts: 8
Joined: Wed Dec 18, 2019 6:53 pm

Re: Bare metal STM32 programming

Post by racemaniac »

dannyf wrote:
Fri Aug 28, 2020 12:38 am
the cubemx code generator
I guess there are differing flavors of "bare metal".
Picking apart the generated code and writing your own version of manually configuring all the peripherals & DMA?

It really helped me when going bare metal. Interpreting the datasheet & getting every step right was annoying. Having the CubeMx code as a starting point really helped a lot :).

dannyf
Posts: 25
Joined: Sat Jul 04, 2020 7:46 pm

Re: Bare metal STM32 programming

Post by dannyf »

coding to the datasheet may sound challenging initially but it is not that hard. it allows you to migrate away from vendor libraries and develop a better understanding of the hardware -> the essence of "bare metal programming".

racemaniac
Posts: 8
Joined: Wed Dec 18, 2019 6:53 pm

Re: Bare metal STM32 programming

Post by racemaniac »

dannyf wrote:
Sun Aug 30, 2020 10:48 pm
coding to the datasheet may sound challenging initially but it is not that hard. it allows you to migrate away from vendor libraries and develop a better understanding of the hardware -> the essence of "bare metal programming".
Yeah, and the generated code just adds to that documentation :). I mean, we were originally talking about "bare metal programming" using libmaple that also already maps all the registers etc... When learning bare metal programming, i started with the datasheet approach, which really sucked, getting I2C running on DMA took me days of searching and frustration. (i was very new, so that's probably also a reason), a single mistake is fatal. Later i used the generated code to get started from, which is both a good example of all the datasheet info combined, and a working example. If my own code didn't work, i'd compare register values, and quickly find the things i was missing :).
I'm not saying that generating cubemx code & using that is bare metal programming. I'm saying you can do great bare metal programming using its register mappings & the generated code as an example. But the generated code is very inefficient code. It always assumes nothing is set up when you initialize a peripheral/dma. So if you know one dma channel is always doing the same type of transfers, you can greatly optimize starting the transfer after the first setup, and throw away a lot of bloat :). And that requires bare metal programming, getting to know every register, know which things you need to set, vs which are still correct :).
If i'd do some bare metal programming in libmaple for a peripheral where there aren't any examples yet, i'd start generating the cubemx code for what i want to do, and use that as a working example/documentation, and together with the datasheet, i'd get anything working in a single evening :).

MGeo
Posts: 21
Joined: Thu Dec 19, 2019 10:29 am

Re: Bare metal STM32 programming

Post by MGeo »

Nothing stopping you, go ahead and do it.

The challenges I've run into with bare metal (which I think of as CMSIS / LL / c and asm register access to hardware as opposed to using Arduino higher level functions) is name collisions, multiple definitions and hard coded interrupts in core implementations. It has forced me into undesirable workarounds and sometimes help from our resident hero fpiSTM with core mods.

With libmaple and target F1 hardware are getting to be end-of-life I would recommend a more current core or just going direct to using VSCode/CubeMX/gcc. A cheap hardware debugger to track register manipulations and logic analyzer to view multiple pin outputs are super useful as well.

racemaniac
Posts: 8
Joined: Wed Dec 18, 2019 6:53 pm

Re: Bare metal STM32 programming

Post by racemaniac »

MGeo wrote:
Wed Sep 16, 2020 9:07 am
Nothing stopping you, go ahead and do it.

The challenges I've run into with bare metal (which I think of as CMSIS / LL / c and asm register access to hardware as opposed to using Arduino higher level functions) is name collisions, multiple definitions and hard coded interrupts in core implementations. It has forced me into undesirable workarounds and sometimes help from our resident hero fpiSTM with core mods.

With libmaple and target F1 hardware are getting to be end-of-life I would recommend a more current core or just going direct to using VSCode/CubeMX/gcc. A cheap hardware debugger to track register manipulations and logic analyzer to view multiple pin outputs are super useful as well.
Indeed :)

When doing low level stuff, i was really happy i bought a license of VisualGDB. It allowed me to import a cubemx project into visual studio, and then continue developing in that awesome IDE. The functionality that VisualGDB brings is great. It knows all the registers of all STM32's, and supports pretty much any debugger. I used an ST-link V2 to program & debug the STM32, at a breakpoint you can view all the registers by name, you can take any piece of c(++) code, and immediatly go to the disassembly to see what it was assembled to (had some fun learning some of the instructions the stm32 has, and then see if the compiler was using them), etc... I usually avoid not open source platforms a bit, but as microsoft & visual studio are currently on a course of being more open, open source & accessible rather than the other way (and i use it professionally too), this really was an awesome option :). And VisualGDB is worth the money imo :). Guys making such great tools really earned it :).

dannyf
Posts: 25
Joined: Sat Jul 04, 2020 7:46 pm

Re: Bare metal STM32 programming

Post by dannyf »

most of the code you find will be developed against CMSIS and a set of vendor header files. so I would encourage you to at least try to align there.

Post Reply

Return to “Ideas & suggestions”