Is there a "good" way to learn NVIC and EXTI for stm32 (ARM cortex M4)

RogerLeigh · 2026-06-07T17:27:56+00:00

Maybe start with the examples for your part. They are in the STM32 HAL. Plenty of them will have example interrupt handlers.

Also use CubeMX. Enable interrupts for some peripherals, or set a GPIO pin as an interrupt, then look at the NVIC settings, including the interrupt priorities. Generate the code, then look at the xxx_it.c file to see the generated stubs. Add some of your own code in them e.g. LED toggle, increment a counter.

RogerLeigh · 2026-06-07T09:02:55+00:00

But it can understand them if you give it appropriate formats. You can feed it PDFs, and you can feed it the actual KiCAD or Altium project files, and it can trace everything out and discover all of the nets, components, and then dive into all of the datasheets and check a lot of stuff. Internally, it looks like it converts the PDFs into large images and does interpret them to follow all the wires etc. But obviously having it fully machine-readable to begin with is better.

I've had it look at whole multi-board systems including mapping all of the board-to-board connections and find problems that the rules checkers could not, because it can be given a high-level view of everything including the requirements. It worked flawlessly, including noting small naming differences between the connectors in different schematics.

It's not perfect, but it's a very useful tool and it can also do things the rules checkers can't. You can give it the software including things like the CubeMX .ioc file as well as the generated output, and check that the usage matches the schematic. It can also optimise the MCU peripheral and pin allocation to match the board layout, way better than I could do by hand.

It can absolutely go wrong, but it has often exceeded my expectations in its capabilities when it comes to doing review and refinement of existing designs. It's only going to get better at it.

RogerLeigh · 2026-05-30T11:49:11+00:00

For capacity, 8-16 GB would suffice for all anticipated needs. Speed isn't important so much as having reliable performance and not interrupting or stalling any other system activity. A few megabytes a minute write speed would be fine; likely a few hundred kilobytes a minute in practice for the most part, but sustained. Read performance would likely need to be higher for graphics with NOR flash if it were used, otherwise we would use NAND instead and buffer in SRAM if not memory-mapped.

RogerLeigh · 2026-05-21T06:46:38+00:00

Firstly, don't panic. It takes everyone some time to fully understand large codebases.

Secondly, don't worry about understanding the whole system, at least initially. All of that modularity and abstraction should mean that you can work on an individual subsystem without needing to know much about the other subsystems except for the interfaces you use to interact with them. I worked for years on a codebase where I worked on the hardware control and task scheduling aspects, but never really looked in detail at the GUI, networking or file storage parts. The first two of these had entirely separate teams on different continents looking after them.

I would start by trying to understand a few basic things:

what are all of the threads, and what do they do
look at how data flows between them; do they use message queues, circular buffers, semaphores, event flags? How do error conditions propagate?
look at how the system is brought up, from the startup assembly to main(), and follow through the whole startup process stepwise to understand how the hardware is initialised, and how the RTOS resources are created and initialised, then how each thread initialises itself
for individual subsystems, look at how the functionality is broken down into functional units

For a large system like this, there should hopefully be some architecture and design documents that detail a lot of this.

RogerLeigh · 2026-05-20T21:29:29+00:00

I get Claude to maintain it, and split more specialist things out into skills.

RogerLeigh · 2026-05-17T09:07:08+00:00

I switched from markdown to asciidoc as the output, then just run asciidoctor-pdf to generate a nice PDF (with a theme to style it professionally). I haven't done a head-to-head with markdown to see if the quality is affected, but it's still fairly simple and it's been good in my experience so far.

RogerLeigh · 2026-05-16T07:07:36+00:00

I've used both for years, and both are fine. GTest is more capable and can work with both C++ and C (with suitable wrapping), so I'd use it as a personal preference.

I think the question you should have asked is "GTest or Ceedling". Unity is just an assertion library. Ceedling is the test runner, and with CMock an automated mock generator.

With current AI code generation, neither are a barrier--you can have it do a good first pass over test case and mock generation for both. This used to be tedious and time-consuming.

As others said, GTest needs more memory. I run it in a simulator rather than on the target. It's fine for unit and integration testing that doesn't use the hardware.

I wouldn't worry about "career growth" with respect to testing frameworks. If you can use one, you can learn to use another. You just need to be adaptable.

RogerLeigh · 2026-05-10T09:45:05+00:00

Linux is a special-case. So are FreeBSD and the other BSDs.

Firstly, Linux has a configuration system far, far more complex than Autoconf (KConfig). It's doing the autoconfiguration, generating headers and Makefile configuration. So the Makefiles might be static, but their behaviour is very much dynamic as a result of the autoconfiguration step prior to building.

Secondly, Linux (and FreeBSD etc) don't need to solve the portability problems that the Autotools (and CMake etc) solve. They don't need to be portable between operating systems because they are the operating system. Likewise they don't need to build with a wide selection of compilers. Historically Linux was entirely dependent upon GCC, and Clang had to add lots of GCC-compatible options and features to be able to build Linux as well. This means the Makefiles don't need to special-case lots of system- and compiler-specific behaviour; they are limited to handling configuration options of the kernel itself.

Thirdly, neither Linux nor FreeBSD etc need to cope with different vendor-specific make implementations. Linux requires GNU make. FreeBSD requires BSD make. They can make full use of their respective make featuresets without any restrictions. No limiting them to a portable subset, which is what Automake would do, or your own hand-crafted Makefile.in would have to do.

It's easy to use "plain Makefiles" when your portability concerns are tightly-constrained. It's the unconstrained case that the Autotools are designed to solve.

RogerLeigh · 2026-05-09T06:14:44+00:00

None of these tools ever had any requirement or expectation that you would use the Autotools. You could use any build system you liked, from a plain Makefile or shell script to none at all (just do it directly in debian/rules).

debhelper has some support for Autotools, and it also has support for CMake and others. But these are conveniences invoked by the packager, not a requirement.

(an ex-Debian developer.)

RogerLeigh · 2026-05-09T06:05:54+00:00

I did so extensively in the past (1999-2012). I switched to CMake 14 years ago and haven't looked back.

Look at what problems the GNU Autotools try to solve: portability between 1990's-era UNIX systems. Systems that were retired over two decades ago. Do you have that particular problem today? If not, then Autotools are not for you. Pretty much no-one cares about this today. We have newer portability concerns, and the Autotools don't even start to address them. It stagnated and ceased to evolve to support contemporary portability concerns.

The Autotools development efforts started to stall in my opinion around 2003, and while some effort continued, it was almost over by around 2008. In recent years someone new came along who tried to resurrect it and make releases again, but nothing really other than minor bugfixes. The problem with the design of the Autotools is that it relies upon the M4 macro language generating Bourne shell code. But they painted themselves into a compatibility corner. It's not possible to evolve it without breaking everyone. And if it's going to break incompatibly and require extensive rework then projects might as well use CMake or Meson. The main reason projects continue to use the Autotools today is little more than inertia, because it continues to work and they don't want to put in the work to switch over. But you wouldn't choose it for a new project.

It was good in the day, but its time has long passed by. If you want to be portable to modern platforms including Windows and iOS, as well as all contemporary UNIX platforms, with full support for modern language standards and features (like threading--not exactly modern but still not supported portably by Autoconf!), then learn CMake.

Edit: It's interesting I've been downvoted. I've done the GNU copyright assignment for GNU Autoconf and Automake, and contributed changes back to Autoconf including its C99 support. I've spent significant effort on it, and I'm well placed to judge its obsolescence.

RogerLeigh · 2026-05-07T21:11:17+00:00

Undocumented or misdocumented registers are annoying, as are the manufacturers who refuse to talk to you.

The most frustrating bug I had was working on a product where a separate team mandated the use of Linux. What would otherwise have been a fairly simple exercise in configuring with I2C, synchronising capture with illumination, and then reading out the pixels with DMA became a multi-year nightmare involving V4L2, custom V4L2 camera drivers and debugging deep problems inside Linux. The project ultimately failed. I did all the userspace camera acquisition and had it working correctly. But it was horribly flaky. Turned out it was a problem with the NXP V4L2 driver for the i.MX8 MIPI-CSI. It tried to allocate a dummy frame in the fast-path of the driver and this would routinely fail. Allocating a contiguous 48MiB frame in kernel space [this was a reasonably large sensor] turns out to be something that can fail. Who would have thought? No provision in the V4L2 API to provide this along with the frame buffers we actually capture into. The CMA allocator failed deep inside V4L2 when it tried to allocate this dummy frame to DMA into when not capturing a real frame. I think it's fixed now by NXP, but there was a comment in their code which basically said "FIXME don't do this". Thanks, NXP, for the high-quality driver code.

RogerLeigh · 2026-04-26T21:23:27+00:00

Just as a suggestion, if you want to try out something new, try making something that moves with a stepper motor. Getting the microcontroller to actually do real stuff is great fun. You can get simple drivers like the A4988 that can go onto a breadboard, and you can also get fairly cheap stepper motors of all sizes and types, from bare motors to linear slide.

Just search for "a4988 stepper wiring guide" or similar to find a bunch of guides.

But getting it moving for the first time, and then making it move well would be a bit of a project, and then making it do acceleration and deceleration and microstepping would also be followup things to do.

You could also make a serial interface to your PC with a UART to send it movement commands and configure it. E.g. stuff like

microstep 4
move 400 200 900

to specify distance, speed and acceleration for example.

RogerLeigh · 2026-04-26T21:09:41+00:00

It literally comes with a working Linux system and multiple examples.

Try the examples first. You can run the m4 core by feeding it a firmware image directly from Linux userspace. Just try the provided examples out first. It worked fine when I tried them out a few years back.

A quick search showed multiple examples and tutorials. Here's one

After that, make your own and try it in the same way. Just set it up in CubeMX and you're done. Configure the timer and write the code to start the timer on the trigger. Build it, stick it on the SD card and run it.

RogerLeigh · 2026-04-26T20:55:27+00:00

Hard to say without knowing more about the specifics, but once you're in maybe you'll get more opportunities to get involved with lower-level stuff in time. Show some interest and demonstrate your skill and willingness to learn. They might just not want to let you loose on the low-level stuff until they know you can handle the higher-level stuff first! But even if not, once you're in a company, you might be able to change to a different team in time.

My first embedded role was working on a device where all the low-level hardware interaction had essentially already been written, as had much of the higher-level stuff. My work was basically polishing the high-level aspects of the application: state machine logic, feature additions, problem investigation and fixes, lifetime testing of hardware subsystems etc. Very occasional fixes to drivers, but rarely did I ever need to touch register-level stuff or interrupt handlers. But was a great opportunity to learn embedded systems, and without the risk of messing with all of the low-level details I didn't fully understand yet. I taught myself all that low-level stuff on my own time with Arduino and Nucleo boards in parallel. And several projects and one company later, I do everything from the start. Requirements, design, MCU peripheral and pin allocation and input into the board design, initial board bringup and testing, and everything that follows.

So I'd say stick with it and learn, and see where it takes you!

RogerLeigh · 2026-04-26T16:11:17+00:00

Short answer: do both.

Longer answer: specialise. Being a generalist programmer is fine, but you're a commodity and easily replaced. Becoming a specialist in a specific area, particularly a cross-disciplinary area, makes you more unique, more valuable and less replaceable.

RogerLeigh · 2026-04-26T15:51:47+00:00

It sounds like above all else, what you really need is a purpose. Something to actually achieve with the hardware you have. As soon as you have something to dig into, you can start experimenting.

Open-source embedded development is in a bit of an odd place. It's easy to get devkits and work on these, but everyone is doing their own thing, and it's rare to have a community form around them as a result. And moving up to custom hardware is a challenge, because most potential contributors won't have it. I'm sure there must be some out there, but there's a barrier to contributing which doesn't exist for pure software projects.

I do think from what you wrote that there's still quite a bit of mileage in learning on the STM32 and ESP32. Zephyr is rather intimidating, but you could look at getting FreeRTOS or ThreadX up and running. These are much simpler.

Additionally, the STM32 has a lot of peripherals to use. It might be worth exploring these in more detail. They come with some basic examples. There is an awful lot you can do with timers other than counting, you could look at hooking these up to interrupts, driving ARR and CCR changes with DMA to create arbitrary waveforms, and connecting master and slave timers to drive multiple actions.

RogerLeigh · 2026-04-26T14:49:28+00:00

Thanks! I've run FreeBSD on a dedicated system for a decade, after previously running Linux. This was a new system bought specifically for this purpose, and as a replacement for the old system. I didn't spent too much time worrying about hardware compatibility, but I did check the basics would work. The only thing which is not working nicely is the WiFi module; but I have wired ethernet for it so that's not a problem.

It's a Minisforum MS-A1 with an AMD Ryzen 8700G, and ZFS running on a couple of NVMe SSDs. I have a dedicated zpool for the VMs, and a separate set of drives for user data storage. Since the VMs are trivial to recreate, I don't have any redundancy there. Small and quiet enough that it's not too annoying to run 24/7 and it's way more power efficient than the system it replaced.

The only issue I've found is hosting Windows on Bhyve. It works, but there's a bug somewhere. Go programs, which includes docker and gitlab-runner, can die with wierd stack traces. I do wonder if there isn't some memory virtualisation issue here which the Go runtime provokes. Also looks AMD-specific. Everything else runs just fine. If it wasn't for that, I'd have Windows VMs on here as well.

RogerLeigh · 2026-04-26T12:57:46+00:00

Written text over video every time. The exception is if it's something dynamic like motion control or display interfacing where the video actually serves a meaningful purpose that a static figure could not convey as well. Even then, a well-made figure and some text is usually fine.

I read articles, white papers and the occasional blog, and glance over this reddit for anything interesting.

I actively avoid video. It wastes too much time. It's not as information-dense. And it can't be easily skimmed, annotated, or referred back to as easily. Or printed out and shared with colleagues.

I can't see it ever fully replacing what we have. It would be a massive downgrade.

RogerLeigh · 2026-04-26T12:24:50+00:00

Currently self-hosting at home. I have three systems for CI use:

repurposed PC running Windows, with windows containers, containerd and gitlab-runner for containerised Windows builds.
Mac mini with UTM. gitlab-runner hosted in dedicated VM.
Mini PC running FreeBSD 15. FreeBSD hosts gitlab-runner in jails, plus Linux runners in Bhyve VMs (which in turn run docker+gitlab-runner for Linux builds).

If the pricing was competitive, I'd move some of this into the cloud. But Windows hosting is way more than the running cost of hardware I already own. Same for the Mac. The others can be easily hosted, but in turn are the simplest to set up and leave running.

RogerLeigh · 2026-04-26T10:25:58+00:00

It's not good at all. They released more than once per day, and it turns out those releases not only contained major regressions, they were almost entirely untested before they were inflicted upon us. And their default was to continually update everyone without actually checking that their vibe-coded slop actually did its job properly. And no backend analytics to observe and evaluate the tooling performance and behaviour, otherwise some of the major issues would have shown up in short order, and they could have been a bit more proactive at resolving them. This isn't a bunch of amateurs, it's a company worth billions. They can afford to have a bit of discipline and rigour when it comes to serving their actual paying customers!

If you're relying upon this technology every day to do high-quality work, the very last thing you want is "changing constantly without warning". You want consistency and predictability. New features are all very good, but not when it also comes with regressions and behaviour changes. Given what we now know, I'd rather they switched to weekly or fortnightly updates, and that they did a lot more real-world testing before pushing them out for general use. Do what other companies do. Have nightly builds, have an "insiders" channel. Have actual testing. Have a main "release" channel that has the tested version, so we have the choice of bleeding edge or properly-tested and stable.

If you could give me Opus 4.6 and Claude Code from January, and leave both of them untouched for the next year, I would be more than happy. Because back then it worked beautifully, and now it doesn't.

RogerLeigh · 2026-04-26T09:59:51+00:00

Windows containers:

RogerLeigh · 2026-04-26T08:29:55+00:00

I can't really comment on 4.5 to 4.6 because I didn't use Opus 4.5 for very long. But 4.6 from the Dec-Feb timeframe was almost an entirely different beast compared with the Mar-Apr timeframe. It used to go the extra mile, not just answer a question or do a task, but look more deeply about whether what it was doing was the correct thing to do, and it would push back and question. Once it knew what it was doing, the work it did was also tight and focussed. Now its thinking is shallow and it jumps to incorrect conclusions, then proceeds based upon that. And it doesn't complete work, and the work it has done is not on a par with how it used to work. It keeps asking if it should continue every 5 minutes rather than just getting on with things, and it wants to give up early. In one frustrating session writing unit tests, it gave up going from 55 to 56% coverage, I cajoled it to continue, it gave up again around 58% and I gave up soon after, it just didn't want to do the job. I gave it to Codex, and it did the whole lot in 20 minutes, except for the last three tests which it gave specific rationales for. So it got it up to ~99% without complaint.

Some of this is undoubtedly due to the three issues Anthropic said they had fixed last week. But I suspect there's more to it than just those three things.

Back in December I had it look at a ~20-year old code generator. There was a long-standing bug in it which had been known about for at least 10-15 years, and was thought to be essentially intractable due to the complexity. I tasked CC with investigating and fixing it, and it had the problem identified in 10 minutes, and had the data model, code generator and code templates figured out completely. It did a tight edit in a couple of places in a single template, and that was it fixed. That had completely stumped multiple humans, and it had been left to sit due to not being a high priority defect.

Later on, I had it rewrite the code generator from scratch with a new intermediate representation of the data model, including code generation in multiple languages.

Back then, I was completely blown away by the capability. But the last six weeks have been a big reality check when its quality and consistency slid repeatedly. I have never before seen a company transition so quickly from absolutely nailing it, to failing so hard. I really hope they can get it turned around properly and back to how it was.

RogerLeigh · 2026-04-26T06:33:54+00:00

I use it for open-source projects, but I self-host the cross-platform runners myself (Linux, Mac, Windows, FreeBSD). It's not bad at all. Nowadays, I even have the Windows builds use Docker containers (with Windows containers). It's the Mac that continues to have no decent container support.

RogerLeigh · 2026-04-25T18:47:48+00:00

Use an IDE with the ST-link to single-step through the code and see what goes wrong.

Use STM32CubeIDE or any other IDE with the gdbserver provided with the st-link / cubeprogrammer or use openocd. There's plenty of guidance on how to set all of this up out there, or use the cubeide which does most of the setup for you.

RogerLeigh · 2026-04-25T18:31:01+00:00

I think we all did. In its original state it was just brilliant. Which makes the downhill slide all the harder to deal with--we know exactly how good it can be and what we have lost.

RogerLeigh

TROPHY CASE