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

0 Members and 9 Guests are viewing this topic.

Offline paulca

  • Super Contributor
  • ***
  • Posts: 6325
  • Country: gb
Re: Using Claude Code for embedded work
« Reply #75 on: April 23, 2026, 09:10:51 am »
Why can't you just write code by yourselves?

Where do you write yours?  Notepad?  Do you use any CASE tools?  Where is your line?
"What could possibly go wrong?"
Current Open Projects:  68000 Self Build computer + OS.
 

Offline paulca

  • Super Contributor
  • ***
  • Posts: 6325
  • Country: gb
Re: Using Claude Code for embedded work
« Reply #76 on: April 23, 2026, 09:20:58 am »
That is what I do.

I use Claude (not CC) to generate code as required for some well defined functionality. But this is after I have created the project file(s), the overall framework, set up the RTOS tasks, etc.

The usage suggested in this thread seems to be a huge amount of work to set up, and then you have to extremely carefully check all the code - because it has been generated without much involvement from you. The setup to work interactively with CC is also going to be hard to archive, so a re-visit in a few years' time is probably going to be impossible without doing it all again.

I think this "interactive CC" is probably good for scenarios where you inherently generate vast amounts of code, which you don't really understand in detail and don't really want to. The most obvious common example would be server-side website coding. In the embedded sphere, one tends not to write huge amounts of incomprehensible code, but anything to do with wifi or bluetooth is still pretty horrible (a lot of code and almost certainly you won't care much about the detail). USB is not much better.

In most embedded work you need to know the detail.

All I can say is that I do embedded work as a hobby to give myself a break from the sheer scope and depth of the day job.  To write software for a bank, insurance company, logistics company, stock exchange or government... i need to understand their systems FAR better than they do.  I need to know how everyone else does their job so I can do mine.

Embedded is like a green field meadow with a bubbling brook to me.

If you think an MCU or IC datasheet and reference manual is difficult, try something like a multi-leg strategy cross order risk analsyis.  You have < 10uS.  Trillions of dollars will flow through it.  They WILL notice tiny aggregate errors and a single race condition causing incorrect numbers and the entire exchange "freezes" and stop trading until its fixed at the cost of millions per minute.

The details matter.
« Last Edit: April 23, 2026, 09:26:13 am by paulca »
"What could possibly go wrong?"
Current Open Projects:  68000 Self Build computer + OS.
 

Online Unixon

  • Frequent Contributor
  • **
  • Posts: 760
Re: Using Claude Code for embedded work
« Reply #77 on: April 23, 2026, 11:31:50 am »
Where do you write yours?  Notepad?  Do you use any CASE tools?  Where is your line?
Usually in an IDE, which one depends on language and toolchain.
GUI editors like in QtCreator and in Lazarus plus a decent autocomplete pass for CASE tools for me.
However, this is not for embedded development.
Using CubeMX for initial configuration of a project is probably closest to the subject.
 

Offline brucehoult

  • Super Contributor
  • ***
  • Posts: 6395
  • Country: nz
Re: Using Claude Code for embedded work
« Reply #78 on: April 24, 2026, 01:46:25 am »
Why can't you just write code by yourselves?

Where do you write yours?  Notepad?  Do you use any CASE tools?  Where is your line?

Emacs, ever since I got x86 Linux, and an ancient SPARC ELC, and then Mac MkLinux (1995) then Rhapsody (1997) in quick succession in the mid 90s. MacOS 7/8/9 didn't have any satisfactory emacs ports at the time, but MPW offered similar functionality, just using shell scripts (or arbitrary programs) for extensions not elisp.

These days emacs runs on all interesting OSes and is pretty much as usable over ssh as it is locally — or using e.g. sshfs/FUSE or TRAMP to edit remote files on a local emacs.

Here's a MPW Shell script I just found on the net (I had a ton I wrote myself, but who knows if I still have them...)

Code: [Select]
  # StdMPW Canonizes all MPW Textfiles
  # By Dan Allen 7/13/87 set today "'date -s -d' 12:00pm"
  directory "{mpw}"
  for i in : 'files -d'
    directory "{i}"
    for j in 'files -t TEXT'
      setfile -a 1 "{j}"
      target "{j}"
      font Monaco 9 ; tab 4 ; find
      movewindow 36 22 ; sizewindow 473 280
      close
    end
    if "{i}" != ":"
      directory ::
    end
  end

Rather sh/bash-like, but different. And the "target" opens a text editor window and then the font, tab, movewindow, sizewindow, close operate on that.
 

Offline 5U4GB

  • Super Contributor
  • ***
  • Posts: 1712
  • Country: au
Re: Using Claude Code for embedded work
« Reply #79 on: April 24, 2026, 03:26:36 am »
It's gonna be fun when "AI" gets into PCB layout :)

It's been doing it for years, just not stochastic-parrot AI.
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 11122
  • Country: fi
Re: Using Claude Code for embedded work
« Reply #80 on: April 24, 2026, 06:00:37 am »
The usage suggested in this thread seems to be a huge amount of work to set up

Exactly the opposite. There is no setup except just install and start using. That's the whole point. Your manual copy-pasting has "setup" every time (the copypasting back and forth). Besides, in the isolated copypasting, the AI cannot look at surrounding code, so cannot do good work, and will be producing crap that works in isolation, so now you spend more time integrating the pieces together. (The process you mention works quite well for truly isolated pieces.)

AI can do the "big picture" and the integration work just fine, but it has to have full access to your codebase to do that - hence, agentic.

But yeah, if Claude Code doesn't work on Windows 7, and you must use Windows 7, and special setup (like a VM) is "huge amount of work", then it's clearly not for you.
 
The following users thanked this post: hans

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 11122
  • Country: fi
Re: Using Claude Code for embedded work
« Reply #81 on: April 24, 2026, 06:26:03 am »
Why can't you just write code by yourselves?

Oh, just like Linus Torvalds wrote all the code that went into linux? Or like Elon Musk sits in his office writing all the rocket code?

"Just writing code" is something I wholeheartedly agree with, and part of the reason software industry fails so hard is overavoiding "just writing code". But there is a limit how much you can do, even if you are good. It's not a huge amount of complexity after you already have to team up.

Software is not just writing the code once - it's maintaining it, daily operations (debugging production issues, making fixes) - while continuing multiple lines of development of new ideas and improvements. And maybe you have a firmware part, but also UI part, some server, tooling, whatever.

So you have to team up. Well functioning team of 5 really good programmers can do wonders. And AI works if you cannot find these unicorns. The main strength is not that it can "write code". It can do much more to the point that it can work similarly to a human member in a team, but the key strength is 2-3 orders of magnitude less communication delay. This direct natural-language communication and instant implementation of ideas is what drives many inefficient and problematic software industry practices obsolete. Exactly those practices that were necessary evil, but what we "why not just write the code?" programmers hated. Overdetailed planning <-> monkey implementation pattern specifically was expensive and slow. Those who know what they want and "just write code" get the job done well, but once having the insight what is needed and being able to write the code are detached, everything collapses: now you spend nearly as much time as writing the code specifying how the code should be written, and then a monkey implements it, and then it doesn't do what you actually needed (see e.g. the classic https://preview.redd.it/tree-swing-v0-i2aeyrivmjoz.jpg?auto=webp&s=6a8d5a17a9f8decbedd5614c51dc8dc6cbb9e3d4 ), even if the monkey implemented it correctly. This is natural and expected, but the issue is iteration speed and cost.

With AI you won't be writing tickets and specification documents that micromanage details (unless you really want) or testing a product which doesn't work only to revise the documentation to be fixed after weeks. You chat about it and you work together to get it done.
 

Offline 5U4GB

  • Super Contributor
  • ***
  • Posts: 1712
  • Country: au
Re: Using Claude Code for embedded work
« Reply #82 on: April 24, 2026, 06:28:58 am »
in the isolated copypasting, the AI cannot look at surrounding code, so cannot do good work, and will be producing crap that works in isolation, so now you spend more time integrating the pieces together.

I've found the opposite, which was unexpected: Use CLAUDE.md + single file and get good analyses of specific issues, use a group of related files and get vague generalities that aren't particularly enlightening.  This may be a recent thing though as Anthropic allocated every GPU possible to finish the Mythos training and Glasswing, leaving Opus with very little compute for anything.  I'm also still on 4.6 because 4.7 added guardrails to prevent it from being used to find exploits, making it less useful if you're checking your code for possible issues... and presumably to make more of a market for Mythos in the process.
 

Offline peter-hTopic starter

  • Super Contributor
  • ***
  • Posts: 5942
  • Country: gb
  • Doing electronics since the 1960s...
Re: Using Claude Code for embedded work
« Reply #83 on: April 24, 2026, 06:49:25 am »
Quote
to prevent it from being used to find exploits

Surely that is a legitimate use, by someone who wrote the code.

I get Claude warning me about variables shared between RTOS tasks, and then it corrects itself by saying "but in arm32, a float is atomic so it is OK" ;)
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline SpacedCowboy

  • Frequent Contributor
  • **
  • Posts: 419
  • Country: gb
  • Aging physicist
Re: Using Claude Code for embedded work
« Reply #84 on: April 24, 2026, 07:17:29 am »
On a complete tangent - does anyone else feel slightly guilty about terminating the session - ie: killing the instance that's just done so much good work for you - just so you can start afresh with a new context. Making it doubly bad is that I tend to ask the current session to write me the prompt for the next one to be up and running as quickly as possible...

"Yeah, I know you've just performed absolute miracles here, you've just implemented ARC in an afternoon when it took teams of Apple engineers  months to do it, but you've run out of context space now so I'm just going to get rid of you and reboot to a fresh context so I can carrry on with what I want. See ya!"

Only *slightly* guilty, I know it doesn't have feelings, but ...

No ? Just me then ? Ok.
« Last Edit: April 24, 2026, 07:19:11 am by SpacedCowboy »
 

Offline 5U4GB

  • Super Contributor
  • ***
  • Posts: 1712
  • Country: au
Re: Using Claude Code for embedded work
« Reply #85 on: April 24, 2026, 07:51:23 am »
Quote
to prevent it from being used to find exploits

Surely that is a legitimate use, by someone who wrote the code.

It is, but they're worried about use by someone who didn't write the code, perhaps coming from an IP address in North Korea.
 

Offline woofy

  • Frequent Contributor
  • **
  • Posts: 510
  • Country: gb
    • Woofys Place
Re: Using Claude Code for embedded work
« Reply #86 on: April 24, 2026, 08:14:19 am »
On a complete tangent - does anyone else feel slightly guilty about terminating the session - ie: killing the instance that's just done so much good work for you - just so you can start afresh with a new context. Making it doubly bad is that I tend to ask the current session to write me the prompt for the next one to be up and running as quickly as possible...

"Yeah, I know you've just performed absolute miracles here, you've just implemented ARC in an afternoon when it took teams of Apple engineers  months to do it, but you've run out of context space now so I'm just going to get rid of you and reboot to a fresh context so I can carrry on with what I want. See ya!"

Only *slightly* guilty, I know it doesn't have feelings, but ...

No ? Just me then ? Ok.

Its a good illusion, but no.  The moment its finished the job, the specific copy of the model that did it will be assigned a new context window and be busy on something else. It already isn't there any more. If you give it further instructions then your context window may well be assigned to another copy on a different server or even data center. No consciousness , no guilt, no worries.
That said, I'm quite sure the tone of a request affects the output from an AI, but in the opposite way that you might expect. I find being direct and succinct gives the best results. Being overly polite is just verbal noise to the AI.

Online Unixon

  • Frequent Contributor
  • **
  • Posts: 760
Re: Using Claude Code for embedded work
« Reply #87 on: April 24, 2026, 08:34:28 am »
And AI works if you cannot find these unicorns. The main strength is not that it can "write code". It can do much more to the point that it can work similarly to a human member in a team, but the key strength is 2-3 orders of magnitude less communication delay. This direct natural-language communication and instant implementation of ideas is what drives many inefficient and problematic software industry practices obsolete.
I would even speak up in support of AI if it was based on a formal logic approach and worked just as a compiler and abstract problem solver working from strict formal definitions, not this probabilistic crap.

And considering the rest part about raising efficiency... this relentless thirst to accelerate things is not leading us into a good place.
The more people understand this, calms down, and chooses a measured hasteless pace of life the better world we'll be living in.
 

Offline paulca

  • Super Contributor
  • ***
  • Posts: 6325
  • Country: gb
Re: Using Claude Code for embedded work
« Reply #88 on: April 24, 2026, 08:39:37 am »
On a complete tangent - does anyone else feel slightly guilty about terminating the session - ie: killing the instance that's just done so much good work for you - just so you can start afresh with a new context. Making it doubly bad is that I tend to ask the current session to write me the prompt for the next one to be up and running as quickly as possible...

"Yeah, I know you've just performed absolute miracles here, you've just implemented ARC in an afternoon when it took teams of Apple engineers  months to do it, but you've run out of context space now so I'm just going to get rid of you and reboot to a fresh context so I can carrry on with what I want. See ya!"

Only *slightly* guilty, I know it doesn't have feelings, but ...

No ? Just me then ? Ok.

Its a good illusion, but no.  The moment its finished the job, the specific copy of the model that did it will be assigned a new context window and be busy on something else. It already isn't there any more. If you give it further instructions then your context window may well be assigned to another copy on a different server or even data center. No consciousness , no guilt, no worries.
That said, I'm quite sure the tone of a request affects the output from an AI, but in the opposite way that you might expect. I find being direct and succinct gives the best results. Being overly polite is just verbal noise to the AI.

"Overly polite" yes.  But saying please and thank you is not for the bot.  It's for me.  I am still human.

One thing I did find myself doing, early on, was having sympathy for it.  When it went down a rabbit hole and failed, I had the choice to "stop it and put it out of it's missery" or just let it go and revert it in git, clear the context.  The trouble was.  The answers were coming from my "social reasoning".  That triggered some alarm bells.

There are many better ways to deal with this "ephemeral" nature.  More structured and effective methods of persisting context and sharing it across sessions.  Even parallel sessions.

In the simpliest instance is the CLAUDE.md file.  After that there is the .claude folder with things like "System Prompts", memories, skills, plugins, reference sets.  For example.  You can set down reference tables for your hardware in the master .claude folder and it will have those across all sessions.

Claude also tries to "align with your processes".  So if you start a session stating you want a documentation trail and ask for "Mark down files" keeping track of the session, decisions and work.  It will do it, but it will also begin to assume that you want this process carried on throughout and so you stop needing to ask it.

When you launch a new session, point it at the documentation folder, give the context of what you want to pick up on and it will fairly rapidly get back up to speed.

If you find on every session you have to tell claude how to do something or access something for a project... put it into the CLAUDE.md file.  "When trying to access X use Y"
"What could possibly go wrong?"
Current Open Projects:  68000 Self Build computer + OS.
 

Offline SpacedCowboy

  • Frequent Contributor
  • **
  • Posts: 419
  • Country: gb
  • Aging physicist
Re: Using Claude Code for embedded work
« Reply #89 on: April 24, 2026, 09:52:32 am »
I use CLAUDE.md, but this is a big project, and although there's some shared context between sessions, I usually try to keep them fairly separated. The last four have been:

  • Reference counting - so whenever I use 'new', the memory to which it refers is reference-counted and anything wanting to use it just bumps the reference-count up by 1 with 'retain' when using it, and using 'release' to decrement that count when it's done. Once the count goes back to 0, it's returned to the heap
  • Automatic reference counting - so now when you create an object, it gets a reference-count of 1, as soon as you assign it or pass it out of the function that reference count follows it. If it goes out of scope, it gets automatically 'release'd and the memory is returned to the heap if the refcount is now 0, as soon as the last reference goes stale, same thing. Apart from cycles (a has a reference to b, b has a reference to a) this pretty much frees me from any memory management at all, at pretty much zero runtime cost. ARC is freaking amazing in Objective C, I wanted it for my own little language
  • Typed pointers - so you can designate something as 'weak' (for example, there's a few different types implemented) to break that retain-cycle I just mentioned.
  • Class properties - so if you have an i-var, and implement setIvarName then the compiler automatically invokes the method rather than accessing the i-var directly. Turns any i-var into a property-type wherein you can override behaviour (restrict the range of an int to 10-100 for example).
All of these were different sessions - but they all relate to the compiler in general, and sometimes to each other. So I have generic stuff in CLAUDE.md, and I'll specifically ask the current prompt something like "given the current class implementation, write a prompt for the next session that gives a succinct but complete starting point for implementing i-vars as properties using the policies expressed in doc/property-policies.md". I'll get back maybe 50 lines of text, with some things I probably wouldn't have thought to include, and the next session is bootstrapped.
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 11122
  • Country: fi
Re: Using Claude Code for embedded work
« Reply #90 on: April 24, 2026, 10:12:34 am »
I would even speak up in support of AI if it was based on a formal logic approach and worked just as a compiler and abstract problem solver working from strict formal definitions

Oh, but that's a different problem entirely. Programming languages and formal verification or, say, CASE tools, do exactly what you want. Programming language itself is for making a strict formal definition for what the computer should do, and compilers are crazily good at implementing it correctly!

This is a totally mature field of study. It's just that you need someone to write the formal specification, which needs to be both correct and useful. And that's huge amount of work for non-trivial, complicated problems. It's the design work.

You can present rocket trajectory as a series of formulae, but you can't represent, say, Microsoft Word or Tesla's infotainment system or ERP or Altium Designer or linux kernel as a series of formulas. You only have feelings, fluffy human language plus maybe drawings to represent user experience, which is everything that eventually matters - does it work and does it do what it needs to do?

And the code needs to implement that.

So yes, AI agents are human replacements. They design and implement software. They are not 1:1, and have different set of strengths and weaknesses. They are solving a totally different problem than what programming languages, formal verification or CASE tools are. And they use those tools!
« Last Edit: April 24, 2026, 10:24:54 am by Siwastaja »
 

Online Unixon

  • Frequent Contributor
  • **
  • Posts: 760
Re: Using Claude Code for embedded work
« Reply #91 on: April 24, 2026, 11:06:08 am »
but you can't represent, say, Microsoft Word or Tesla's infotainment system or ERP or Altium Designer or linux kernel as a series of formulas.
Since each one of such products is a mix of informal artifacts and formal solutions it is not possible to re-engineer it completely from a formal specification.
If would be possible if world artifacts were isolated and provided as a system of constraints.
Fluffy feelings expressed in "I want it to be this way because I see it so, but can't explain" just as historical artifacts like compatibility requirements must be recorded to a list of artifacts which is informal part of set of formal definitions.
Probabilistic AI as it is may be very efficient in constructing such corpus of definitions and that's OK.
But all the rest must be derivable within a rule system.

So if you ask an AI agent to explain how it got this solution it mush show you exact derivation sequence that it used inside (not an imitation of) just as a compiler would show you it's internal AST and debug-print all the rest of decisions up to code generation.
 

Online Unixon

  • Frequent Contributor
  • **
  • Posts: 760
Re: Using Claude Code for embedded work
« Reply #92 on: April 24, 2026, 11:14:50 am »
Cause the way it works now is "I don't know what the hell I'm doing, but the frequency of this event in a given context is high" and this is just insane.
Yes, I do find Google's Gemini suggestions useful at times, but it is impossible to be sure that it didn't just made some shit up.
 

Offline 5U4GB

  • Super Contributor
  • ***
  • Posts: 1712
  • Country: au
Re: Using Claude Code for embedded work
« Reply #93 on: April 24, 2026, 11:49:58 am »
This may be a recent thing though as Anthropic allocated every GPU possible to finish the Mythos training and Glasswing, leaving Opus with very little compute for anything.

A recent post from Anthropic explaining that they did indeed change some stuff recently that impaired performance.

Also, for people hanging out for Mythos, it sounds like the name is appropriate.
 

Offline 5U4GB

  • Super Contributor
  • ***
  • Posts: 1712
  • Country: au
Re: Using Claude Code for embedded work
« Reply #94 on: April 24, 2026, 11:58:36 am »
Its a good illusion, but no.  The moment its finished the job, the specific copy of the model that did it will be assigned a new context window and be busy on something else. It already isn't there any more. If you give it further instructions then your context window may well be assigned to another copy on a different server or even data center. No consciousness , no guilt, no worries.

In the things-you-probably-didn't-need-to-know basket, this is how online sex chat sites work, or used to.  You think you're having a private chat with Misty when what's at the other end is a pool of work-from-home folks who get your chat in one window and context information in the other, so they can have an ongoing conversation with someone they're encountering for the first time.  When you type in your message, whoever's first in the queue picks it up and responds.  The next time, you can get a completely different person responding after consulting the context notes to see what the conversation is about.  Those earn-money-working-from-home jobs aren't only money mules.

The difference now is that it's AI bots instead of human workers.
« Last Edit: April 24, 2026, 12:00:39 pm by 5U4GB »
 

Offline ejeffrey

  • Super Contributor
  • ***
  • Posts: 4827
  • Country: us
Re: Using Claude Code for embedded work
« Reply #95 on: April 24, 2026, 04:20:35 pm »
The usage suggested in this thread seems to be a huge amount of work to set up

Exactly the opposite. There is no setup except just install and start using. That's the whole point.

Exactly.  There are a lot of things you _can_ do, to improve the process.  But for me the huge benefit of specifically the CLI agents is that you dont have to change your existing process at all.  You dont need to figure out how to integrate it with your editor / IDE.  You don't need to let it see your whole project or explain the build process.  You dont need to use a specific version control system.  You dont have to install language servers.  You just install it and run it and then tell it what to do.  And you dont have to give control entirely.  You can still do manual edits, and the worst that happens is the next time it tries to edit that file it may fail until it refreshes its cache.

The other stuff helps.  The more of your project it can see and the more tools you give it access to and the better you maintain its context window the better the results you will get and the more complex tasks it can perform.

But even then: the first order thing to do is write a text file with a list of instructions like "to build, run make compile; the output will be in the build/arm32 directory."  That and using plans which are just markdown outlines (written by CC and edited or approved by you) of steps and substeps.

I have been using the gemini CLI (which is googles version of CC) on verilog projects for a few weeks now.  Its _definitely_ worse than python/c/c++ and other traditional programming languages.  But its still quite good.  And it deals far better with the shitty world that fpga developers are forced to live in than any ide ever.  It can work around black boxes, hidden, encrypted libraries, and multi megabyte compile logs filled with useless warnings. its tripped up by many of the same things that give humans problems but it also helps manage those problems.
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 11122
  • Country: fi
Re: Using Claude Code for embedded work
« Reply #96 on: April 24, 2026, 07:00:55 pm »
It can work around black boxes, hidden, encrypted libraries, and multi megabyte compile logs filled with useless warnings. its tripped up by many of the same things that give humans problems but it also helps manage those problems.

If you look at how it works (I'm assuming similarly to Claude), it's eerily similar to human beings - limited by "context" like human beings - so it reads 100 lines of the huge log... Then it greps it, does spot searches of codebase, maybe writes a Python script to filter the log... Whatever to prevent it from having to actually read the megabytes of log, because just like human, LLM realistically can't do it either.

So the difference is just that it does those steps much faster; instead of spending the whole afternoon doing those tool uses, it does it in 5 minutes.
 

Online uer166

  • Super Contributor
  • ***
  • Posts: 1264
  • Country: us
Re: Using Claude Code for embedded work
« Reply #97 on: April 24, 2026, 08:04:21 pm »
LLMs for coding are best treated as a force multiplier rather than an engineer replacement.

One really good embedded developer can maintain, churn out, refactor and debug more code with Claude rather than on their own.
 

Offline paulca

  • Super Contributor
  • ***
  • Posts: 6325
  • Country: gb
Re: Using Claude Code for embedded work
« Reply #98 on: April 25, 2026, 10:57:36 am »
I use CLAUDE.md, but this is a big project, and although there's some shared context between sessions, I usually try to keep them fairly separated. The last four have been:

So for "contained tasks" that apply across 'contexts', and sessions such as a 'de-linting', "bug finds" and 'static analysis', even code review this is where "Skills" actually work and are intended to be used.

Consider a CLAUDE.md file, but in your shared (project or user level) .claude config.  Now instead of calling it CLAUDE.md you call it something like  skills/reference-check/SKILL.md

You don't even need to understand, even that much.  When you go back to your "Referential integrity" session, ask claude to capture the process you have been following with it into a "skill".  I suggest plan mode so it gives you the full break down of what it does (or does not) capture in the skill.  It writes it for you.

Then in any session, new or maxed out, doesn't matter, you can just "invoke" that skill.  In most situations it is just a "canned prompt" based on the steps and processes you highlighted from your prior 'manual' prompting version.  It's capturing something quite real here.  'Your' personal process of how you want claude to go through things.  The key difference is that you don't need to re-explain those processes, techniques and rules to it every time.  Just run the skill.

Some skills do not even "do" anything.  They are just there to instruct claude to load a bunch of things into context when you switch to a particular task.

If when I get back into embedded stuff, I will be employing skills as simple as:

/stm32f411
/arduinomega
/esp32

And keep those updated when I work on each, so when I switch micro I don't need to "quirk check" it so much each time.  Any quirks or "out of date info" that creeps in can be 'fixed' in those skills.  They will not action anything, except to point claude to the documnentation collection and "ways of working" MDs files... specific to that micro.
« Last Edit: April 25, 2026, 11:01:37 am by paulca »
"What could possibly go wrong?"
Current Open Projects:  68000 Self Build computer + OS.
 

Offline paulca

  • Super Contributor
  • ***
  • Posts: 6325
  • Country: gb
Re: Using Claude Code for embedded work
« Reply #99 on: April 25, 2026, 11:14:43 am »
The usage suggested in this thread seems to be a huge amount of work to set up

Exactly the opposite. There is no setup except just install and start using. That's the whole point.

Exactly.  There are a lot of things you _can_ do, to improve the process.  But for me the huge benefit of specifically the CLI agents is that you dont have to change your existing process at all.

The situation we need to assist in here is that the OP's dev environment is highly customized, version frozen all over the place and running on Windows 7.

That particular combination, old eclipse, old proprietary extensions, old operating system and a completely custom dev environment beyond that... is not particularly welcoming to modern software.  Almost everything in the stack dropped windows 7 support 5 to 6 years ago, along with the dated DotNet runtimes and you are immediately into "What works, what doesn't" if you try and run them.

Peter has suggested he is willing to go as far as a VM with Windows 10 I believe?  That's a start.  Not a bad one either.  For Peter's peace of mind the VM provides a protection layer, makes it a sandbox "air gapped" almost from his actual dev environment.  No shared files, no shared execution contexts, no shared memory.

Windows 10 alone will get to a running claude CLI in power shell.  Might require a few "Add programs and features".

Does anybody actually like DotNetCLI... sorry Power shell?  I know I can't speak a line of it.

I would see that as the next hurdle.  How do we get a 'decent' enough bash shell on WIndows 10?  WSL ... is a bit heavy, it's basically a nested VM.  Brings a whole new set of problems we don't want.  You might as well install Kubuntu at that point instead of Windows 10.

VSCode will run happily in Windows 10, I use Windows 10 for dev still.  VSCode has got claude extensions and they do support "Raw CLI" mode.  If you are going to find a bash shell extension somewhere, VSCode is a good place to look.  Cygwin... not worth it.  "Git Bash" doesn't have the level of terminal control required by claude.

Even with powershell.  Just
* Fresh windows 10 VM
* Turn off the garbage telemetry and tidy it up - or use a pre-cleaned ISO
* Install Claude CLI with the instructions for Windows 10.... I believe they exist somewhere
* Copy, zip, checkin/out, or fileshare a copy of your project into the VM
* Run claude.
* Ask it about your project.
* Tell it your problems.
* Sit back and enjoy.


Caveat:  I have never tried to run claude in Windows at all.
Caveat2: I think the OP should just go and install Kubuntu.  It's very windows like and very user friendly out of the box.  It even has the "Terminal - Konsole" in the favourites menu on first boot.  Just the claude curl command to begin.
« Last Edit: April 25, 2026, 11:21:42 am by paulca »
"What could possibly go wrong?"
Current Open Projects:  68000 Self Build computer + OS.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf