Plans?

[jmunt]

Hi mate,

Would be good if you could provide any plans/thoughts you currently have on this project regarding further automation and structure changes to reduce management burden.

My thoughts at the moment:

ld: If you have no better plan with the mcu specific ld files, I'm thinking to move it into a generate_ld.py script where the variables are still manually entered but at least they'll all be in a compact table within one file that's easier to bulk add/edit/review.

device_headers: As much as I like flat file structures, it's going to become unwieldy. If only because sort by filename isn't sorting it nicely, possibly Windows specific. I'm thinking to go 2 deep to clean this up, eg: device_headers/core device_headers/STM32F0 device_headers/STM32G0 etc

Makefile: The "Define target chip information" section needs a cleaner solution. I'm not much help being a Make newbie. Hoping you have a plan to save me from learning Make (or ditching Make, or generating the Makefile)

[jmunt]

Sorry, just saw that you already noted that you want to generate everything from SVD files. This stuff is all new to me, sounds great but then I read that:

• Sourcing from Keil is problematic for recent MCU's (update delays).
• ST has more recent versions for STM32 specifically but apparently more buggy than their headers (and possibly not easily accessible? about to go looking through cubemx's files)

[WRansohoff]

Hi, sorry for the late response.

I've gotten kind of sidetracked from build automation by other projects. This sort of structure works well enough to quickly start a new project with a bit of file modifications, but it is a long way from a 'one-click' sort of solution.

Using raw SVD files to make the linker scripts and vector tables would be nice; I'd probably use Rust instead of Python for that, since there are a few crates (like svd2rust) which can import those files into data structures which are nice to work with. There might be Python libraries for that too, but I haven't seen any.

The vector tables should probably just go in RAM; it's convenient to put all of the interrupt vectors in Flash and forget about them, but it slows down interrupt latency. You only need to define the first several entries, then the application could configure the SCB->VTOR register before initializing any interrupts.

I try to avoid the HAL in bare-metal programs, but it looks like a fine way to bootstrap a project, and the CubeMX planner is a good way to plan pin mappings when you're designing a PCB. I just feel like it obscures how the peripherals work at a low level, and I like understanding that.

As for Makefiles, it would probably be more sustainable to use an IDE like PlatformIO or the chip vendor's fork of Eclipse. But I like simplicity, and it's nice to just copy a file and make a few changes.

Overall, the project structure is more suited for tinkering and learning than commercial applications.

[jmunt]

Thanks for the response.

If I use CubeMX or PlatformIO do I get the vector table in RAM solution by default?

I'm not expecting anything more from you, and I'm pretty happy with my setup that's come out of this template! Hopefully I can make it work long term without too much effort, maybe I can't. There's clearly some risk in my lack of knowledge still but I can live with that. My time isn't overly valuable these days, I'm kinda retired and just messing around, working on something I plan to commercialise at the moment but I'm on a pretty loose project timeline with only myself to answer to if I make bad choices.

This vector table in Flash vs RAM inefficiency issue is just another example of learning as I go, I wasn't yet aware of the issue, hopefully it won't be too difficult for me to DIY the improvement, I guess time will tell. I'm on schematic/PCB design at the moment, it will be a few weeks before I even start to look into it.

[WRansohoff]

That's a good question; unfortunately I don't use an IDE very often, but if they let you run a raw project without any 'hidden' startup code, that probably won't include relocating the vector table. I would guess that CubeMX must have an option for doing it, but I'm not sure if it would be enabled by default.

It doesn't take much code to move the vector table in your program, though; I wrote a little bit about working with RAM on a Cortex-M7 chip here, and the first section goes over how to put a vector table in RAM.

Good luck with your designs! If you're new to making an STM32 board, don't leave the BOOT0 pin floating and be sure to double-check the "pin 1" locations if you solder them yourself :)

[jmunt]

You've suckered me into having a quick look =)

From what little I gathered it seems that putting the vector table in Flash is typical for IDE's, at least for low to medium performance MCU's, and that immediately makes me fairly unconcerned about this. Unless I'm missing something the possible inefficiency is tied to Flash wait states, making it a (possible) issue only for "high" CPU clocks. At high CPU clocks you also have to balance the issue against the lower interrupt latency you already get just from shorter clock periods. Plenty of applications where this still matters, but in my little world it's going to be pretty niche.

Apparently there is another benefit of moving both the vector table and some/all interrupt routines to RAM in order for them to not be blocked by Flash writes. Hard for me to imagine many use cases where that's really all that important though, not a whole lot of wiggle room to gain there before you'd be opting for an MCU that's better designed to deal with this via dual Flash banks.

Might have a play around with this some day if only out of interest. Seems the Cortex M0/M0+ doesn't have VTOR so might instead need to switch 0x0 to point to RAM instead of Flash after boot.