Author Topic: Using Claude Code for embedded work  (Read 39320 times)

0 Members and 6 Guests are viewing this topic.

Offline paulca

  • Super Contributor
  • ***
  • Posts: 6442
  • Country: gb
Re: Using Claude Code for embedded work
« Reply #325 on: June 20, 2026, 08:22:59 am »
The risk is really that your professionals refuse to work with "hobbyist ad-hoc mess", even when you know that is exactly what you need first to figure everything out.

I'm going to pull you on scale again.  You seem to think in terms if "a bit of software = project/architecture"

Most large businesses have 100s of bits of software.  A lot of them need to integerate and co-operate or we go back to 1980s when someone would print it out and give it to someone to data-enter back in.

The whole concept of "just redesign it, rewrite it".  Works for "one component" or a "group of components", but even that has to be done in concert with the rest of the business.

Now NONE of that has anything to do with architecture.

The architecture is how the 100 components work together, probably many different architectures.

A MCU project is like creating a podium with a Microphone.  An "Architecture" is what hold the stadium roof, the lights, the cameras, the fire suspression system... etc. etc.  All the seats , the whole complex.

So, yes a new podium and a rewrite.  Go for it.

However.  It WILL need to integrate into the building sound system, light control, projector controller, etc.  They are also parts in the overall architecture.  Are you going to redo the whole building just to suit your new podium.

I honestly think you have the words "Pattern" and "Architecture" flipped.

Lets try a little test...

Name me: One scalable architecture and one unscalable "simple" architecture.  Just the top level name if you want.
« Last Edit: June 20, 2026, 08:27:26 am by paulca »
"What could possibly go wrong?"
Current Open Projects:  68000 Self Build computer + OS.
 
The following users thanked this post: Siwastaja

Offline paulca

  • Super Contributor
  • ***
  • Posts: 6442
  • Country: gb
Re: Using Claude Code for embedded work
« Reply #326 on: June 20, 2026, 08:40:53 am »
I will give me the bare basics of a project I was on recently.  No names.  Obfuscated purpose, but the meat in there.

Customers send us requests for legal documents.  They give us the "named template" and a blob of meta-data.  We send them a legal document PDF cira 100+ pages and 100MB.  "Templates" are not one single document, they generate a "Pack" of documents.  For legal transfer say. 

Each document is generated, then amended with various "locale specific legal requirements" like different text on signature blocks, inserts for California etc.

The set of documents is then merged into a single PDF and either sent for "onward electronic delivery" or dropped into a print queue at one of four industrial printer workshops which "ship" them by mail.

All probably sounds easy enough to picture a bit of software doing this.  The customer already has one.  The issue is the "load factor" and that the current system cannot scale.  The "PDF Engine" is a single multi-threaded DotNetFramework application and is "end to end synchronous".  Request in....30 seconds... PDF out. 

Large customers batch their documentation requests and send them at the end of day.  Some at the start of day.  Some of their days are different timezones.  It bottlenecks.  Cannot be scaled horizontally and vertical costs far too much.

This is one component in a set of components, in a wider architecture, all to do with legal documentation generation.

The change in requirements is fairly harsh too.  "Move it from "Leased DC servers" to "Cloud" so it can scale without having to buy and commission new hardware.  Also so it can run multi-region and have proper failover.  Because of the way to the wider market is, it's to all be rewritten in Typescript. Even if that is the worst idea ever.  It's what the businesses out there are paying for ATM.

Documents can be requested in batches of up to 100.  The current system is struggling under about 100 documents a minute.  Larger document packs taking more than 30 seconds end to end is causing issues with browser/proxy timeouts already. 

The customer engineering want ALL PDF operations moved to a single 'service'.  Rather than bits and bobs spread out across many different flows.

So where would you start?
« Last Edit: June 20, 2026, 08:44:33 am by paulca »
"What could possibly go wrong?"
Current Open Projects:  68000 Self Build computer + OS.
 

Offline paulca

  • Super Contributor
  • ***
  • Posts: 6442
  • Country: gb
Re: Using Claude Code for embedded work
« Reply #327 on: June 20, 2026, 02:25:48 pm »
Not "quite" embedded work, but just saturday some fun with claude, I thought you guys would engage with a little more than enterprise BS.  Its pure engineering control loop stuff.

Today I am teaching claude how to run a nuclear reactor.  This is a 'game' reactor simulator.  Maybe "college" or "under grad" textbook, 3 loop PWR.

The game has a REST API.  Which allows you to control the reactor and read its metrics/guages.

I just handed it the cold reactor.  Asked it to start it up via the API. Absolutely hilarity has been following.

So it lifted the rods and kept lifting to them awaiting a reactor response.  When none came it withdrew them all the way to 50%.  Only then did it realise the fuel was not loaded and sat in the "unloaded" position.  It asked me to insert it as the API has no control to.... so I did.  Knowing exactly what would happen with the rods at 50%.

Reactivity redlined.  Reactor went from "room temp" to 400C in about 20 seconds.  Many alarms and klaxons all at once.  I just laughed.  It got stuck fighting the reactor through transients, but it did get it under control. It just tripped a dozen alarms doing it and damaged several things.  5/10 - shutdown and mantenance required.  However... the reactor was balanced at 300C, the steam gens where at 60bar, 50% fill level.  3rd loop was in vacuum and condensor/condensate in spec.  Steam bypass fully open.  "Right end state".

It didn't boronate the water, it didn't fill the pressurizer, it did not pre-heat the pressureiser.  Just lifted rods to 50% and asked me to dump the fuel in.  Ran several pumps dry, over pressured the steam gen, send condensate into the steam turbines....  at least in a game you can reset the simulation and don't have to do the months cleaning that up.

Anyway, Ive spent the last 3 hours?  Getting claude to write python scripts for it to control the reactor under my direction.  "Safe state -> plan -> new safe state" - to hell with adverse procedures for now. 

Startup: Bring reactor to "ready for rod lift" - script runs parallel "prep" tasks and exits when all exit criteria are met.  Broron, coolant flow, fuel, pressure, temp, steam plant 'primed'.
Then...
Launch control loops for "rods to track iodine", "steamgen balancer pump controls"...

So far so good.  Working through a staged startup process, so I have plenty of time to teach claude.

Step 1: Pre-rod prep.  DONE
Step 2: Rod lift for "Tea kettle mode" (very low iodine gen).  The only consumer is the condensor steam engine vacuum pump.  3rd loop cooling is passive.  rector extremely low power.  (No xenon yet).  Turbines bypassed.  Working on this now.

Step 3:  On reaching  a stable and safe state from above with the condensor alone running off the steam gens.... stabilise the 3rd loop plumbing and vacuum.
Step 4-n: Ramp up power and stabilise.  Notify grid.  Open main steam control valves, shut bypass, spin up the turbines... sync... connect.... load match... monitor.

There are parts of this that are new to me, a lot has changed in the game in recent updates.  The whole condensor steam driven vacuum system is a bit of a wild horse.  Claude is actually pulling in steam plant knowledge, vacuum charts, "steam tables" and trying to work it out too.  Quite amusing.

Hopefully before i get bored claude will do better than 5/10 starting it up and getting it on grid.

If anyone knows how to run an "Industrial steam engine condensor with steam emotive vacuum pump"... now would be the time.  Claude is busy monitoring the evapouration and pressure rise.

The actual "reactor" part is fairly easy in the game, just a rod control loop.  The steam plant is the complicated part.

UPDATE:  I don't understand how to start up the condensor that much is clear.  Nor does claude.  Its just very hard to get any balanced stable state in "Startup mode".  Once the steam comes up to the full 60bar the condensor becaomes hard to manage.  Once the steam goes to the turbines though, and the condensor switches to "Operational mode" it calms down to a sleeping lamb again.  Parked it for today.  Will resume with a "stable on load state" and tune the stable state control loops instead next time.  Startup is complicated.
« Last Edit: June 20, 2026, 04:18:46 pm by paulca »
"What could possibly go wrong?"
Current Open Projects:  68000 Self Build computer + OS.
 

Offline 5U4GB

  • Super Contributor
  • ***
  • Posts: 1755
  • Country: au
Re: Using Claude Code for embedded work
« Reply #328 on: June 21, 2026, 01:45:42 am »
Today I am teaching claude how to run a nuclear reactor.

I wonder how it would run SimEarth? Friend of mine played with this a long time ago when it first came out, only he ran it as SimHell, for example dealing with plague outbreaks by crashing ice meteorites into the plague region. I suspect an AI would run it in a similar manner because there's easy fixes for any problem.
 

Offline peter-hTopic starter

  • Super Contributor
  • ***
  • Posts: 6036
  • Country: gb
  • Doing electronics since the 1960s...
Re: Using Claude Code for embedded work
« Reply #329 on: June 21, 2026, 08:25:30 am »
I did a google on win7-64 and Claude Code:

It's possible to run Claude Code natively on Windows without WSL using PowerShell or Command Prompt. Install Node via the official Windows installer, then run the same npm install command.

Has anyone tried this?

I might try it. A friend (heavy Claude user) says Code should be safe because it can be configured to ask for authorisation for any source change.

Also there is loads of stuff about Vscode on win7-64. The win10+ requirement seems to be the usual gratutious "M$ don't support it so we won't" crap.
« Last Edit: June 21, 2026, 08:33:15 am by peter-h »
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline 5U4GB

  • Super Contributor
  • ***
  • Posts: 1755
  • Country: au
Re: Using Claude Code for embedded work
« Reply #330 on: June 21, 2026, 08:33:05 am »
A friend (heavy Claude user) says Code should be safe because it can be configured to ask for authorisation for any source change.

But that's not binding. I've lost the link to the bug report (currently still unfixed) but it was that requirements in CLAUDE.md are just injected into the context window like everything else in there and, like other things in it, can fade or be forgotten. So you can set hard rules that are later ignored by Claude.
 
The following users thanked this post: peter-h

Offline paulca

  • Super Contributor
  • ***
  • Posts: 6442
  • Country: gb
Re: Using Claude Code for embedded work
« Reply #331 on: June 21, 2026, 08:41:40 am »
A friend (heavy Claude user) says Code should be safe because it can be configured to ask for authorisation for any source change.

But that's not binding. I've lost the link to the bug report (currently still unfixed) but it was that requirements in CLAUDE.md are just injected into the context window like everything else in there and, like other things in it, can fade or be forgotten. So you can set hard rules that are later ignored by Claude.

The cat modifies my code.  She does not have a permissions system.  She just wants to sleep on the warm laptop.

HD crash.  You have bad days and get a day into a refactor you no longer want.  You modify code when drunk. You come into work to find your dev VM was "culled" by accident.  "So sorry, here's a brand new one".

Does the sky fall in?

No, we have git.
"What could possibly go wrong?"
Current Open Projects:  68000 Self Build computer + OS.
 
The following users thanked this post: Siwastaja

Online ejeffrey

  • Super Contributor
  • ***
  • Posts: 4842
  • Country: us
Re: Using Claude Code for embedded work
« Reply #332 on: June 21, 2026, 03:06:48 pm »
A friend (heavy Claude user) says Code should be safe because it can be configured to ask for authorisation for any source change.

But that's not binding. I've lost the link to the bug report (currently still unfixed) but it was that requirements in CLAUDE.md are just injected into the context window like everything else in there and, like other things in it, can fade or be forgotten. So you can set hard rules that are later ignored by Claude.

Those are two different things.

The rules in CLAUDE.md -- stuff like "always re-run tests after every change" or "follow the styleguide naming convention" are inputs the the LLM and subject to randomness.

The permissions / approval requirements (always ask before running shell commands, only access files in this directory) are part of the harness and they are not ignorable, although in practice it's super easy to auto hit "approve" without checking.
 
The following users thanked this post: Siwastaja

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 11241
  • Country: fi
Re: Using Claude Code for embedded work
« Reply #333 on: June 21, 2026, 03:51:22 pm »
A friend (heavy Claude user) says Code should be safe because it can be configured to ask for authorisation for any source change.

But that's not binding. I've lost the link to the bug report (currently still unfixed) but it was that requirements in CLAUDE.md are just injected into the context window like everything else in there and, like other things in it, can fade or be forgotten. So you can set hard rules that are later ignored by Claude.

Those are two different things.

The rules in CLAUDE.md -- stuff like "always re-run tests after every change" or "follow the styleguide naming convention" are inputs the the LLM and subject to randomness.

The permissions / approval requirements (always ask before running shell commands, only access files in this directory) are part of the harness and they are not ignorable, although in practice it's super easy to auto hit "approve" without checking.

Yes. Claude Code is the piece of software that executes actual file edits and tool calls. This software isn't an LLM. It has various permission modes you can use, and it has a json config file in which you can give it permissions to run some programs without asking. No LLM involved in that. (There is an optional permission mode where LLM decides if something is potentially questionable, and lets everything else pass through without asking. It's clearly enough labelled.)

A lot of work to configure, and then you let it run only to see it stopped nevertheless on permission prompt. And routinely hitting allows/allow/allow is not actually any safer, you just stop reading what commands you approve, especially since some of them are long and complicated. I just run always with --dangerously-skip-permissions, which is so dangerous it can be only accessed by typing out that command line parameter. Zero accidents so far. Yes, I trust it; trust and risk-taking is what makes the world go around. Some day it will do some "expensive" mistake. Shit happens. Claude misbehaving and accidentally wiping of your hard drive is possible, but if you think that's your most relevant threat, it's quite scary. No backups? No version control? 100x more likely something else happens, a human mistake or just hard drive failure.

If you fear that Claude can cause more serious damage than a few hours/days worth of lost time, then that's pretty scary, because what's protecting against your human workers or yourself - or your cat - doing the same?

Even I take some minimum amount of precautions. I let Claude access our production database through a script which defaults to read-only access. So it won't that easily mess with the database. If I ask it to do database writes, which is rare, then I temporarily switch off from the auto-accept mode. Same protections, default to read-only, really work against humans making mistakes, too.

Also don't forget the basic user account separation, I think it nowadays works in Windows, too. Even if you run claude --dangerously-skip-permissions, it can only do what you can do on your computer.
« Last Edit: June 21, 2026, 03:59:51 pm by Siwastaja »
 
The following users thanked this post: bookaboo

Online ejeffrey

  • Super Contributor
  • ***
  • Posts: 4842
  • Country: us
Re: Using Claude Code for embedded work
« Reply #334 on: June 21, 2026, 07:45:32 pm »
For coding, data analysis, and that sort of thing i gave basically no qualms. I have version control, and my version control rejects force push and other destructive commands.    I let it write anything in the working copy and rely on backups.  Yes technically it could write and execute a script that deletes my whole home directory but that is very unlikely and i can recover if needed.

For sysadmin and deployment tasks i am a lot more nervous.  Its still very useful but its inteinsically a setup where you can make destructive operations.  Obviously you still want backups but corrupting a production database is still a problem.  I dont really do this so its not something i have to figure out how to handle.

 
The following users thanked this post: Siwastaja

Offline Randy222

  • Super Contributor
  • ***
  • Posts: 1827
  • Country: ca
Re: Using Claude Code for embedded work
« Reply #335 on: June 24, 2026, 02:46:39 am »
I started another thread on same subject..... It wont remove.

Have you seen it, it's an interface between your PC and MC, but you instruct the interface (via AI) to program the MC the way you want it, you can even use voice commands instead of typing.

"Code my MC using proper python and have gpio blink on and off at 50% PWM with frequency of 1Hz".
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf

 

-->