Using Claude Code for embedded work

[jc101]

Interesting thread. Today I was reading up about potentially using some local AI models, via LM Studio, that claude code can be set to use rather than going out to the internet. How well those models work, I've no idea. But the office PC is beefy enough to take a look at. I did check the current price of RAM, that was very scary.

[Unixon]

Why don't you ask it to make an optimized copy of itself? 

[abeyer]

How well those models work, I've no idea. But the office PC is beefy enough to take a look at. I did check the current price of RAM, that was very scary.

It's a mixed lot... none of them are completely competitive w/ using a hosted anthropic model, but they can be useful.

RAM is absolutely important tho... and should be attached to your GPU. So, either a video card with lots of onboard vram, or a chip with cpu/gpu/shared memory all in one package. 24gb is probably the bare minimum to get good results in this space, but 128gb would be my target right now.

If you go the discrete gpu route, you can play some games balancing cost and performance based on how much you do on gpu vs cpu, and how much ram each has.

[jc101]

How well those models work, I've no idea. But the office PC is beefy enough to take a look at. I did check the current price of RAM, that was very scary.

It's a mixed lot... none of them are completely competitive w/ using a hosted anthropic model, but they can be useful.

RAM is absolutely important tho... and should be attached to your GPU. So, either a video card with lots of onboard vram, or a chip with cpu/gpu/shared memory all in one package. 24gb is probably the bare minimum to get good results in this space, but 128gb would be my target right now.

The PC has 64Gb ECC DDR5, the video card has 32Gb VRAM. My M1 Max MacBook Pro is possible, though it's 32Gb. I may update the MBP later in the year, budgets permitting.

[peter-h]

Well, I asked, guess who? Claude:

Q:

Can I give you all the source code for this product, to comment on etc, or do I need to use Claude Code for that? I am running win7-64 and the executable Claude has for fetching the source code from a specified directory is probably not compatible with that?

A:

You can just paste or upload the files directly here in the chat — there's no need for Claude Code for this. You've been doing it successfully throughout this whole conversation, uploading individual `.c` files as documents.

For a whole project, the practical approach is just to upload the files you want reviewed one at a time or a few at a time. The main limitation is context window size — very large amounts of code can push earlier parts of the conversation out of the context window, which is why this conversation was compacted earlier.

Regarding Claude Code and Windows 7 — you're right to be cautious. Claude Code is a command line tool that requires Node.js and is designed for modern operating systems. Windows 7 reached end of life in 2020 and Node.js dropped Windows 7 support some time ago, so Claude Code would almost certainly not run on it.

So the best approach for your project is to continue as you have been — paste or upload the key files you want to discuss. If you want a broad review of the whole project, uploading the main `.c` files one by one and asking for observations on each works well. Alternatively you could paste multiple files in a single message if they are not too large.

Q:

What is the maximum amount of data I can send you?

A:

The context window for Claude Sonnet 4.6 is 200,000 tokens, which is roughly 150,000 words or about 600-800KB of plain text code. However the practical limit per message is lower — very large single uploads can cause issues.

A more practical way to think about it for your project:

- A typical embedded C source file of 500-1000 lines is about 5,000-10,000 tokens
- You could upload 10-20 such files in one go and still have plenty of room for discussion
- The conversation history also consumes tokens — this conversation is already quite long, so you may be getting close to the limit where earlier context starts being dropped

The most practical approach for a whole project review would be to start a **fresh conversation** and upload all your key source files at once at the beginning, then ask for a review. That way the full context is available without the overhead of this long conversation history.

The files most worth uploading for a complete picture would be [ list of .c files ] — which you've already shared here — plus any header files and the main startup file if there is one.

Q:

If I start a new conversation, won't you have forgotten previous comments?

A:

Yes, each conversation starts completely fresh — I have no memory between conversations unless you have the memory feature enabled in settings (which you mentioned earlier is not enabled).

However for a code review that's actually fine — you don't need me to remember the discussion history, you just need me to see the code. You could start a fresh conversation, upload all the source files, and add a brief summary of context such as:

[ list of recent projects and discussions re them ]

That gives enough context for a useful review without needing the full conversation history. The code itself contains most of the relevant information anyway — your comments and change log entries are very thorough.

For anything where the conversation history genuinely matters — like continuing to develop a specific feature — it's worth staying in the same conversation. But for a broad "review all my code" request, a fresh start with all files uploaded is actually better since the full context window is available for the code rather than being partly consumed by conversation history.

[5U4GB]

yeh, something like: I've seen this XX opensource project but I don't like the license, can you write something that does the same?

It's not even that, you have no idea where the code that Claude is extruding for you has come from.  The reason I mentioned SCO vs. IBM is that they used tiny snippets of code, e.g. portions of atealloc, as their "evidence".  So if you're using it for anything other than personal projects you at least need to have a policy about this, for example anyone who contributes AI-extruded code has to take ownership and responsibility for the code and certify that it's their creative work, not the AI's.

That may not be 100% accurate, it was from a long discussion over legal issues when using extruded code which isn't really my department so I wasn't taking notes.  Our policy for now is human-written, human-vetted, human-committed, because there won't be any nasty surprises in the future.  The scariest one would be a ruling that the copyright for extruded code lies with the data it was trained on, which will be a nightmare to go back through every code contribution for the last x years to figure out its provenance.

[ejeffrey]

Well, I asked, guess who? Claude:

Q:

Can I give you all the source code for this product, to comment on etc, or do I need to use Claude Code for that? I am running win7-64 and the executable Claude has for fetching the source code from a specified directory is probably not compatible with that?

A:

You can just paste or upload the files directly here in the chat — there's no need for Claude Code for this. You've been doing it successfully throughout this whole conversation, uploading individual `.c` files as documents.

For a whole project, the practical approach is just to upload the files you want reviewed one at a time or a few at a time. The main limitation is context window size — very large amounts of code can push earlier parts of the conversation out of the context window, which is why this conversation was compacted earlier.

Code review is totally fine to work like that, uploading individual files.  But you are definitely missing out on a lot of capability.  If you want to actually use it to write code or make large scale modifications to existing code spanning multiple files, you are going to want the CLI agent or an IDE/editor integration.  Then it will be able to interact with your version control, read the project files, run build scripts and interpret the results, make refactoring changes across multiple files, and execute multi-step plans.  And yeah, you will need a newer OS.  But you can run it in a virtual machine if you want. That also gets some helpful isolation.  I'm not a windows user, but I would guess you could use WSL2 and run a recent version of Ubuntu in that?

[peter-h]

OK; this is all very useful.

Yes indeed I can run a win10 VMWARE VM on a win7-64 host, and already do. It is just very slow, even on a top-spec machine.

OTOH I mostly do code development in small functional blocks. I am extremely careful to not break existing code which has been thoroughly tested. For example I might want a CAN subsystem, and Claude came up with code in seconds which I can just drop in and which looks mostly usable.

[paulca]

OK; this is all very useful.

Yes indeed I can run a win10 VMWARE VM on a win7-64 host, and already do. It is just very slow, even on a top-spec machine.

OTOH I mostly do code development in small functional blocks. I am extremely careful to not break existing code which has been thoroughly tested. For example I might want a CAN subsystem, and Claude came up with code in seconds which I can just drop in and which looks mostly usable.

Yes and a single prompt and claude code would have tested it all too.

It's honestly night and day. 

Chat bot:  One prompt, one answer, one invocation.  One API call, also cheap.
Code bot:  One prompt, 3 minutes waiting on 5 code analysis agents, 2 planning agents, 6 Q&As.  Outputs a full plan on what is changing and how it will be changed.  You read, approve or go back and forth, or just abort it entirely.  Or say "Yes" and let it action the plan.

It's in the loop fully with you.  Not a back and forth prompt/answer, but actually working in parallel with you.

On platform.  I think this is your biggest hurdle.  Your OS is 10 years old.  Nobody supports it, nobody wants their software to run on it.  A lot their insurance company won't permit it.

Windows10 isn't going to be great either.  Windows has only ever been the home for IDEs and email clients.  Most higher end software runs on Linux, so there is a terminal never too far away.  It's why my company favour Macs.  The core terminal based UI.

It will install and it will run in a "Powershell" terminal and it does support "Powershell", but it's nothing on bash/zsh etc. 

A better option might be VSCode with a bash shell add on or something.  The claude extension on windows might already give you a bash context.  If not it will pick up Powershell and use it.

Claude being in VSCode and you being in CubeIDE might not create as many issues as you think it will.

Similar installing the Claude Code extension for eclipse into CubeIDE might have legs.  Depending on how old your CubeIDE is.

[peter-h]

You read, approve or go back and forth

The bit I don't get is how can one possibly do good quality embedded code this way. In embedded, there is a lot of critical stuff to do with e.g. peripheral setup and timing. There is a lot of scope testing to make sure timing is right. Claude cannot read and make sense of the 2000 page RM, for example. It probably dives into github, ST appnotes, and such like, for code examples.

When you get to stuff like user interfaces, it gets a lot easier. That's what I found.

Whereas e.g. web application development is far less critical. You can throw code at the problem until it looks like it is working and then you move on to the next bit. You get lots of subtle browser dependent compatibility issues but few people worry about that these days I see people doing server-side apps fully with this process, with high productivity.

[SpacedCowboy]

Peter, have you actually tried it ?

I ask because in that 6502 compiler I was talking about, Claude wrote optimising steps based on the knowledge that if there was a STA absolute,X (or Y), there was a 1-clock penalty for the access if the indexing took it over a page boundary.

I didn't tell it. It worked it out for itself. That seems to be the sort of detail that you're talking about. This, of course, is Claude Code, not just the bargain-basement web version.

122B on 128GB of RAM? Is that Q4 with a limited context size?

It was a while ago, but I think it was Q4. I was also using the trick to increase the RAM available to the GPU (to 116GB IIRC), but my context size was maxed out at 256K.

I do expect the local models to get better, I'm not sure how quickly they'll get to where the frontier models are now, but they've made enormous strides over the last 6-9 months. I very much doubt that's the end of it.

[paulca]

There are strengths and weaknesses in it's training data, yes.

Also a full 2,000 page STM reference manual, especially in PDF format is going to bust your token budget rapidly.

Again, apply the "Junior Engineer" pattern.  What would you do with a junior engineer in that circumstance?

Let's be fair and honest here.  You would "helicopter" and "micro-manage" them, right?  Then do that with claude.

There are a few tricks though, that you can't really try with a flesh and blood engineer, not safely anyway.  You can have more than one claude session, you can use that "Always a new junior every day" problem to your advantage.  If one 200k context doesn't fit, use two or more of them.

To explain.  An approach I have taken before, under similar circumstances is to pick things up where I am happy and comfortable and get claude to explain the current situation to me.  This fits with your situation as I see it.  Gain the trust and steer claude through the "It tells you what your project does." "chit chat" phase.

When you find it steps outside of your "expectations", such as you find yourself saying, "Hey, that's not what it says in my  reference manual.", then point claude at that reference manual or an excrupt and get it to "write it down" for itself (and you) in a reference notes file.

For the reference manual itself.  They can be hit and miss.  It depends on the PDF format.  PDF does not extract in a "co-linear" fashion to the text in more complex formats.  So things like getting one line from the left column + one line from the right column, followed by a "figure annotion" is what the bot sees.  Converting it into a more suitable format, aka, MarkDown or plain text, or even HTML can help the bot parse it and form it into context.  It is also far less tokens to process text than a PDF.

You could use a clean claude session and get it to convert and extract parts of the PDF into a folder of documents, just for claude itself.  It will even install the tools for you, such as "Poppler" PDF utilities.  You don't need to worry much about reading it.  Just check it works by spot testing claude on something very specific and very empirical it either gets right or doesn't.

I took this approach with the 68k CPU and it's MC68681 UART.  The SRAM and FlashROM datasheets were very light, so I left them as PDFs.

At the end of that session, you have a set of "This is what claude needs to know from the reference manual" documentation suite.

You can clear that session now.

Start a new one, and repeat this analysis and documentation stage but focused on your project and writig the documentation for it you could never be bothered to write!  Yes, I see you.

When  you have a nice coherent project description in a folder of documents, you can again clear down that session and context.

Finally.  When you "/init" a project, or just by asking claude to create it, the key file (in the first instance) is the CLAUDE.md readme.  This is the the claude README file.  It will always open it and put it in the context at the top.  In this you tell it about the STM32 docs you created, you tell it about the project documentation you made.  You tell it to use those as references for the hardware and software.  You can even "try" and tell it to "always query the user when there is not enough information present to decide from these hard references alone."

If you are stuck with where to start with claude on the project and if you did the above I would be very, very surprised if you haven't already started a long TODO list of things it found, you didn't like or were trying to hide.  It might find the bodies.  It's very likely to find them and so it's not just you who knows where they are buried.

Start with admin.  Start with listing those things you never got round to.  Asides being a good junior it's a very responsive project manager who will actually write the documentaiton you can't a.r.s.d writing.  The stuff you really needed, but never bothered.  (We would call this backlog forming).

Then just pick one of those that you know the solution to, but just haven't got round to and guide claude through it.  See how you feel, see if claude drove the work and followed  you how you liked.

The end test is simple.  Did it save you time?  Did it help you think?  Regardless of how productive "it" was, did it make YOU more productive?  If those are true, you got it.  If they are not, you might need a change of approach or maybe it just isn't for you.

[paulca]

I didn't tell it. It worked it out for itself. That seems to be the sort of detail that you're talking about. This, of course, is Claude Code, not just the bargain-basement web version.

Mine learnt the hard way, while I watched it burn a week's worth of token budget, that assigning a pointer with 0 in GCC will produce "undefined behaviour" at runtime.  It's the GNU thing where they just declare something as undefined behaviour and do nothing to fix it, deliberately.  It will compile and it will run, but GCC will have stripped all access to that pointer.

But in a hardware project test harness checking that address 0 is writable... kinda necessary.

Honestly, neither it nor me seen this "mistake" in advance but claude got the bone and didn't stop.  It decompiled the binary produced by GCC and looked at the ASM and realised half of it was completely missing.  It even realised it was taking far too long so it just wrote  "TODO.md" file with a "Fix this!" in it and ... commited a sin... it 'fixed' the code to pass the test.  It wrote to address 1 instead. 

Next session I asked it to check the GCC docs and message lists and it found the reference to how GCC will just delete point access'es which are invalid... ie. 0... ie NULL.

Easy fixed, add the right flag for embedded raw access and no more problem.  But it did open a new todo from me.  "Split the build tools for bootload and kernel."  Leave that flag OFF after the bootloader primes the hardware.

[ejeffrey]

OTOH I mostly do code development in small functional blocks. I am extremely careful to not break existing code which has been thoroughly tested. For example I might want a CAN subsystem, and Claude came up with code in seconds which I can just drop in and which looks mostly usable.

If you have a workflow that's working for you great.

The difference with a local instance is the difference between "mostly usable" and "fully implemented and tested". For instance CC if you rewrite you CAN driver to use a port structure passed in as  an argument instead of a global variable, CC could analyze the rest of the code, figure out where to store the port pointers, and update all the fall sites.  Then build and, assuming you have the capability, test.

I've also found it very useful for generating tests.  You can have it analyze a module that is mostly working to your satisfaction and generate a bunch of tests.  While it generally does a good job, here I don't really care.  The important thing is coverage, and now I can have the agent rerun the tests after every change.  That allows it to fix simple bugs automatically, it to ask me if a change in behavior is a legitimate bug fix or a regression.

Again, if you have an approach that's working  go with it.  But if you get a chance to try the command line integration, I recommend it.  I assume the editor plugins work well to but I haven't used them.  I like the CLI because I can keep using the setup I already have and keep the AI agent as a separate window.

[SpacedCowboy]

Honestly, neither it nor me seen this "mistake" in advance but claude got the bone and didn't stop.  It decompiled the binary produced by GCC and looked at the ASM and realised half of it was completely missing.  It even realised it was taking far too long so it just wrote  "TODO.md" file with a "Fix this!" in it and ... commited a sin... it 'fixed' the code to pass the test.  It wrote to address 1 instead. 

Next session I asked it to check the GCC docs and message lists and it found the reference to how GCC will just delete point access'es which are invalid... ie. 0... ie NULL.

Easy fixed, add the right flag for embedded raw access and no more problem.  But it did open a new todo from me.  "Split the build tools for bootload and kernel."  Leave that flag OFF after the bootloader primes the hardware.

Interesting - I tend to ask it to come up with a plan for solving a problem, and actually "discuss" the test-ideas and results - things like that would (hopefully) fall out in the planning stage - it still goes off and runs some programs etc to verify its plan but I think we feel out the problem first, and I think that helps . It's also possible, of course, that I might be benefitting more from this being a software effort than a firmware problem than I thought.

[peter-h]

The difference with a local instance is the difference between "mostly usable" and "fully implemented and tested".

How can CC deliver tested code? The only possible way would be an interface to a hardware test harness etc. Obviously it is not doing that. You (the human dev) need to tell it "yeah I can see data" or "it looks dead", etc.

Whereas with web code it can run the generated HTML by itself.

[nimish]

The difference with a local instance is the difference between "mostly usable" and "fully implemented and tested".

How can CC deliver tested code? The only possible way would be an interface to a hardware test harness etc. Obviously it is not doing that. You (the human dev) need to tell it "yeah I can see data" or "it looks dead", etc.

Whereas with web code it can run the generated HTML by itself.

You can just give it tool access to the input/outputs. I like having it run tests using a basic harness. Use some creativity! All LLMs are is extremely enhanced autocomplete with pattern matching. They are as useful as you make them.

[ejeffrey]

The difference with a local instance is the difference between "mostly usable" and "fully implemented and tested".

How can CC deliver tested code? The only possible way would be an interface to a hardware test harness etc. Obviously it is not doing that. You (the human dev) need to tell it "yeah I can see data" or "it looks dead", etc.

How do you test it?

If your only test criteria is "my human eyeballs see the light blink or the motor move" then yeah, that's going to require those eyeballs.  But if you have any automated testing capability, CC can run that just fine.  And if you don't, but you could CC can help write that.  If that means loading a firmware image onto a device and then communicating over a serial port to check all the sensors behave correctly that certainly possible.

Even if you can't do any significant testing, having CC able to run the build process and check the output is already a huge help.  It does make mistakes like using the wrong variable name or getting function arguments in the wrong order.  I would generally rather it find those errors itself rather than make me do it.

[peter-h]

You guys really build ATE jigs for your new products, and connect these to a PC with some sort of scripting language, so you can use CC to develop the code for it?

[Siwastaja]

yeh, something like: I've seen this XX opensource project but I don't like the license, can you write something that does the same?

It's not even that, you have no idea where the code that Claude is extruding for you has come from.  The reason I mentioned SCO vs. IBM is that they used tiny snippets of code, e.g. portions of atealloc, as their "evidence".  So if you're using it for anything other than personal projects you at least need to have a policy about this, for example anyone who contributes AI-extruded code has to take ownership and responsibility for the code and certify that it's their creative work, not the AI's.

That may not be 100% accurate, it was from a long discussion over legal issues when using extruded code which isn't really my department so I wasn't taking notes.  Our policy for now is human-written, human-vetted, human-committed, because there won't be any nasty surprises in the future.  The scariest one would be a ruling that the copyright for extruded code lies with the data it was trained on, which will be a nightmare to go back through every code contribution for the last x years to figure out its provenance.

Gives classic example of human being (supposedly) violating copyright. A few sentences later, concludes that by limiting to human beings, "there won't be any nasty surprises". I'm astonished at this mental acrobatics - especially given how well-known the pattern of outright copypasting code out of Stack Overflow (without verifying where it come from, or what the license is) is - nearly everyone has done it, and nearly everyone does not admit it, or remember exactly if they did and when.

[SpacedCowboy]

You guys really build ATE jigs for your new products, and connect these to a PC with some sort of scripting language, so you can use CC to develop the code for it?

Not sure what the acronym ATE means, but ... a serial port isn't that hard to link up. CC can probably do it for you (including bit-bang one if you don't have a spare UART

Once that's there, you have a bidirectional data-channel, at that point it's just instrumentation. Which CC can do quite happily.  If you literally don't have any spare pins, CC can probably instrument via a logic-analyser that has a CLI interface. Salaea offer a socket-API for example, for which there's a python CLI.

[peter-h]

Automatic Test Equipment.

One common form is a bed-of-nails fixture and you pop each board into it, press a button, etc. I've built a load of those over the years. Usually they connect to a box with ADCs DACs etc and a laptop driving it all. WinXP usually - only the most timeless will do

I have actually given Claude a phone photo of a laptop screen showing a load of ARINC429 packets, and it worked out 99% of it.

[ejeffrey]

You guys really build ATE jigs for your new products, and connect these to a PC with some sort of scripting language, so you can use CC to develop the code for it?

All of my microcontroller devices have a serial port, whether that is the main communication point or simply for diagnostics logging.  That's all I'm saying.

And it's not "just" so I can use CC.  It's because that's been the only sane way for me to do development for years.

Maybe I sounded more expansive when I said "fully tested" than I intended.  I just meant that whatever you would normally do to make sure you didn't break something can be automated by an AI agent doing the same thing.  Depending on your project you might still have real world functional testing that needs to happen.  But as always with testing, a little bit is way better than none at all.  The vast majority of bugs are simple, but even they can't be caught if the problematic code is not even executed.

[peter-h]

OK; sure. I have a USB CDC VCP port, for debugs etc. So that can be accessible to an application running on the host PC. Normally it is Teraterm...

[ejeffrey]

OK; sure. I have a USB CDC VCP port, for debugs etc. So that can be accessible to an application running on the host PC. Normally it is Teraterm...

Right.  So if you tell CC that the device is connected on com8 or whatever, it will be able to create a test script using whatever serial port library / language you like and verify communication. 

Then you could make a CLAUDE.md file that instructs it to, after every new feature, build a binary, load it with your flash dongle, and then connect over the serial port to check basic functionality.