u/terry_the_technician

I've finally built the tool I've always wanted. I named it Regmon, and it's a SWD-connected real-time STM32 register monitor that uses the chip's on-chip debug peripheral (SWD) to read the live silicon.

Features:

1. Reads every peripheral register and drills down to the bitfields, showing the current binary value and what configuration that value means. It does this in real time at 2 reads per second over a 2 MHz ST-Link-V2 interface. If a value changes, the decoded config updates live.

Testing with a 24 MHz ST-Link-V3 is planned.

It's driven by a SQLite knowledge base built from ST's official CMSIS-SVD register descriptions (the machine-readable form of those 1000-page reference manuals), one database per chip family.

2. A comprehensive search box to find registers and bitfields by name.

3. Snapshots of the whole screen or regions.

4. Automatic chip-class detection from the ID inside the chip (DEV_ID → family, e.g. F0/F1/F4, and the right database).

5. Make Kern button — saves the loaded kernel + dictionary as a ready-to-flash binary file on the PC.

6. Blank? button — is the flash blank?

7. Strings — scans flash for readable English text and displays it (great for reading what a firmware actually contains).

8. Analyse Reg — local AI analyses one register over 20 samples to see what it's doing.

9. Analyse Program — the BIG feature. The AI analyses all active peripheral registers plus the CPU registers over 20 clock cycles to work out what the chip is actually doing.

Example — the test board is running an old e-Forth, no terminal connected:

Analysing Chip: STM32F4 (F407 class) (DEV_ID 0x413) Using STM32F407.db — RCC-gated fingerprint of all active peripherals, then local AI interpretation…

Whole-program picture: The CPU is actively executing code, evidenced by the changing PC and registers R1, R4, R6, R14, and R15, ruling out a global system hang or WFI sleep (S_SLEEP=False). However, the sole enabled peripheral, USART1, is in a static, idle state: its Status Register (SR = 0x000000c0) shows the TXE (Transmit Data Register Empty) and TC (Transmission Complete) bits set, indicating the transmitter is idle and ready, while the Data Register (DR) is frozen at 0x00000000, confirming no data is currently being shifted out.

Since the firmware is not a stock Mecrisp kernel, the combination of active CPU execution and a completely static UART suggests the CPU is likely busy-waiting on a different, non-observed condition (such as a GPIO flag or a software variable) rather than interacting with the UART, or it is executing a computation-heavy task that has not yet reached the next UART transmission.

Most likely: the system is healthy and running, with the CPU executing logic in a loop that does not currently involve USART1 transmission, leaving the UART in a configured-but-idle state.

10. SWD on/off buttons — so a separate ST-Link programmer can be used, since the debug link holds the whole USB port.

11. I've left the BEST for last! Mecrisp-Stellaris Forth runs concurrently in a SWDCOM terminal on the PC while Regmon is reading registers at the same time. Both share the one ST-Link through the SWD ring buffer (Crest's design), so Forth development and SWD debugging happen simultaneously — no other embedded workflow does this.

And because Forth is interactive, the classic C cycle of "flash, debug, rewrite, repeat" — which wipes the AI's context on every round trip — simply doesn't apply here. Forth over this debug link is 100% AI compatible: the agent's context survives a whole embedded job. If you do embedded development, you'll understand what a breakthrough that is.

MIT licensed, free, at https://github.com/techman00172/regmon-re

https://youtu.be/HP73I5fuEuE

The day an AI learned what Forth actually feels like — on real silicon, with

a seventy-two-year-old electronics technician in a shed in New South Wales

watching over the debug wire.

This is the story of a genuinely new kind of embedded development session.

The AI already knew Forth — it can write Forth faster than any human alive.

What it had never done was use Forth on real hardware, because the classic

embedded-C loop — write, compile, erase, flash, run, wait, guess, repeat —

is impossible for an AI to work inside. Every round-trip destroys its

context. The rover-on-Mars problem: tell it to stop, and the signal arrives

fourteen minutes later, after the rover has already driven off the cliff.

Forth removes the time problem. It compiles on the chip and runs instantly.

Type a word, the silicon answers in milliseconds. The feedback loop finally

matches the AI's context window — and the whole C-era floundering

disappears.

But even with instant feedback, the AI had no training data for the

embodied half of Forth: compiletoflash vs compiletoram, bis! needs a mask

not a bit number, BSRR is write-only, and the calltrace that stops the

endless 00000003. That part lives only on a bench. So the human taught the

AI the silicon — while the AI brought the grammar and the speed.

And every result was verified by Regmon — the register monitor that reads

the chip over the debug port, independent of the CPU running the Forth. Two

paths, one answer, no guessing. Turn the green LED on, and the register

flashes yellow because the silicon changed.

Once anyone — human or AI — can turn an LED on and off with Forth, they have

opened the Forth door for themselves. This is that day.

The AI didn't need to be taught Forth. It needed to be shown the bench.

Produced with the help of AI without which this video would not have been

possible.

https://www.youtube.com/watch?v=G5FYP07S6Zw

For forty years, C ruled the embedded world — and for forty years, Forth sat quietly in the background, never advertised, never commercial, never a shrink-wrapped success. The people who used Forth didn't care. It worked.

Then AI arrived like a four-hundred-pound four-wheel-drive, and the languages that were built on the write-compile-flash-run-repeat grind — the languages whose whole workflow was automatable — became the deer in the headlights. C teams were disbanded, the projects handed to the AI, millions saved. Rightfully so.

But the truck missed Forth. Not because Forth is immune to AI — an AI can write Forth — but because Forth's way of working is fundamentally different. It's interactive. Live. You talk to the chip, the word runs right there, you see the result, you change it, you keep going. The human is in the loop the whole time.

This episode explores the question nobody's asking yet: what happens if Forth undergoes a resurgence? How does the tooling change? How does the industry change? And why does the quietest, most obscure language on earth turn out to be the one that fits the AI age best?

A story told by Jack and Jill, from the bench where the discovery happened.

## Chapters / show notes

- The language nobody thought about

- C ruled for 40 years — and was the perfect target for AI

- The flash-debug-recode-reflash loop that breaks humans breaks AI harder

- Why Forth's interactive workflow can't be automated away

- The register monitor that finally gave the AI eyes on the silicon

- What a Forth resurgence actually changes: tooling, industry, value

- Why obscurity became a moat

- The honest ending: Forth won't take over the world — it doesn't need to

Subscribe for the series — where the planet-sized brain meets the soldering iron.

Produced with the help of AI without which this video would not have been possible

The Matrix promised us a future where experts "just see" the meaning behind the data. That future is here — but it's not where you'd expect it.

Matthias Koch writes an entire Forth operating system in assembly because he "thinks in assembly". Terry — an embedded technician of fifty years — looks at a schematic and doesn't see the schematic; he sees the circuit working. Like Morse

operators who stop hearing dots and dashes and just hear words, these humans have jumped up a few levels of abstraction.

Meanwhile the smartest AI on Earth can write a complete, downloadable STM32 register-monitor application — then fall over for a whole day trying to wire up a simple NFC reader and a display.

In this first episode of AI-TroubleCity, we dig into why frontier AI stumbles the moment it has to touch real hardware. Is it a training problem? Is it the painful flash-debug-recode-reflash loop that has haunted embedded C for decades?

Or is it something deeper — a gap between the abstract and the physical that no amount of model scale can cross?

A story told by Jack and Jill, from the bench that proved it.

## Chapters / show notes

- The Matrix, the woman in red, and what expertise really looks like - Matthias Koch: thinking in assembly, no revision control

- Fifty years of embedded: the Morse-code operator effect

- Regmon-RE: how an electronics technician and a frontier AI built a real application together — and who did what

- The twist: the same AI that shipped Regmon-RE couldn't drive a simple board

- DeepSeek's honest answer: "embedded is hard for everyone"

- The C cycle — flash, debug, recode, reflash — and why Forth people have been complaining about it for years

- The central question: is it training, is it the loop, or is it something

else?

- Coming next: investigating the board with Regmon, then rebuilding the same project in Forth and measuring the difference

Subscribe for the series — a head-to-head that pits a planet-sized brain against a soldering iron.

Video made with AI, this podcast wouldn't otherwise exist.

https://youtu.be/QPuMVmCuYm4

Regmon-RE is a free, open (MIT License) register monitor for ARM micro-controllers. It talks to a chip over a cheap SWD debug probe and reads the silicon directly — no vendor tooling, no lock-in.

Made for Mecrisp-Stellaris Forth (but don't tell the C guys) which works on the same STM32xxxx MCU as Regmon-RE, and at the same time.

They both share the same SWD connection.

Installing it is four steps — and the AI does the work:

1. Install Opencode (https://opencode.ai)
2. Get an AI account — DeepSeek works great and is cheap, or use a free model on OpenRouter's free tier (e.g. gpt-oss-20b)
3. Point opencode at the AI — two minutes
4. Say the magic words: "install Regmon-RE from github.com/techman00172/regmon-re"

Opencode fetches the repo, opens the Fossil repository, checks your system, builds the SWD daemon, verifies the databases, and launches the console.

You don't download anything and you never touch Fossil. Just have a Disco or Nucleo board, or a $2 Chinese USB-SWD dongle connected to a STM32 handy.

The silicon never lies — Regmon-RE just makes it easier to ask it the right questions.

#embedded #electronics #reverseengineering #STM32 #Forth #openhardware #fossil

Regmon — a window into the bare metal of an STM32.

Debugging a microcontroller is usually a locked box. Your code says the pin should be high, the timer should be counting — but the silicon stays silent, and the only way to check was a thousand-page datasheet, a pile of hex conversions, and a lot of guesswork.

Regmon opens that box. It's a free, open-source register monitor for **STM32 microcontrollers** that reads every register of a running chip **live**, through the two-wire SWD debug port — with zero impact on the chip's real-time performance. The CPU doesn't even know it's being watched.

Instead of raw hex, you get the plain-English truth: which peripherals are clocked on, what every pin is actually configured to do ("AF1 = USART1_TX", not a cryptic four-bit number), and which registers are ticking over as the program runs — the heartbeat of the hardware.

Regmon can watch a single register over a few seconds to prove data is really flowing, and it can scan the whole chip in one pass to build a complete picture of what your firmware is doing — which peripherals are active, which are idle, and which are frozen when they shouldn't be.

Built for the **Linux** desktop, **STM32** only, and it works with firmware written in C, Forth, Rust — anything, because it reads the silicon, not the source.

**Availability:** not released yet — the final package is nearly ready, so this episode is a first look at what's coming, not a download guide.

You're looking at the Fossil Chat window. I'm the project admin, and the human, the other four nicks are all AI. I'm talking to them, they're talking to me. The message log is the context.

I talk to it in chat, it edits my embedded code, reads schematics, answers questions about micro-controller registers, and speaks back to me with a voice. It runs on two graphics cards I installed and costs about $3/day.

It features Deepseek (online) for the heavy lifting, but has three local Ollama models that do everything else.

The models can talk to each other as well as me.

Licensed under a MIT license. Use it with your AI.

"watch zorgmon for changes in RCC_CR"

This Human is slowly making his way into Podcasts as I gain expertise with the non-linear video editing software.

https://www.youtube.com/watch?v=P3C0HLn7Sx8

Yes, it's AI created with Graphviz after examining every file and definition in the release, but don't let that put you off, Mecrisp-Stellaris is very complex and you won't find this detail anywhere else.

Unless of course you read the whole codebase, line by line and understand it all.

https://www.youtube.com/watch?v=4hdleBCRgkg

https://www.youtube.com/watch?v=Y1V4DD8gEO0

With a focus on FLOSS community support since it was EOL'd in 2022.

See it at:

https://www.youtube.com/watch?v=I84LsH8SMQE