2 September 2026 · Bharat Raj

Code that reviews its own wiring

Ask any capable model for an Arduino sketch and you'll get one. It will compile. The variable names will be sensible. The comments will be helpful. And none of that tells you whether it matches the board on your desk. Compiling proves the grammar is right. It does not prove the firmware and the wiring describe the same physical object. That second question is the one that costs you an evening, and it is the one Soldr is built to ask.

Compiling is not the same as correct

This is the gap almost nobody talks about. A sketch can compile perfectly and still be wrong in ways the compiler has no opinion about. It can use a pin that does not exist on your board's package. It can use a real pin, but not the one your wiring diagram says the sensor is on. It can assume 5V logic on a 3.3V part, or drive a motor from a GPIO that cannot source the current.

The compiler checks grammar. It does not check that the code and the diagram agree.

So we check that specifically

When Soldr generates firmware, it does not just produce a sketch. It produced a pin plan first — an assignment of which part sits on which pin — and the wiring diagram is drawn from that plan. So there is a question worth asking that has a definite answer: does the code actually use the pins the plan assigned?

When it does not, here is what you get, verbatim:

"the firmware does not use the pin we assigned to the Rain Drop Sensor Module (GPIO3). The wiring diagram is generated from that assignment, so the schematic and the code will disagree — rewire to match, or ask me to regenerate against your wiring."

Read that again, because the important part is the last clause. It does not just flag a mismatch. It tells you which two artefacts disagree, why they disagree, and two ways out. That is a message you can act on at your bench in thirty seconds, instead of an evening spent wondering why GPIO3 does nothing.

The same discipline on pins we do not know

The strongest version of this is not a correction at all. It is a refusal:

"I don't have a verified pinout for the Wio Terminal. I can still compile for it, but I won't guess pin numbers at you — a wrong pin you have no reason to doubt is the one mistake here you can't recover from. Tell me which pins you've wired and I'll write the sketch against those exactly."

And when we do have a pinout, we say where it came from:

"Pins came from seeedstudio.com, read 2026-08-14. I extracted them from the vendor's page — I did not measure your board. Check them against your silkscreen before you wire anything."

A sourced pinout with a date on it is a different object from a plausible-looking number. One you can verify. The other you can only trust.

What we are not claiming

Not that nothing gets through. A check finds what it was built to find. Ours will miss things, and when we learn about a miss we widen the check.

What we are claiming is narrower and, we think, more useful: the firmware and the wiring are compared against each other, and where they disagree you are told, in language that names the pin and the part. Most tools do not compare them at all — which is why the mismatch is yours to discover, at the bench, at midnight.

Why this is possible here and not elsewhere

You cannot check a sketch against a pin plan if there is no pin plan. You cannot check a pin plan against a board if the board is a guess.

Soldr allocates pins from the manufacturer's published pinout, stored with the source and the date it was read, for a specific board that Compoden physically stocks. Everything above is downstream of that one unglamorous fact.

Describe what you want to build. Asking is free.