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

0 Members and 32 Guests are viewing this topic.

Offline paulca

  • Super Contributor
  • ***
  • Posts: 6507
  • Country: gb
Re: Using Claude Code for embedded work
« Reply #225 on: June 07, 2026, 07:20:23 am »
Code: [Select]
aFunction( anObject ) {
   anObject = detaint( anObject )
   anObject = normalise( anObject )
   anObject = validate( anObject )
   anObject = domain_map( anObject )
  // etc.
   return anObject
}

I see you!  I see you want to convert that all into a single cascade chain of function calls and remove the intermediary assignments entirely.

STOP!

Get some experience of debugging things under pressure. 
"What could possibly go wrong?"
Current Open Projects:  68000 Self Build computer + OS.
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 11298
  • Country: fi
Re: Using Claude Code for embedded work
« Reply #226 on: June 07, 2026, 12:26:51 pm »
So when I see broad stroke "LLMs are useless" opinions, my immediate reaction is "you're holding it wrong" or (being more blunt, forgive me) "you don't know what you're doing".

Even more bluntly: I don't think it's even "you are using it wrong", but rather, it's "you haven't really even tried, so you are just talking about something you don't have a freaking clue about". 99% of AI critics have not tried, or have tried so lightly it doesn't even count as trying (and hence, something that they would do wrong or right), or have tried many years ago.

There are good tell-tale signs to distinguish people like this, e.g. the classic "LLM is just a statistical parrot" argument. Reasoning LLMs became mainstream more than 3 years ago and do well in any reasoning benchmark, and all you need to do is to give any modern-day LLM, even some free online model like ChatGPT/Deepseek (Claude Opus in Claude Code is obviously even better), any programming task which requires reasoning - and watch it do exactly that: solve a problem which never exists in the training data, by following a step-by-step thinking process (which Anthropic nowadays unfortunately hides from the sight; in that regard, Deepseek might be a better first introduction as you can enable the thinking visibility), disproving the "just repeats the training data" theory.

LLMs are "statistical parrots" and generic reasoning machines and huge collections of nearly all human knowledge, and the combination of these three traits make them do useful work.

Quote
Sometimes they'll be wrong, you correct them, and they'll learn and adjust from that. Often better than people would.

Combination of two factors: the model itself has been trained with thousands of times more input data than any human being has seen. It averages out strong wrong biases some people have. (The flipside is that it might not been pushy enough when the user indeed is seriously wrong and a "strong" opinion happens to be correct.) - then the user prompt has quite significant weight, so it's easy to push the probability horizon where you want - i.e., correct the wrong idea.

Because the training input tends to be quite balanced, user prompt can easily push it to a certain direction; this is the "learning" and "adjusting" you mention. Both a blessing and a curse. If the user is wrong, user can easily manipulate the LLM to agree.

Reasoning depth of the LLM actually helps here. When you are disagreeing with the LLM, it IS a good idea to tell your reasoning of why, because that stays in context, and it then takes it into account every time it reasons further about the issue.

You just saying "no, not this, but that" gets some weight because the machine is trained to follow user's orders. But telling also why makes it reach the same conclusion, and just like with human beings, means it will reason around this limitation and find the correct solution, instead of keeping finding the solution it thinks is right, only to dismiss it because user said it's forbidden (without any explanation why), creating a loop.

Those who don't want to let the AI think and want it to be a stupid machine only, with very peculiar processes they want to micromanage, will be most disappointed. Those who create long lists of "donts" in CLAUDE.md and get a stroke every time it accidentally breaks one of the rules, will be disappointed. Give it some real work and real responsibility and you will actually see how much it can do.

Quote
I have an excellent (almost to the level of hand-tuned assembly) compiler for an obsolete processor that was written almost entirely by an LLM. That processor, yes, was very popular during its day, and still has its adherents, but it's a niche of a niche of the internet, and "its day" was actually prior to the internet; yet Claude could tell me that Read-Modify-Write was in significant use on C64 machines, but almost never used on Atari machines, so this optimisation could work here and that one was better there. The amount of internet real-estate dedicated to that is miniscule. You don't need that much source material for the data to be represented in the weights.

And this is one of the core strengths. It's almost unbelievable how much these machines know, and how correct their information usually is. They deserve all the amazement.

Quote
I think (and this may be an unpopular opinion I guess) there is a fair amount of copium going on when people decry the abilities of LLMs.

Well said. But it's psychology. The cycle of admitting being wrong is highly personal. Many of us were rightfully skeptical, and to be fair, say 4-5 years ago when ChatGPT was the fanciest thing and mostly hallucinated total bullcrap to no end, and in context of programming, was only able to output variations of popular example programs, it was hard to see how this would ever become revolutionary for programming, like some were saying. But they were right; maybe some of them saw something critics didn't, maybe some were just optimists and were right by mere luck.
 

Offline ralphrmartin

  • Frequent Contributor
  • **
  • Posts: 519
  • Country: gb
    • Me
Re: Using Claude Code for embedded work
« Reply #227 on: June 07, 2026, 05:39:06 pm »
Even more bluntly: I don't think it's even "you are using it wrong", but rather, it's "you haven't really even tried, so you are just talking about something you don't have a freaking clue about". 99% of AI critics have not tried, or have tried so lightly it doesn't even count as trying (and hence, something that they would do wrong or right), or have tried many years ago.

There's another possibility - they have tried to solve problems for which there is inadequate training data.

Here's a little problem (not embedded, sorry) which I have not found any current reasoning LLM able to give a good (or even working) solution to. All I get is half-baked solutions which dont compile or dont run (typically with library version problems) or produce the wrong output (a black screen), even after several hours interaction with the LLM  to try to get it to fix up its errors:

Write a java modern opengl program using the JOGL libraries to draw a rotating cube illuminated with phong lighting. This program is to run on a Mac with an Apple Silicon processor.

I've tried with a whole range of models and multiple coding agents. None of them gave a working solution ebven after lengthy interaction trying to explain what went wrong.. My conclusion at this point: these tools are great for straightforward tasks of the kind where there are plenty of materials / hints online (web page stuff, for example), but less so for specialised coding and uncommon tasks. I'm surmising here, but I suspect similar issues could arise for less widely used microprocessors/controllers, or obscure embedded problems.

 

Offline SpacedCowboy

  • Frequent Contributor
  • **
  • Posts: 448
  • Country: gb
  • Aging physicist
Re: Using Claude Code for embedded work
« Reply #228 on: June 07, 2026, 07:59:57 pm »
Here's a little problem (not embedded, sorry) which I have not found any current reasoning LLM able to give a good (or even working) solution to. All I get is half-baked solutions which dont compile or dont run (typically with library version problems) or produce the wrong output (a black screen), even after several hours interaction with the LLM  to try to get it to fix up its errors:

Write a java modern opengl program using the JOGL libraries to draw a rotating cube illuminated with phong lighting. This program is to run on a Mac with an Apple Silicon processor.

I've tried with a whole range of models and multiple coding agents. None of them gave a working solution ebven after lengthy interaction trying to explain what went wrong.. My conclusion at this point: these tools are great for straightforward tasks of the kind where there are plenty of materials / hints online (web page stuff, for example), but less so for specialised coding and uncommon tasks. I'm surmising here, but I suspect similar issues could arise for less widely used microprocessors/controllers, or obscure embedded problems.
[emphasis mine]

I don't have the time to try your problem myself and see, but in reply to the bolded statement:

Here's the documentation for a new language (xtc) and an extended 6502 (it has stack-relative addressing, and a much larger stack to play with) running at 100MHz in fabric, both of which have been created with Claude. On top of that, it's instrumented FreeRTOS running on a Zynq A9, with an HDMI output pipeline which has a scaler and multi-purpose blitter, and a sprite-engine built in. Last night (yes, just last night) it integrated GEM (the Atari ST's graphical user interface system, writing the VDI (virtual device interface, all the lines/fills/beziers/arcs etc.) as well as the AES (Application Environment Services, all the dialogs, menus, event-processing etc.), embedded Lua to give /etc/rc.d style boot scripting, libz and freetype to provide outline font-processing, and bound the VDI and AES into the lua environment so you can script the UI.

Here's the desktop I have up right now, generated by the Zynq, with some lines/faked-out window at the top left drawn with the bound Lua tables, just some tests I've been running on calling the blitter to draw lines, and an active 6502 session in the centre of the screen:

2836070-0

I just asked it to help integrate the font-blitting, using the font-cache {ptr-to-buffer, stride} as a data source, and (for a given string) sourcing the glyph source {x,y,w,h} and buffer-destination {x,y,stride}. This was its response:

Code: [Select]
⏺ Here's the detailed design. I've grounded it in the actual blitter structure (queue snapshot at
  xt_blitter.sv:558, source-addr gen at :847, FLAGS at :372, the alpha-blend datapath, the 1024-deep FIFO).

  DDR-source blit (font + general) — RTL design

  1. Command & mode
 
  New CMD = 0x08 (SRC_BLIT), reusing the existing block-blit read/write FSM
  (BL_READ→BL_RWAIT→combine→S_AW/S_W) but with a configurable source. Keeps the existing BLOCK_BLIT (0x03,
  plane-internal) untouched. Mode comes from FLAGS bits (offset 0x18, currently only [0]=BLEND,
  [1]=BILINEAR):
  - [2] SRC_DDR — source reads from SRC_BASE/SRC_STRIDE instead of the hardwired plane
  - [3] SRC_COV — source is 8-bit coverage (text); else RGBA (4 B/px)
  - [4] SRC_AOVER — for RGBA: alpha-over composite; else straight copy
 
  2. Datapath — two formats, one blend

  - Coverage (text): read 1 byte/px from the atlas → that byte is the alpha; the color is the pattern
  register (set a 1×1 pattern = text color, exactly like a fill). Blend dst' = dst·(255−cov) + color·cov.
  This reuses the existing alpha-blend-rect-fill datapath (BL_RACC…), just sourcing alpha per-pixel from
  DDR instead of the pattern's alpha byte.
  - RGBA (general): read 4 B/px; SRC_AOVER → dst' = src.rgb·src.a + dst·(255−src.a) (same blend unit); else
  straight copy (today's block-blit combine).

  3. Source address (no multiplier)
 
  Today: bl_src_raw_addr = FB_BASE + (src_y+cy)<<13 + (src_x+cx)<<2 (:847). New:
  src_row_base  = SRC_BASE + (src_y)·SRC_STRIDE      // accumulated, +SRC_STRIDE per row (no mult)
  src_pix_addr  = src_row_base + (src_x+cx)·bpp      // bpp = SRC_COV ? 1 : 4
  The ·SRC_STRIDE is done as a per-row accumulator (the blit already walks rows), so no DSP multiplier —
  consistent with the existing "no multipliers" rule. Coverage reads unpack 8 px/beat (1 B/px) vs RGBA's 2
  px/beat.

  4. Per-command snapshot (queue-safe atlas)
 
  The atlas {ptr,stride} + src-flags are snapshotted into the queue entry at CMD-write time (like dst/src
  already are), so every queued glyph-blit carries its own atlas — no global-state hazard when the CPU sets
  up the next run while the previous one is still draining. This widens the snapshot 192→256 bit
  (SRC_BASE[32] + SRC_STRIDE[16] + src-flags; the FIFO BRAM grows one tier). You set
  SRC_BASE/SRC_STRIDE/color once per run; each glyph's CMD captures them.

  5. The fiddly bit — register allocation

  The 32-byte register window is full, and three $D4Cx slots collide with the keyboard-injection regs in
  fpga_xt_top ($D4CB/CD/CF). Two ways to fit SRC_BASE(4B) + SRC_STRIDE(2B):

  Option: A — auto-load stream (recommended)
  How: Reclaim the dead FONT_DATA slot (0x1E/$D4CE, the one non-colliding free offset) as SRC_DATA: write 6
 
    bytes (BASE×4, STRIDE×2), auto-advancing like PAT_DATA; pointer resets on a FLAGS write. Retire the
    FONT_* coverage BRAM.
  Cost: Localized to the blitter; no top-level change
  ────────────────────────────────────────
  Option: B — relocate kbd regs
  How: Move kbd-inject $D4CB/CD/CF into the $D5xx I/O gap (like the bank regs already were), freeing 4
  clean
    offsets for plain SRC_* registers.
  Cost: Cleaner map, but touches fpga_xt_top + the USB-HID→POKEY path
 
  6. Software side (C/VDI)

  - Atlas build: on first sight of a glyph, FreeType-rasterize its coverage into a DDR atlas buffer
  (gfx_a9/font.c), record its {x,y,w,h} slot. Flush once.
  - Draw run: set SRC_BASE/SRC_STRIDE = atlas, pattern = text color, then per glyph push SRC{x,y,w,h} +
  DST{x,y} + CMD 0x08 — all into the 1024-deep queue in one vdi.text() call; blitter drains async.
  - Large glyphs (>cache slot) and rotated/effected text fall back to the CPU path.

  7. Validation → bitstream

  - tb_xt_blitter: coverage-blit (atlas→plane, check blended pixels), RGBA alpha-over, straight RGBA copy,
  and the per-row-accumulator address gen.
  - tb_blitter_bridge: a SRC_BLIT through the GP0 path (atlas in the mock DDR).
  - Then bitstream + on-HW: vdi.text a string, confirm it matches the CPU rendering.

  Scope

  This is the biggest piece so far — new command, reconfigurable source-read, coverage unpack, blend
  wiring, snapshot widening, register loads, plus the C atlas manager — then a bitstream. Several hours of
  RTL+sim before the ~40-min build.
 
  Two calls for you before I start cutting RTL: register option A vs B, and confirm CMD 0x08 (new) vs
  folding into BLOCK_BLIT 0x03. My leanings: A (localized, no top-level churn) and new 0x08 (isolates the
  new path so block-blit/fills can't regress).

I'd be happy with that from a junior (or even mid-level) software engineer. I'm about to push back on it because I can't see any specification for offscreen bitmap blits. It looks like it's baking in the 0-level compositing screen (there are 4 levels) as the destination. This is the sort of thing I do often look out for - where it takes a task and does what you ask, but fails to generalise it to a larger scope.

I should point out that Claude has already engineered

  • The 6502 CPU
  • Extensions to the 6502 to make it play better with modern compilers
  • Support chips (ANTIC, POKEY, PIA)
  • 4-layer compositor, lowest is the GEM desktop, then m68k emulator, then 6502 emulator, then sprites/mouse etc.
  • Line/Arc/Affine-transform/Bi-linear transform/Blit/Rect/Pattern-fill blitter
  • Sprite engine
  • xtc language, with IR representation, targets 8-bit 6502 and (currently) 64-bit ARM, others to come
  • Automatic memory management (ARC) even on a 6502

This seems well beyond a simple 3D app, and significantly more complex a problem than a "simple web app". It also deals with problem-spaces that aren't that well populated on the internet.
« Last Edit: June 07, 2026, 08:02:17 pm by SpacedCowboy »
 

Offline nctnico

  • Super Contributor
  • ***
  • Posts: 30304
  • Country: nl
    • NCT Developments
Re: Using Claude Code for embedded work
« Reply #229 on: June 07, 2026, 08:03:53 pm »
Combination of two factors: the model itself has been trained with thousands of times more input data than any human being has seen. It averages out strong wrong biases some people have. (The flipside is that it might not been pushy enough when the user indeed is seriously wrong and a "strong" opinion happens to be correct.) - then the user prompt has quite significant weight, so it's easy to push the probability horizon where you want - i.e., correct the wrong idea.

Because the training input tends to be quite balanced, user prompt can easily push it to a certain direction; this is the "learning" and "adjusting" you mention. Both a blessing and a curse. If the user is wrong, user can easily manipulate the LLM to agree.

Reasoning depth of the LLM actually helps here. When you are disagreeing with the LLM, it IS a good idea to tell your reasoning of why, because that stays in context, and it then takes it into account every time it reasons further about the issue.

You just saying "no, not this, but that" gets some weight because the machine is trained to follow user's orders. But telling also why makes it reach the same conclusion, and just like with human beings, means it will reason around this limitation and find the correct solution, instead of keeping finding the solution it thinks is right, only to dismiss it because user said it's forbidden (without any explanation why), creating a loop.

Those who don't want to let the AI think and want it to be a stupid machine only, with very peculiar processes they want to micromanage, will be most disappointed. Those who create long lists of "donts" in CLAUDE.md and get a stroke every time it accidentally breaks one of the rules, will be disappointed. Give it some real work and real responsibility and you will actually see how much it can do.
From first hand experience I can say this is very true. Micro managing Claude is the wrong way of using it.

Recently I had Claude do a massive rewrite to convert about 15k SLOC of C into C++ and do some other improvements. At some point Claude had missed a subtile statemachine discrepancy causing the program to enter a deadlock. Claude started to go in circles trying to debug the problem. At some point I had to intervene and tell it to take a step back and look closely at the original code and check how the state changes work in the new code. Claude did a compact by itself, did an in depth analysis and did track the problem down. All this in a process where I'm working with Claude like Claude is a fellow software engineer. BTW I'm finding myself being polite when communicating with Claude  ;D Interesting.

Then again, my workflow with fellow engineers has always been goal oriented and not so much about the path to get there. I don't always have to agree with how somebody implements something however, for as long as it does the job, I'm happy.
« Last Edit: June 07, 2026, 10:22:16 pm by nctnico »
There are small lies, big lies and then there is what is on the screen of your oscilloscope.
 
The following users thanked this post: peter-h, Siwastaja

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 11298
  • Country: fi
Re: Using Claude Code for embedded work
« Reply #230 on: June 08, 2026, 05:46:26 am »
Write a java modern opengl program using the JOGL libraries to draw a rotating cube illuminated with phong lighting. This program is to run on a Mac with an Apple Silicon processor.

That's an interesting test - so you are giving it very strict constraints, and not helping it out achieving it. Interesting follow-up to this test would be:
1) give it more freedom: "Write a program that draws a rotating cube on Mac with an Apple Silicon processor, with the framework you feel confident with"
2) if you want those exact libraries, help it out; give your experience/insight on those libraries (which you probably do have, why would you otherwise ask for them specifically?)

Even with the vast knowledge, there will be gaps. I realized I have to put this to CLAUDE.md:
Code: [Select]
Extremely important detail is 15-minute netting in metering. When choosing between buy price vs. sell price, instantaneous power is irrevelant, only 15-minute energy (avg power) matters. E.g. if buy cost is 10c/kWh and sell cost is 0c/kWh, importing at 2kW for 7.5 minutes, then exporting at 2 kW for 7.5 minutes results in zero bill. These periods are fixed at xx:00, xx:15, xx:30, xx:45. IOW, in billing, at 15-minute level only buy or sell bin is non-zero.

Why this gap? Because the fact that Finland happens to net export/import in electricity metering in 15-minute periods is almost impossible to find out from public sources; basically you need to be an industry insider to know that.

And because many of the tasks Claude needs to reason about need this information, I put it in CLAUDE.md. No mistakes after that, at all; completely gone; it reasons perfectly about the cost modelling and complex chains where using energy somewhere at partially sell_price removes the need of using it somewhere else at buy_price.
 

Offline gspeed

  • Contributor
  • Posts: 49
  • Country: cn
Re: Using Claude Code for embedded work
« Reply #231 on: June 08, 2026, 08:19:07 am »
It does not reason or do anything close to that. It may generate apparently working code very fast (and often with a very beautiful user interface), but if you trust it blindly, it WILL bite you sooner or later.
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 11298
  • Country: fi
Re: Using Claude Code for embedded work
« Reply #232 on: June 08, 2026, 09:25:06 am »
It does not reason or do anything close to that.

So you have not tried, and just have no clue what you are talking about. Strong reasoning skill is some of the most easily verifiable features. You are basically saying "cows do not produce milk", because you have not seen it. For many others, the thing is totally obvious.

Quote
(and often with a very beautiful user interface)

Beauty of user interfaces tends to be usually the most lacking one, needing the most guidance. If you just ask for an UI, it will be some very average, boring one; very acceptable for internal testing, but far from polished. It doesn't have the "eye" professional UI design artists have, and that's exactly as expected from the LLM working with language only.

Quote
but if you trust it blindly, it WILL bite you sooner or later.

No shit sherlock - that's obvious, but that's obvious also with any alternative way of development, and especially with human workers. And it has absolutely nothing to do with reasoning. Blind trust can only come from perfect communication of requirements, AND never doing any mistakes, both features which are impossible with all human workers and all AI systems in existence, and this is not changing anytime soon if ever. Blind trust is a unicorn you should not be chasing.
« Last Edit: June 08, 2026, 09:30:53 am by Siwastaja »
 

Offline paulca

  • Super Contributor
  • ***
  • Posts: 6507
  • Country: gb
Re: Using Claude Code for embedded work
« Reply #233 on: June 08, 2026, 09:52:20 am »
It also deals with problem-spaces that aren't that well populated on the internet.

You just aren't looking with the right eyes, tools, experience or information.

What you might want to consider.  "Software patterns are fractal".  They appear at almost all levels of abstraction and all mediums, all languages, all industries.

So, when you engage an AI outside of it's scope into a completely unrefrenced model of the code it will, with your help, match software patterns and then attempt to apply them.

It will see an enumeration pattern, a deligate pattern, a filter pattern, a non-destructive filter versus a destructive one etc. etc.  The electronics parallel if I can reach for it, is a skilled electronics person with a life career in geological sensors, finding himself in a lab making consumer gadgets, does not need an RC filter or a crowbar explained to him.
"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: 6507
  • Country: gb
Re: Using Claude Code for embedded work
« Reply #234 on: June 08, 2026, 10:03:00 am »
It does not reason or do anything close to that.

I agree, I don't think you have used it really.  You have not tried to reason with it.  And I don't mean, tried to trick it.  How would you approach an individual at work to determine if they can reason or not?  Try that.

Also.  I would restrict the reasoning domain to be reasonable.  For example.  The "Upside down cup problem" is real.  It highlights they have no "mental model" of space, time, geometry.  They literally cannot "picture the cup" and "turn it upside down in their minds".  They don't have the hardware.  You can attempt it and it will reason, but it effectively becomes a wierd academic debate, much like, "How do you know, when you say, blue, that we see even remotely the same thing?"

Images and it's ability to "grok" them is highly debatable.  The tech basically tokenises the images into pels and feeds them to the "language model".  It can match patterns, reason in a robot way about that (its on the left, its on the right, it's below, it's above) but they cannot "see it" and have no "aesthetic" sense.

If you want to "see" the internal reasoning.  Use an unfiltered offline model.  Or an online model that will expose the 'thinking' to you.  Its fairly bizarre.  It will start to generate a response, then stop itself and check alignment with the user prompt.  Self critique the match and start again.  It will do this a LOT.  It can be quite choatic and frankly... on an unfiltered raw open source model, a bit disturbing.


"What could possibly go wrong?"
Current Open Projects:  68000 Self Build computer + OS.
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 11298
  • Country: fi
Re: Using Claude Code for embedded work
« Reply #235 on: June 08, 2026, 01:10:43 pm »
What you might want to consider.  "Software patterns are fractal".  They appear at almost all levels of abstraction and all mediums, all languages, all industries.

So, when you engage an AI outside of it's scope into a completely unrefrenced model of the code it will, with your help, match software patterns and then attempt to apply them.

It will see an enumeration pattern, a deligate pattern, a filter pattern, a non-destructive filter versus a destructive one etc. etc.  The electronics parallel if I can reach for it, is a skilled electronics person with a life career in geological sensors, finding himself in a lab making consumer gadgets, does not need an RC filter or a crowbar explained to him.

Exactly, and the same is true for everything else, not just programming: everything we do is covered by countless of analogies into something else we did earlier. LLM is good at finding those analogies, sometimes getting enthusiastic to tell you about them even if you don't ask. Ask and it will give as many as you want, and they are more or less spot-on.

LLMs match patterns and that's not some sort of "proof they don't work", quite the opposite, that's exactly the reason why they do work, because human brain is pattern matcher as well.

And this is exactly why large models are better than small models even if the efficacy looks bad ("I don't need 99.9999% of that raw information for this task"), they have more "life experience", so similar problems in training corpus, which they can apply as analogies - as their basis for reasoning. "Doing X worked on Y, which is similar - hmm, what happens if I try it here - wait, Z is different, let me check A, B and C. Wait, B prevents G from working, so can we do something about it..." - this is what LLM reasoning looks like, and it's very similar from human reasoning because it learnt the process of reasoning from humans.
 

Offline paulca

  • Super Contributor
  • ***
  • Posts: 6507
  • Country: gb
Re: Using Claude Code for embedded work
« Reply #236 on: June 08, 2026, 02:35:33 pm »
The catch is... it doesn't feel anything when its wrong and it doesn't even sleep, so it won't sit up at night worrying about the code either.
"What could possibly go wrong?"
Current Open Projects:  68000 Self Build computer + OS.
 

Offline SpacedCowboy

  • Frequent Contributor
  • **
  • Posts: 448
  • Country: gb
  • Aging physicist
Re: Using Claude Code for embedded work
« Reply #237 on: June 08, 2026, 07:06:26 pm »
It also deals with problem-spaces that aren't that well populated on the internet.

You just aren't looking with the right eyes, tools, experience or information.

I think we're making the same point. I'm saying that "even though the LLM is unlikely to have found anything like what I'm asking it to do, it still performs well because it can generalise from the model of what it has found".

The comment was to refute that made by ralphrmartin who was claiming "these tools are great for straightforward tasks of the kind where there are plenty of materials / hints online (web page stuff, for example), but less so for specialised coding and uncommon tasks"

I'm aware of how neural networks work, I have a doctorate in the topic, and even though it was a long time ago (in a galaxy far away) and things have indeed changed significantly, the fundamentals are still the same.
 
The following users thanked this post: paulca

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 11298
  • Country: fi
Re: Using Claude Code for embedded work
« Reply #238 on: June 09, 2026, 08:36:59 am »
The comment was to refute that made by ralphrmartin who was claiming "these tools are great for straightforward tasks of the kind where there are plenty of materials / hints online (web page stuff, for example), but less so for specialised coding and uncommon tasks"

That was a valid observation 4-5 years ago, when ChatGPT was new and shiny and amazing at producing plausible looking, grammatically correct text littered with errors and hallucinations. It was able to produce code which also compiled and ran often on a first try, or at least after a few iterations "hey this doesn't work" "Good catch -- try this" - still possibly thousands of lines worth, something it would take a day for human to produce, within just minutes. So it was amazing, but when people actually tried to apply it for serious software development, they quickly saw just what ralphmartin was saying: it's just varying highly common patterns in direction of user requests: useful for those (often beginners) who need something outside their core expertise quickly, but where almost-there solutions commonly exist; basically automated version of "copy-paste random stuff from Stack Overflow".

But some saw the potential - let's pour more money, more resources, more research into this problem, and it will magically become a real, generic thinking machine. And despite all naysaying, that's exactly what happened. Easier to see in retrospect, and kind of funny that some still deny the facts easily observable to everyone; hence my "cows don't produce milk, prove they do!" analogy.

Two significant changes are visible and understandable even to us non-AI-experts: model size, and introduction of thinking (reasoning) phase, a separate step where the model outputs reasoning in natural language, which shifts the probability landscape (which is the context, including the user prompt, but also the reasoning text the model is outputting), for the model to create the final answer. But even this isn't anything new, really; Deepseek did a great job years ago exposing that thinking phase to users through a button from which they can enable it. That shifted the discussion from "It's not reasoning!" to "OK, it IS reasoning, but doing mistakes nevertheless" - so it's kind of funny to see someone in 2026 claim that LLMs do not reason at all, when that's exactly what they do, and it's so easily observable to anyone willing to try.
 

Offline peter-hTopic starter

  • Super Contributor
  • ***
  • Posts: 6078
  • Country: gb
  • Doing electronics since the 1960s...
Re: Using Claude Code for embedded work
« Reply #239 on: June 09, 2026, 08:58:36 am »
I've just spent 2 days on a "computer graphics" job with Claude and clearly it does not write code the way a human coder would (should). It tries just about everything until the result works (or doesn't). Eventually one gets there although I've been on the last one for a whole day, sending it pics of the LCD...

That said, the end result would have taken a human a lot longer to do.

UPDATE: I got my 2nd (free) Claude on the job and it solved it in just a few iterations! I then gave the code to Claude #1, who commented "that's a completely different approach..." :) I have repeatedly found this 2nd Claude to be more clever. It also shows the code on a panel on the right, which I can't do on #1. And it does not highlight function names with a black background like #1 does... Claude #1 has no idea how to configure this.

Claude #2 looks like this (never mind the Chinese buttons)


EDIT: turns out that to get the above, you need to enable Artifacts, and tell Claude to send code to the Artifacts panel instead of inline. Both are painfully slow but inline is even slower. Also there is a UI bug that you have to scroll to the bottom of the code (in either mode) before pressing Copy, otherwise you get only a partial copy.

Quote
But some saw the potential - let's pour more money, more resources, more research into this problem, and it will magically become a real, generic thinking machine. And despite all naysaying, that's exactly what happened. Easier to see in retrospect, and kind of funny that some still deny the facts easily observable to everyone; hence my "cows don't produce milk, prove they do!" analogy.

True but it still does weird stuff e.g. I am drawing some text in narrow20, and I asked it to change to narrow15. It did that but completely pointlessly did a random change elsewhere, which broke some stuff. One realises it is not deterministic (whatever that means).
« Last Edit: June 09, 2026, 01:20:56 pm by peter-h »
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 11298
  • Country: fi
Re: Using Claude Code for embedded work
« Reply #240 on: June 09, 2026, 03:21:05 pm »
True but it still does weird stuff e.g. I am drawing some text in narrow20, and I asked it to change to narrow15. It did that but completely pointlessly did a random change elsewhere, which broke some stuff. One realises it is not deterministic (whatever that means).

Your problem is in the harness. You are using the Claude's generic web UI, which is not really designed for programming, to do programming. This is what people experimented with 5 years ago. In that setting, programming is "read prompt, write code, rinse and repeat", and rewriting the code is not only wasteful, it introduces random changes.

Programming agents, like Claude code, operate differently; they read code, decide what needs to be changed, do spot reads around the area, and edit (not rewrite) code here and there. As a result, no pointless random changes elsewhere.
 

Offline ralphrmartin

  • Frequent Contributor
  • **
  • Posts: 519
  • Country: gb
    • Me
Re: Using Claude Code for embedded work
« Reply #241 on: June 09, 2026, 06:44:18 pm »
Write a java modern opengl program using the JOGL libraries to draw a rotating cube illuminated with phong lighting. This program is to run on a Mac with an Apple Silicon processor.

That's an interesting test - so you are giving it very strict constraints, and not helping it out achieving it. Interesting follow-up to this test would be:
1) give it more freedom: "Write a program that draws a rotating cube on Mac with an Apple Silicon processor, with the framework you feel confident with"
2) if you want those exact libraries, help it out; give your experience/insight on those libraries (which you probably do have, why would you otherwise ask for them specifically?)

I wanted it to generate a working skeleton program, which I could then modify myself to turn into a real application.
I particularly wanted to use java / those libraries, as I am familar with java.

I couldn't help it out. I was asking it as I couldn't get this working myself.

 

Offline SpacedCowboy

  • Frequent Contributor
  • **
  • Posts: 448
  • Country: gb
  • Aging physicist
Re: Using Claude Code for embedded work
« Reply #242 on: June 09, 2026, 08:07:37 pm »
I admit to being mildly curious as to why Claude would have such difficulty with what (at first glance) doesn't appear to be an onerous task for it. I know very little about Java but I figured it'd be a learning experience as to why it didn't work so I spent the time to see what it would do.

I used the exact same prompt "Write a java modern opengl program using the JOGL libraries to draw a rotating cube illuminated with phong lighting. This program is to run on a Mac with an Apple Silicon processor"

Initially we ran into an issue because jogamp.org doesn't seem to be serving JAR files, but Claude tried first with HTTP GET, then with Curl, then decided it ought to go to "Maven Central" (whatever that is) where there are mirror files. It then fetched the JAR files.

Then it wrote src/PhongCube.java

Then it wrote run.sh to invoke things correctly - with a minor hiccup because it didn't provide the best arguments the first time, it corrected itself and the app ran.

Attached is a (very) short video of the cube running, it's a MOV in a ZIP because apparently you can't attach MOV files. Here is the entire directory (including the JAR files, src, and a transcript of the entire session)

Took 5-8 minutes. Worked first session. So, it seems to work for me  :-+


« Last Edit: June 09, 2026, 08:21:27 pm by SpacedCowboy »
 
The following users thanked this post: skench, Siwastaja

Offline peter-hTopic starter

  • Super Contributor
  • ***
  • Posts: 6078
  • Country: gb
  • Doing electronics since the 1960s...
Re: Using Claude Code for embedded work
« Reply #243 on: June 10, 2026, 06:41:38 am »
Does anyone know where this silly colour scheme is configured?



This is on the paid Claude; the free one looks like this



Claude doesn't know :)
Z80 Z180 Z280 Z8 S8 8031 8051 H8/300 H8/500 80x86 90S1200 32F417
 

Offline paulca

  • Super Contributor
  • ***
  • Posts: 6507
  • Country: gb
Re: Using Claude Code for embedded work
« Reply #244 on: June 10, 2026, 07:46:09 am »
I've tried with a whole range of models and multiple coding agents. None of them gave a working solution ebven after lengthy interaction trying to explain what went wrong.. My conclusion at this point: these tools are great for straightforward tasks of the kind where there are plenty of materials / hints online (web page stuff, for example), but less so for specialised coding and uncommon tasks. I'm surmising here, but I suspect similar issues could arise for less widely used microprocessors/controllers, or obscure embedded problems.

The tools are great for straightforward tasks in unskilled hands.  In skilled hands they go a lot further.

Your use case sounds simple.  As a professional Java progammer of 10+ years, I can tell you it's not.  Nor is it simple if you had the entire corpus of what Claude has 2026.

It's not even likely to be a code problem you will face.  It will be an environmental one.  A JVM one.  A JVM setup one.  An OS driver setup one etc.

As a similar example (?) I asked it to setup a Raspberry PI 2350 dev board for "Bare RISC-V ASM Blinkie".

After 6 builds and "dead MCU" I gave up.

I was not driving, I was not in the loop, I was not even paying attention I was just hitting "Yes", "Yes and don't ask".

So you could say that claude did nothing useful, right?  Well, the thing is, it is likely to be one or a small number of "dumbness" slipped in somewhere, a missed step, a missing parameter on the memory segments, alignments, maybe even an assumption about the particular dev board or RISC-V core boot process.

I have no idea.  Because I was not in the loop and have no idea what it did.  All I read was the ASM code at the bottom and it looked "ok".

This is me as an amatuer asking for "the moon on a stick" and unable to help claude out.

Does this make claude useless?  No.  I expect if I took your task and you took mine, we would probably be able to get the projects working if we guide claude.  The important part would be, how quickly with and how quickly without claude?
"What could possibly go wrong?"
Current Open Projects:  68000 Self Build computer + OS.
 

Offline Siwastaja

  • Super Contributor
  • ***
  • Posts: 11298
  • Country: fi
Re: Using Claude Code for embedded work
« Reply #245 on: June 10, 2026, 09:53:59 am »
Took 5-8 minutes. Worked first session. So, it seems to work for me  :-+

Hush! You are not supposed to replicate the "AI does not work" experiments! Let's keep believing it doesn't work!  >:D
 

Offline ralphrmartin

  • Frequent Contributor
  • **
  • Posts: 519
  • Country: gb
    • Me
Re: Using Claude Code for embedded work
« Reply #246 on: June 10, 2026, 11:19:24 am »
I admit to being mildly curious as to why Claude would have such difficulty with what (at first glance) doesn't appear to be an onerous task for it. I know very little about Java but I figured it'd be a learning experience as to why it didn't work so I spent the time to see what it would do.

I used the exact same prompt "Write a java modern opengl program using the JOGL libraries to draw a rotating cube illuminated with phong lighting. This program is to run on a Mac with an Apple Silicon processor"
I am assuming you ran the generated code on a Mac?

I have to admit it was a couple of months back I tried this.
 A major problem I hit at first was it could not find the right version of of the jogamp files including the native libraries.
Then it could not get jogl to work with swing java windows without errors, and sent me down a rabbit hole of trying to fix that.

Your video shows a couple of defects which presumably are readily fixable: the light source is rotating as well as the object, and the cube does not appear to be shiny (specular refletion, which is the point of the phong model).

But I have to admit that it is basically working.

 

Offline ralphrmartin

  • Frequent Contributor
  • **
  • Posts: 519
  • Country: gb
    • Me
Re: Using Claude Code for embedded work
« Reply #247 on: June 10, 2026, 11:26:24 am »
Hush! You are not supposed to replicate the "AI does not work" experiments! Let's keep believing it doesn't work!  >:D

I'm not saying I don't believe it works. I have successfully used it to improive some code for driving a thermal printer directly, and for fixing errors in embedded code for a climate logger. I was trying to say that results may not always be as hoped for in cases where there is limited training data relevant to the problem.

Amyway, engineers should base their work on evidence, not belief!
 

Offline smokeless0864

  • Contributor
  • Posts: 16
  • Country: hu
Re: Using Claude Code for embedded work
« Reply #248 on: June 10, 2026, 11:26:44 am »
Is it possible to configure Claude addon in VScode for inline code completion?

It's a lot nicer if it tries to figure out what I'm going to type next, than me having to specify it in chat.

Just like Github copilot, but I don't want to pay for both.
 

Offline SpacedCowboy

  • Frequent Contributor
  • **
  • Posts: 448
  • Country: gb
  • Aging physicist
Re: Using Claude Code for embedded work
« Reply #249 on: June 10, 2026, 12:39:03 pm »
I am assuming you ran the generated code on a Mac?

Yep, it's on an M4 Max MBP, running Sequoia (15.6.1)

I have to admit it was a couple of months back I tried this.
 A major problem I hit at first was it could not find the right version of of the jogamp files including the native libraries.
Then it could not get jogl to work with swing java windows without errors, and sent me down a rabbit hole of trying to fix that.

Yep, I had the same issues with libraries, it couldn't pull from the original source, but it knew some mirror location ("maven") and pulled them from there. To be honest, I'm kind of surprised it found java on the MBP, I can't imagine what I would have had that installed for, but anyway it just pulled everything down, wrote the files, and a script to run it. That entire archive is available at the link in my original post about this, it ought to work on any Mac that has java/javac installed.

Your video shows a couple of defects which presumably are readily fixable: the light source is rotating as well as the object, and the cube does not appear to be shiny (specular refletion, which is the point of the phong model).

But I have to admit that it is basically working.

I'm not a 3D expert :) I thought the phong one was the matte one, but I consulted Claude about it and it found the bug and explained it in terms even I could understand:

Code: [Select]
❯ so the source in this directory was in response to "Write a java modern       
  opengl program using the JOGL libraries to draw a rotating cube illuminated   
  with phong lighting. This program is to run on a Mac with an Apple Silicon   
  processor" but it seems to be rotating the light as well as the cube, and I   
  don't see the shiny reflections I'd expect for phong shading                 
 
⏺ Let me look at the source code to diagnose both issues.
 
  Searched for 1 pattern, read 1 file (ctrl+o to expand)

⏺ I found it. Let me walk through the bug, because it's a single root cause that
  produces both symptoms you're seeing.

  The bug: a transposed normal matrix

  Your lighting is done correctly in world space — uLightPos is a constant (1.6,
  2.0, 3.0) and never rotates. So in principle the light should stay put while
  the cube spins. The problem is the normal matrix (Mat4.normalMatrix, lines
  382–411). It's transposed relative to what it should be, so the normals get
  rotated by the inverse of the cube's rotation.

  Here's the chain (model is a pure rotation O):

  - The desired normal matrix is transpose(inverse(O)), which for a rotation
  equals O itself — normals rotate with the cube.
  - But the code reads the upper-left 3×3 from the column-major array into a,b,c
  / d,e,f / g,h,i as if it were row-major, so the matrix it actually inverts is
  Oᵀ, and then it writes the result back out row-major again. The two
  transpositions don't cancel — they compound into one net transpose. The matrix
  that reaches the shader is O⁻¹ (= Oᵀ for a rotation), i.e. the inverse
  rotation.

  So your cube's positions rotate one way while its normals rotate the opposite
  way. That's exactly why:

  1. The light "rotates with the cube." The shading no longer tracks the surface
  — the bright region counter-rotates against the geometry, which reads
  visually as the light being attached to / spinning with the cube instead of
  staying fixed in the room.
  2. No specular highlights. reflectDir = reflect(-lightDir, norm) is computed
  from wrong normals, so the highlight never lands where the view vector can
  catch it — the glossy spot effectively disappears.

  The fix

  Transpose the returned mat3 — emit the inverse in column-major order instead
  of row-major:

It then fixed the code, I ran it and it produced a rotating cube with a light that seems to be fixed to me. The cube gets a light-pattern looking like (one snapshot):


It also said:
Quote
One optional tweak if you want the highlights more obvious: your light (1.6, 2.0, 3.0) sits almost on top of the camera (2.6, 2.0, 3.4), which flattens the shading. Pulling the light off to one side (e.g. (-1.5, 3.0, 2.0)) gives stronger, more directional highlights and shadow gradients. You could also increase the shininess and specularStrength

So I asked it to do that and give me a really glossy look (since that seems to be what you were after), and it told me that to get truly glossy output, I'd need to switch away from a cube (with its constant normals) and model a sphere instead - or at least some curved surface with varying normals. I said "go ahead" and we got:



Now of course, a featureless sphere with a stationary light doesn't look like it rotates, so I asked it to "add some surface detail so we can see the rotation", which led to the movie in the attached ZIP file (again, can't upload actual MOV files).


« Last Edit: June 10, 2026, 12:51:51 pm by SpacedCowboy »
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf

 

-->