The experiment: turning my huge datasheet library into a smart AI reviewer for schematics and component choices using DeepSeek + RAG.

What initially looked like a simple task that would deliver great results quickly turned into an open field of experimentation. Then again, that might just be my nature.

Reach out to Part 1 here

Distiller harness

The first attempts at extracting parameters into JSON format showed that the harness I applied was too general:

Starting a live experiment: turning my huge datasheet library into a smart AI reviewer for schematics and component choices using DeepSeek + RAG.

Stage 1 - Prototyping

If you’ve moved past blindly soldering other people’s reference designs and you’re now drawing your own schematics, you’ve probably had that moment many times. You stare at your freshly drawn diagram and think: Did I miss something? Are all the parts properly chosen? Can I push to production, or should I double-check everything again?

If you’ve been reading my previous posts, you’ve probably noticed that I love uncovering the hidden secrets behind how devices are built. I guess it’s the spirit of Indiana Jones, but dressed in electronics and reverse engineering. The knowledge gained this way pairs perfectly with practical repairs - I often end up partially (or sometimes completely) reversing schematics of all kinds of electronic devices at my workshop. Over time, you develop a pretty good eye for distinguishing brilliant design choices from stuff that was clearly thrown together on a Friday afternoon.

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”.