For years I’ve been using Microchip’s official Real ICE in-circuit emulator for programming and debugging PIC processors. Then Murphy’s Law struck while I had to download firmware to a fresh batch of boards - something went wrong, and I didn’t even know it yet.

After a few failed attempts, I discovered to my surprise that Microchip had dropped support for the Real ICE in MPLAB X IDE version 6.25 and newer. So now this rather expensive but perfectly functional tool can sit on the shelf and look pretty.

I came up with the idea of expanding the “PID vs ML” article series to seriously investigate what are the real-world possibilities of augmenting classical PID controllers with self-diagnostics capabilities using FFT (unbalanced motor torque, gearbox damage, bearing faults, etc.).

Of course my nature immediately kicked in. Instead of just slapping FFT onto the PID routines, calling it a day and ticking the ‘done’ box like a normal person, I did what I always do - tore the whole thing apart into pieces and started cursing stupid imperfection of the real computer world (as opposed to that beautiful, clean mathematical fantasy we all pretend exists). We’re talking about a finite number of samples, precision butchered by IEEE 754 float/double quirks, rounding errors that sneak in like uninvited guests, and … You think I’m nitpicking again…? Yeah, probably. My nature. But hold my coffee - I’ve got a perfect real-world example coming right up that shows why sometimes being this pedantic actually saves your ass.

You only get one good name

Letting fake chips slip into production can torch your reputation overnight. You end up buried under endless warranty claims nobody pays for and a legion of seriously pissed-off customers.

Not long ago the entire electronics world was choking on component shortages. Legit distributors quoted lead times stretching 6–12 months. Real choice was simple: shut down production for a year… or hunt for alternatives and roll the dice.

Hope you had some fun tinkering with that simple analog temperature comparator from the previous part. That circuit was stripped down to the bone – a classic “how to even do linear signal processing with op-amps” example. But the world doesn’t end at a comparator. You can build 4–20 mA → voltage converters, voltage → frequency, even a basic PID… But today let’s zero in on what used to actually be called an analog process computer.

To kick off our adventure with analog computing systems, let’s start with a bit of history.

It all began in 1947 when John Bardeen and Walter Brattain built the first working transistor prototype using germanium at Bell Labs. Sidenote: in reality, many labs around the world were working on the concept, so it’s a collective achievement.

The jump from bulky vacuum tubes to tiny transistors was a game-changer - it triggered explosive growth in electronics. The next big milestone came quickly: in 1967 Karl D. Swartzel developed the first operational amplifier - an electronic building block that could perform mathematical operations:

As I said in Part 2, I tried to keep it dead simple: how to actually train your own ML model. I know ML purists would call it superficial - but let’s face it: I’m not here to teach you the secrets of deep learning. I want hardware devs to see a real-world way that works on actual silicon – without drowning in theory rabbit holes.
Let’s move on.

From ONNX to C code – let’s see what X-CUBE-AI does with it

Open CubeMX.
Make sure you have X-CUBE-AI installed (the add-on that turns ONNX models into C code – the language the MCU compiler actually speaks). It should show up in the Middleware section. Click “Add network”, name it something like “pid”, switch format from Keras to ONNX, browse to your file, set compression and optimization options, then hit “Analyze”.

As menioned in part 1 I wasn’t in the mood for classic Hardware-in-the-Loop (where the model learns to regulate speed entirely on its own), I took a shortcut. I logged several hundred thousand records of the running PID regulator in different conditions:

• no load
• constant load
• ramping load up
• ramping load down
• and a few cases in between

All done with simple Python scripts dumping values via UART/DMA. Zero CPU overhead on the MCU side.

A few days ago someone casually dropped the line online:
„f%$# PID, that’s good for boomers.”

PID regulation has been the daily bread of process automation for decades. Has something really changed, or are the boomers just stuck in the previous century…?

I’ve been doing electronics for a long time, so that jab hit home. I raised my hand and said: „Challenge accepted. Let’s see.”

test setup

I was already working on a PID regulator for a commercial project. Since commercial projects live and die by price, I picked the cheapest possible MCU that could still do the job: STM32F051 (Cortex-M0, 16 kB Flash). The rest of the hardware: DRV8842 H-bridge driver chip.

In the previous post I described a PID controller tested with randomly generated data in a controlled range. The simulation phase is now complete and the results look promising.

Time to move to real hardware: connecting the algorithm to an actual pH probe.

critical requirement: galvanic isolation

Due to very low signal levels and extremely high input impedance of typical pH electrodes, full galvanic isolation between the probe circuitry and the rest of the system is mandatory. Any ground loop or leakage current destroys measurement accuracy.