Using Claude Code for embedded work

[paulca]

Connect to serial.

>  BIT
<system runs "built in test" and reports>

Claude runs this and the report output is in context.

It could be that simple.

[hans]

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?

Maybe, in the future. Came across this on Github the other day: https://github.com/lollokara/BugBuster/tree/main

Yes, you can now have AI tell your voltage regulator is not set up correctly. Instead of multimetering your input and output voltages, just solder on a tons of wire and let AI do it for you.
Ofc it can't check wrong bad pin amps (ironically this device also has a pin map), intermittent connections, incorrect part mounts.. probably the most common mistake for any engineer...

OTOH if you need a DFM test jig anyhow, maybe you can recycle the hardware if its PC controlled anyway.
Inb4 someone puts Sensepeek like probes on a 4-axis table (XYZ+board flip) and have AI handle that for you, as well.

[SpacedCowboy]

One thing I will mention is that you'll probably end up with a lot more regression tests that you're used to, or perhaps that's just me

The 6502 compiler has a testing framework with some 400 or so tests in it that test internal integrity of the build using ObjC code, and a 'fixtures' directory that contains some 107 files which collectively add 505 (as I write) regression tests. This is a project that's about 10 days old...

Code: [Select]

elysium:xtc % ls tests
codegen lexer run_fixtures.sh XTTestRunner.m
fixtures parser sema XTTestRunner.o
generate preprocessor XTTestRunner.d

elysium:xtc % ls tests/fixtures
ahl.xt                      included.xt            shadow_ram.xt
asm_block.xt                inline_params.xt       shifts.xt
asm_var.xt                  inline-leaf-fn.xt      sign_extend.xt
banked_call.xt              inline.xt              sort_qsort.xt
banked_xcall.xt             inliner_ordering.xt    stack_class.xt
byte_list_init.xt           int_arith.xex          stack_size.xt
cast_widen.xt               int_arith.xt           stale_x.xt
classes.xt                  irq_vbi.xt             static_frame.xt
cloaked_hello.xt            largevar.xt            static.xt
cloaked_helper_promotion.xt length_prop.xt         string.xt
cloaked_method_args.xt      literal_widen.xt       struct_byval_rvalue.xt
cloaked_transitive_clean.xt logops.xt              struct_byval.xt
comments.xt                 loops.xt               struct_copy.xt
constant.xt                 macro.xt               struct_deref_field.xt
double_add.xt               many-structs.xt        struct_field_rvalue.xt
double_const.xt             many-vars.xt           struct_return_expr_large.xt
double_cvt.xt               math_pow.xt            struct_return_expr.xt
double_div.xt               maths.xt               struct_return_field.xt
double_math_lnexp.xt        mixed_arith.xt         struct_return_spill.xt
double_math_trig.xt         modulus.xt             struct_wide_field.xt
double_math.xt              mul_u8u8.xt            structs.xt
double_mul.xt               multi-call.xt          subscript_float.xt
double_ops.xt               negative               subscript_large.xt
double_pow_i16.xt           numbers.xt             subscript_member.xt
double_rand.xt              overload_ambiguous.xt  subscript_store.xt
double_sqrt.xt              overload_class.xt      subscript_struct.xt
enums.xt                    overload_widen.xt      switch_stmt.xt
float_arith.xt              overload.xt            ternary.xt
fn_pointer.xt               placement.xt           test_retain.xt
funcptr.xt                  printf_call_arg.xt     test_ARC.xt
global_init.xt              printf_class.xt        trig_range.xt
heap_basic.xt               printf_cloaked_u16.xt  va_arg_struct.xt
heap_multibank.xt           printf_cloaked_u32.xt  valist.xt
heap_retain.xt              printf_double.xt       varargs.xt
hello.xt                    printf_float.xt        wide_args.xt
ifthen.xt                   printf.xt
include.xt                  printi32.xt

That's a fair amount of regression testing for such a young project, at least by my standards. Don't get me wrong, it's great. It's definitely an improvement over what I'd usually do by now

[gamalot]

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?

Maybe, in the future. Came across this on Github the other day: https://github.com/lollokara/BugBuster/tree/main

Maybe it's not a bad idea, but those schematics are a headache to look at. I'm not trusting anything designed by someone who draws diagrams that messy. 

[peter-h]

It's gonna be fun when "AI" gets into PCB layout

[paulca]

It's gonna be fun when "AI" gets into PCB layout

Been discussed elsewhere and presently it is dire at the moment.

The issue is that schematics and pcb layout are "visual" and "spactial" which are their two greatest weaknesses.
 

[paulca]

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

Interestingly, CC does not "look" at the HTML at all.  No visually.  It's entirely based on the frameworks like react abstracting a lot of it away.

On "enterprise' code in business claude has an advantage.  In that space making code as consistent as possible is very proveilant.  So it's a good thing when the code all looks the same.

"Cookie cutter" is the name for it.  Cookie cutter webapis have got such good tooling these days it was almost completely autogenerated before we had Claude.  In fact there are now debates on whether we should abondon such "Spec->Code" generation layers, if we can just use CC to generate the code.  These people are failign to understand what "Spec->Code" generation gives you that claude generation doesn't.  Deterministic output.

[peter-h]

Interestingly, CC does not "look" at the HTML at all.  No visually.

That is surely useless. So many websites have weird browser version compatibility issues. And it looks like not many coders give a toss.

Perhaps not really on the "embedded" topic but you might well have a web server in your product. I have one; it was quite a bit of work but Claude was not around then. It hooks into LWIP (uses its netconn API rather than sockets) in a primitive way and generates the simplest possible HTML (from my C code - what else?) to produce simple text menus, and I paid some guy on freelancer.com to write some javascript which runs client-side and implements stuff which is not possible with plain HTML e.g. a progress bar on file uploads (a browser gives you a % progress on downloads).

[paulca]

Oh devs give a toss alright.  The only things that make browser apps feasible are frameworks like Angular and React.  Also smaller things like JQuery and such like.  These handle the browser specifics.

Most modern HTML pages are 'responsive' anyway.  So the actual layout depends on your font size, zoom level, screensize etc.  Some people see 4 columns, some see 2.

[peter-h]

I know how it is supposed to work but the reality is that many websites have little bits that are broken with browser x and not with browser y. Or tightly browser version dependent.

I probably know just enough about this to know that there is really no need for such issues. I "run" a site which was done c. 2010 and which is fully functional today. It uses the Bootstrap (ex twitter) style sheet package.

I accept that few people want to spend much time on this and most just want to drop in some library ("framework").

[paulca]

I know how it is supposed to work but the reality is that many websites have little bits that are broken with browser x and not with browser y. Or tightly browser version dependent.

I probably know just enough about this to know that there is really no need for such issues. I "run" a site which was done c. 2010 and which is fully functional today. It uses the Bootstrap (ex twitter) style sheet package.

I accept that few people want to spend much time on this and most just want to drop in some library ("framework").

It looks that way to you, because you are on a PC as old as your website.  Most people are not.

Put bluntly.  You live in a self created bubble where the world stands still and software stays static.  In the real world, the browsers update basically weekly, the operating systems update nearly daily.  Some corporations are legally required to be on the latest and greatest.

So React/Angular and JQuery update almost constantly, but also tend to take large jumps.  So 1.1 -> 1.2 fine.  1.7->2.0 half rewrite.  Stay on 1.x and lose modern browser quirk support.... and eventually security fixing.

On testing.  There are not 2 or 3 browsers.  There are an infinite number of combinations, that are barely restricted by browsers.  The "standard" they implement are almost always varied in some way so they don't work exactly like each other.  Testing those webapp frameworks requires thousands of people.

Also.... Why do you not just add a webserver to your own application?

You can.  It's a common approach in most Java applications, for instance.  They use Jersey or similar micro-webserver component for the main HTTP handlers.  Most Microsoft stack stuff uses the DotNet HTTPListener stack.

If you mean write it yourself, you need to make sure it's secure.  If you want "normal" people to access it, you have to be aware that without HTTPS normal Joe is going to get nervous when it says, "Your connection is insecure!"  A lot of modern browsers will just immediately change HTTP to HTTPS and your user gets a "Connection refused" on port 443. So you will need to HTTPS it to stop that nasty warning.  If you use a self-signed cert, the user will get a worse error saying you are not who you say you are.  A proper HTTPS certificate for your MCU project is going to cost you at least $200.  Or you could use "LetsEncryupt" and update it every 90 days.

In fact if you want your HTTP server, flashed on your micro to have ANY security certificates, you will need to pay hansomly for "long lived certs", like 10 years.   Your device still bricks after that.  If you want/need HTTPS and certs your micro has no choice, but to implement a full CertAuth resigning/cert request renewal process. 

Give it a wide open, authless, HTTP port and an admin interface and no professional network will want it near them.

Then there is IPs and DNS names.  How are you going to handle that?  What IP does the device get in the users environment?  How can you point a DNS name at it? What do you tell users to put in the URL?

Being honest.  Your best option would be to make the MCU an HTTPS "client".  HTTPS or whatever you want to communicate with your backend as client.  Then do the web layer somewhere you have proper mutable access and supporting infra.  Yes, I know that today that means cloud for most wide distribution products.

This is made simplier by choosing a form of "Middleware".  Like MQTT or other message bus.  Then you have a single point of integration shared by all distributed components.

[peter-h]

I don't actually live in a bubble, but I have my own business, so have no incentive to waste time (like employees do, at least in the short term) so if something works I run with it

I deal with the "latest sw compliance box ticking" all the time. I still regard inadequate browser compliance checking as arrogant and negligent. And that's before we reach the full "win11 screwing" scenario (chrome still fully updates on win10) where millions have to chuck out their PCs and laptops to run this latest POS just to get a browser which they can use for their banking etc...

If you mean write it yourself, you need to make sure it's secure.  If you want "normal" people to access it, you have to be aware that without HTTPS normal Joe is going to get nervous when it says, "Your connection is insecure!"  A lot of modern browsers will just immediately change HTTP to HTTPS and your user gets a "Connection refused" on port 443. So you will need to HTTPS it to stop that nasty warning.  If you use a self-signed cert, the user will get a worse error saying you are not who you say you are.  A proper HTTPS certificate for your MCU project is going to cost you at least $200.  Or you could use "LetsEncryupt" and update it every 90 days.

In fact if you want your HTTP server, flashed on your micro to have ANY security certificates, you will need to pay hansomly for "long lived certs", like 10 years.   Your device still bricks after that.  If you want/need HTTPS and certs your micro has no choice, but to implement a full CertAuth resigning/cert request renewal process.

Give it a wide open, authless, HTTP port and an admin interface and no professional network will want it near them.

We went through this when developing this last box. There is no perfect solution (to anything really).

The time may come when Chrome will not work with an http target. Then other browsers may need to be used. Probably Firefox will run for much longer. As you say, the https certificate has no permanent solution.

If this ever becomes a problem then we may have to do something else, like map the http interface to USB VCP and then people can run Teraterm or whatever. It has no graphics. Well, there is a favicon, all coded in C

The http server has a username+pwd, btw, plus can be turned off in a config file (on the USB MSC volume), plus can be restricted to one client IP, and has a timeout. Fine for remote access via a VPN whose LAN IP is known and fixed.

We did have an https server on there, done with MbedTLS, and a self signed certificate, but a self signed cert is arguably worthless for the same reasons you give. A given browser could refuse it for the same reason. I actually think there is a greater risk of Browser X refusing https with a self signed cert, than refusing http (on what is obviously a local network IP). In the end, due to finite RAM, we decided to do the http server instead. It took only a day to do the https server, with Cube MX, to a level good enough to impress the boss and nothing else useful, which sums up MX pretty well.

Back to Claude, I can see one could connect Claude up to this, but that will work only if it is more or less all working and Claude is doing other odds and ends.

[jc101]

Slight tangent, but re the Lets Encrypt and 90 days mentioned in the post above. Isn't it the case that paid for certificates will be need to be reissued every 47 days in a couple of years time?

[peter-h]

Yes the whole trend in this game is for certs to have a short life, so you need a cron job to keep getting new ones, and you need to pay a good server admin (from Poland, Ukraine, etc ) to fix it every time the cron job breaks and your customers moan that your site is insecure

I have this on one server already. For others I use Cloudflare and they take care of it. Not possible on embedded...

[paulca]

I have this on one server already. For others I use Cloudflare and they take care of it. Not possible on embedded...

That is the middle ground most people who can host remotely end up in.  When looking at a genuine "first level" cert you are talking hundreds of dollars and that has renewal costs every few years too.

Hosting on AWS or Azure however and you can get a sub-cert for your domain added to the AWS master cert.  This cert is enough to validate your website IS the domain it says it is and that a server responsible for it served you the request.  It does NOT verify you as a business or any "identity" beyond the domain name though.  It's 99% sufficient for most needs though.

A cloud proxy like cloudflare can also 'HTTPS' wrap requests and even "main in the middle" them with custom self-signed certs.

If your user base are "within your control", such as on a business LAN, a self-signed cert can be used and "force imported" onto users corporate machines.  Or just require them to install your CA root cert into the browser.

Within the foot print of a small Micro, like not an H7.  The "self renew" system might be doable.  Just add a "Cert update" admin page to the web ui, that lets you upload the new cert.  This will become a problem for highly distributed products of course and for those you need it to be automatic.  The device will want to "phone home" periodically and check for a certificate renewal.

Did you hard code a changable IP like 192.168.1.1 like every router out there?  Or did you attempt DHCP?  For DNS there is mDNS which a lot of browsers support and is "peer to peer" all nodes are client and server and they self distribute new-comers.  So your device has it's own DNS and others can ask it, "WHat are you called?"  It means your host names all end in ".local" though and I believe it's limited to the broadcast domain.

[peter-h]

I have an automatic check for a new cacert.pem and an auto update. So that takes care of the https client functionality (the box can authenticate the server).

Did you hard code a changable IP like 192.168.1.1 like every router out there?  Or did you attempt DHCP?  For DNS there is mDNS which a lot of browsers support and is "peer to peer" all nodes are client and server and they self distribute new-comers.  So your device has it's own DNS and others can ask it, "WHat are you called?"  It means your host names all end in ".local" though and I believe it's limited to the broadcast domain.

The box can do either DHCP or user defined fixed.

[paulca]

We are getting off topic, but in professional networks, that class of device, like routers, switches, wifi gizmozs and anywhere "hardware" provided interfaces are involved, they are quarantined into a VLAN or in some cases a separate physical network with airgap, at least on the "Admin" side of things.

This means that nobody stumbling around on 'user networks' will find it and anyone deliberately looking for it will need to get through the firewall or do some funky VLAN hackery.

Most of those kind of devices support putting the admin interface onto a VLAN specifically, or having two physical network ports.  One for "normal use" and the other for "Admin only."

Just throwing ideas at you.

[paulca]

On clauding for embedded.

Background:  My "soft DSP on STM32H7" is acting up and the drivers PC side no longer seem to cover it.  The DSP SAI code, I suspect, it not handling the "Frame ailgnment, overrun, underrun etc. etc." errors on the channels.  So if the frame alignment slips, my code just carries on regardless.  A solution "might" be the reset the SAI channel when this is detected and force realignment, causing a "click", but only one of them.

So I have prompted claude this morning with nothing but:

This code has been running on my STM32H7 'soft' DSP for a few years.  It has an issue.  The I2S frame alignment slips, causing poor stereo spearation and "fizzling" and "clicking".

Claude took about 15 minutes.  About 1:28 to produce the inserted spec (below) of what the code does.  Then the rest to "think" things through.

It resulted in this:

                 
● Now I have a clear picture. Let me explain the root cause and then fix it.
                                                           
  Root Cause                                                                             

  There are two bugs that conspire to cause frame slip:                                                                                                               
                                                                                         
  1. SAI_FIFOTHRESHOLD_FULL on the receiver (main.c:279): The FREQ interrupt fires when all 8 FIFO slots are full. The ISR reads only 2, leaving 6. The "margin" before
   overflow is just 2 more samples (~42µs at 48kHz stereo). Any brief ISR latency overflows the FIFO.                                                                 
  2. OVRUDR (overrun) interrupt is not enabled or handled: When the FIFO overflows, SAI_xSR_OVRUDR is set and incoming samples are discarded. Without handling it, the
  code keeps reading stale data from the frozen FIFO. Per the STM32H7 reference manual, clearing OVRUDR resumes from "the next audio frame" — the hardware re-locks to
  WS and starts at slot 0 (L) again — but since nobody clears it, the FIFO contents are undefined and L/R alignment is permanently broken until power-cycle.           
                                                                                                                                                                       
  The fix has three parts: reduce the threshold to make overflow nearly impossible, enable OVRUDR, and handle it with a FIFO flush + clear.                           
 
● Update(Core/Src/main.c)                                                                                                                                             
                                                                                         
───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
 Edit file                                                                                                                                                             
 Core/Src/main.c
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
 276    hsai_BlockA1.Init.AudioMode = SAI_MODESLAVE_RX;
 277    hsai_BlockA1.Init.Synchro = SAI_ASYNCHRONOUS;                                                                                                                 
 278    hsai_BlockA1.Init.OutputDrive = SAI_OUTPUTDRIVE_DISABLE;
 279 -  hsai_BlockA1.Init.FIFOThreshold = SAI_FIFOTHRESHOLD_FULL;                                                                                                     
 279 +  hsai_BlockA1.Init.FIFOThreshold = SAI_FIFOTHRESHOLD_1QF;                                                                                                       
 280    hsai_BlockA1.Init.SynchroExt = SAI_SYNCEXT_DISABLE;
 281    hsai_BlockA1.Init.MonoStereoMode = SAI_STEREOMODE;
 282    hsai_BlockA1.Init.CompandingMode = SAI_NOCOMPANDING;
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌
 Do you want to make this edit to main.c?
 ❯ 1. Yes
   2. Yes, allow all edits during this session (shift+tab)
   3. No

 Esc to cancel · Tab to amend

I haven't even run CubeMX, it's not installed.  Proving it's correct will be a challenge for me as I have not "tooled up" this project in years.

From here the post is "by claude" (markup mistakes and all):
============================================================================================
Background: This code has been running on my STM32H7 'soft' DSP for a few years. It has an issue. The I2S frame alignment slips, causing poor stereo separation and "fizzling" and "clicking".

I ran Claude Code's codebase analysis over it. Here's what it found:

[spoiler=Claude Code Full Analysis]

COMPREHENSIVE ANALYSIS: STM32H7 DSP AUDIO CODEBASE


1. PROJECT STRUCTURE & OVERVIEW

Directory Layout:

• /mnt/homes/paul/devel/stm32/MixAndEQ/Core/ — Application code
• /mnt/homes/paul/devel/stm32/MixAndEQ/Drivers/ — HAL drivers
• Project: STM32H743VIT6 microcontroller
• Architecture: Cortex-M7 with floating-point DSP
• Audio Sample Rate: 48 kHz
• Data Format: 16-bit signed integer samples

Key Files:

• Core/Inc/SAI.h (lines 1-17)
• Core/Src/SAI.c (lines 1-96)
• Core/Src/main.c (lines 1-602)
• Core/Src/stm32h7xx_it.c (lines 1-399)
• Core/Src/stm32h7xx_hal_msp.c (lines 1-616)

2. I2S/SAI AUDIO INTERFACE CONFIGURATION

SAI Blocks Configured:

1. SAI1 Block A (Input/Receiver) — main.c:275-291

• Mode: SLAVE_RX (receives audio)
• Protocol: I2S Standard
• Data Size: 16-bit extended
• Stereo Mode: Enabled
• Synchronization: Asynchronous
• GPIO Pins (stm32h7xx_hal_msp.c:366-376): PE4: SAI1_FS_A, PE5: SAI1_SCK_A, PE6: SAI1_SD_A

2. SAI2 Block A (Output/Transmitter, Master) — main.c:309-323

• Mode: MASTER_TX (transmits audio, provides clock)
• Protocol: I2S Standard
• Data Size: 16-bit
• Audio Frequency: 48 kHz
• NoDivider: Enabled
• FIFO Threshold: Half-full
• Stereo Mode: Enabled
• GPIO Pins (stm32h7xx_hal_msp.c:403-413): PD11: SAI2_SD_A, PD12: SAI2_FS_A, PD13: SAI2_SCK_A

3. SAI2 Block B (Output/Transmitter, Slave) — main.c:324-336

• Mode: SLAVE_TX (secondary transmit, synchronized to Block A)
• Protocol: I2S Standard
• Data Size: 16-bit
• Synchronization: SYNCHRONOUS (synced to Block A)
• FIFO Threshold: Empty
• Stereo Mode: Enabled
• GPIO Pins (stm32h7xx_hal_msp.c:439-447): PA0: SAI2_SD_B

4. SAI3 Blocks A & B (Additional I/O) — main.c:348-387

• Both configured as SLAVE_RX (receivers)
• Asynchronous operation
• GPIO pins configured but not actively used in ISR

3. DMA CONFIGURATION & BUFFER LAYOUT

BDMA (Backup DMA for SAI) — Not Actively Used for Audio:

• main.c:489-503
• BDMA_Channel0_IRQn and BDMA_Channel1_IRQn enabled but NOT linked to SAI
• Used only for SPI6 (peripheral communication, not audio)

DMA1 (Standard DMA) — Used for UART Debug Output:

• main.c:508-519
• DMA1_Stream0 for USART1_TX (debug output only)
• Not used for SAI audio transfers

Audio Buffers (Small, Interrupt-Driven): — SAI.c:13-16

• rx1Buffer[8] — 8x 32-bit words (32 bytes) in DTCM RAM
• rx2Buffer[8] — 8x 32-bit words (32 bytes) in DTCM RAM
• tx1Buffer[8] — 8x 32-bit words (32 bytes) in DTCM RAM
• tx2Buffer[8] — 8x 32-bit words (32 bytes) in DTCM RAM

Buffer Placement: .dtcm_section (Data Tightly Coupled Memory) — fastest on-chip RAM for low-latency audio processing.


4. I2S INTERRUPT HANDLERS & FIFO-BASED OPERATION

SAI1 Interrupt Handler (Receiver) — stm32h7xx_it.c:308-329

Code: [Select]

void SAI1_IRQHandler(void)
{
  // GPIO flag for debug/monitoring
  HAL_GPIO_WritePin(RxIT_GPIO_Port, RxIT_Pin, GPIO_PIN_SET);
 
  // Check if FIFO interrupt occurred (SAI_FREQ)
  uint32_t itflags   = hsai_BlockA1.Instance->SR;
  uint32_t itsources = hsai_BlockA1.Instance->IMR;
 
  if (((itflags   & SAI_xSR_FREQ) == SAI_xSR_FREQ)
   && ((itsources & SAI_IT_FREQ)  == SAI_IT_FREQ)) {
    // Custom handler: read data directly
    SAI_Rx_Interrupt(&hsai_BlockA1);
  } else {
    // Fallback to standard HAL handler
    HAL_SAI_IRQHandler(&hsai_BlockA1);
  }
 
  // Clear debug flag
  HAL_GPIO_WritePin(RxIT_GPIO_Port, RxIT_Pin, GPIO_PIN_RESET);
}

SAI2 Interrupt Handler (Transmitter) — stm32h7xx_it.c:334-352

Code: [Select]

void SAI2_IRQHandler(void)
{
  HAL_GPIO_WritePin(TxIT_GPIO_Port, TxIT_Pin, GPIO_PIN_SET);

  uint32_t itflags   = hsai_BlockA2.Instance->SR;
  uint32_t itsources = hsai_BlockA2.Instance->IMR;

  if (((itflags   & SAI_xSR_FREQ) == SAI_xSR_FREQ)
   && ((itsources & SAI_IT_FREQ)  == SAI_IT_FREQ)) {
    SAI_Tx_Interrupt(&hsai_BlockA2);
  } else {
    HAL_SAI_IRQHandler(&hsai_BlockA2);
    HAL_SAI_IRQHandler(&hsai_BlockB2);
  }

  HAL_GPIO_WritePin(TxIT_GPIO_Port, TxIT_Pin, GPIO_PIN_RESET);
}
Custom Interrupt Handlers — SAI.c:21-45

Code: [Select]

// Receiver (SAI1): read 2x 32-bit samples from SAI FIFO
void SAI_Rx_Interrupt(SAI_HandleTypeDef *hsai) {
  for(int i=0; i<2; i++) {
    rx1Buffer[i] = hsai->Instance->DR;
  }
}

// Transmitter (SAI2): copy, EQ-process, write back
void SAI_Tx_Interrupt(SAI_HandleTypeDef *hsai) {
  for(int i=0; i<2; i++) {
    tx1Buffer[i] = rx1Buffer[i];
    tx2Buffer[i] = rx1Buffer[i];  // Duplicate to both outputs
  }

  EQ_RunOne(tx1Buffer);   // EQ chain 1 (3 bands)
  EQ_RunTwo(tx2Buffer);   // EQ chain 2 (5 bands)

  // 4 samples = 2 stereo pairs per interrupt
  for(int i=0; i<4; i+=2) {
    hsai_BlockA2.Instance->DR = ((uint16_t*)tx2Buffer)[i];  // Block A output
    hsai_BlockB2.Instance->DR = ((uint16_t*)tx1Buffer)[i];  // Block B output
  }
}

Interrupt Flags:

• SAI_IT_FREQ — FIFO Request Interrupt (triggers on FIFO threshold)
• SAI_IT_WCKCFG — Word Clock Configuration error — Enabled on SAI2 Tx only (SAI.c:79)

5. STEREO CHANNEL HANDLING

Channel Extraction & Processing — EQ.c:115-144

Code: [Select]

void EQ_Run(uint32_t *buf, PeakFilter_t eqFilters[][2], int bands, float *volume) {
  int16_t *buffer = (int16_t*)buf;

  // LEFT CHANNEL (index 0)
  AnalysisBuffer_Update(&inputL, buffer[0]);
  sample = buffer[0] * scale;           // Convert to float [-1.0, +1.0]
  sample = sample * gain;
  for(int band=0; band<bands; band++)
    sample = PeakFilter_Update(&eqFilters[band][0], sample);
  buffer[0] = sample / scale;

  // RIGHT CHANNEL (index 2)
  AnalysisBuffer_Update(&inputR, buffer[2]);
  sample = buffer[2] * gain;
  for(int band=0; band<bands; band++)
    sample = PeakFilter_Update(&eqFilters[band][1], sample);
  sample   = rolloverProtect(sample, &gain);
  buffer[2] = sample;
}


Key observations:

• Stereo samples arrive as: [L_sample, ?, R_sample, ?] (32-bit pairs)
• Left channel: array index
• , Right channel: array index [2]
• Each channel processed through independent filter arrays
• EQ1: 3 peaking bands (80 Hz, 2 kHz, 10 kHz)
• EQ2: 5 peaking bands (40 Hz, 80 Hz, 800 Hz, 2 kHz, 10 kHz)

6. AUDIO PROCESSING PIPELINE
Data flow:
[list=1]

• Reception (SAI1_IRQHandler → SAI_Rx_Interrupt): Audio arrives at SAI1 Block A (slave RX). FIFO threshold interrupt triggers when data is ready. Raw samples loaded into rx1Buffer/rx2Buffer.
• Processing (SAI2_IRQHandler → SAI_Tx_Interrupt): Triggered by SAI2 transmitter FIFO space. Copy rx to tx buffers. Apply EQ_RunOne() (3-band) and EQ_RunTwo() (5-band). Update analysis buffers in interrupt context.
• Analysis (main loop, main.c:169-181): AnalysisBuffer_Process() downsamples 48 raw samples → 1 peak/RMS. AnalysisBuffer_ProcessMS() further downsamples 48 values → 1 final peak/RMS in dB. Results sent via SPI to external controller.
• Transmission (SAI2_IRQHandler → SAI_Tx_Interrupt): Write processed samples to SAI2 Block A & B FIFO. Block A = master output (generates frame sync/clock). Block B = slave output (synchronised).

Sample size & timing:

• 48 raw samples per analysis window @ 48 kHz = 1 ms audio
• 48 × 1 ms values = 48 ms analysis window

7. FRAME SYNC & WORD SELECT (WS) HANDLING

[list=1]

• SAI1 (Receiver) — main.c:277: SAI_ASYNCHRONOUS. External frame sync expected from I2S source. No recovery logic implemented.
• SAI2 Block A (Master Transmitter) — main.c:311: SAI_ASYNCHRONOUS. Generates its own frame sync and clock. SAI.c:79 enables SAI_IT_WCKCFG interrupt for word clock config error monitoring.
• SAI2 Block B (Slave Transmitter) — main.c:326: SAI_SYNCHRONOUS. Synchronises to Block A's clock and frame sync.

WS detection/recovery: SAI_IT_WCKCFG flag enabled on transmitter (SAI.c:79). No explicit recovery code visible; relies on HAL_SAI_IRQHandler for error handling. GPIO debug pins (RxIT/TxIT on GPIOE pins 0-1) used to monitor interrupt timing.


8. BUFFER MANAGEMENT DETAILS

Small audio buffers (interrupt domain):

• 8-element arrays (32 bytes each) in DTCM RAM
• Direct access in interrupt context — no synchronisation
• No overflow handling; overwrites stale data

Large circular buffers (SPI data channel):

• 8 buffers × 2048 bytes = 16 KB total
• Head/tail pointers for async producer-consumer
• Protected with __disable_irq() / __enable_irq() in critical sections
• Used for command/response over SPI6 (not audio streaming)

Analysis buffers:

• Per-channel peak/RMS tracking
• Double-buffering: samples1/samples2, msPeak1/msPeak2, msRMS1/msRMS2
• No locks needed (single producer in ISR, single consumer in main)

9. DMA CONFIGURATION SUMMARY

Audio streaming does NOT use DMA — all transfers are interrupt-driven via FIFO thresholds (low latency, small 8-sample buffers).

DMA used for:
[list=1]

• SPI6 (control/stats): BDMA_Channel0 RX, BDMA_Channel1 TX (stm32h7xx_hal_msp.c:149-182)
• USART1 (debug output): DMA1_Stream0 TX (stm32h7xx_hal_msp.c:270-287)

10. KEY FILES SUMMARY

Code: [Select]

File                                     Purpose                                   Lines
-----------------------------------------+------------------------------------------+---------
Core/Src/SAI.c                           I2S interrupt handlers, buffer management  1-96
Core/Src/main.c                          System init, SAI/DMA/GPIO config, main loop 1-602
Core/Src/stm32h7xx_it.c                  Interrupt dispatcher, WS error detection   308-352
Core/Src/stm32h7xx_hal_msp.c             SAI/SPI/UART pin config, DMA setup         337-515
Core/Src/EQ.c                            Stereo EQ processing, channel separation   115-150
Core/Src/AnalysisBuffer.c                Peak/RMS tracking per channel              1-109
Core/Src/PeakFilter.c                    BiQuad peaking EQ filters                  1-49


11. CRITICAL INTERRUPT PRIORITIES

• SAI1_IRQn: Priority 0, subpriority 0 (highest — audio input)
• SAI2_IRQn: Priority 0, subpriority 0 (highest — audio output)
• BDMA_Channel0/1_IRQn: Priority 1 (SPI control)
• USART1_IRQn: Priority 0 (debug, low traffic)

12. POTENTIAL ISSUES & NOTES

[list=1]

• No DMA for audio: Uses small FIFO-based interrupt transfers (8 samples at a time). Works for low latency but no buffering resilience.
• Stereo channel indexing (EQ.c:120, 134): Hard-coded indices
• and [2] assume specific sample layout. Brittle — any frame slip causes L/R swap or corruption.
• No overflow protection: If SAI2 Tx interrupt doesn't fire frequently enough, FIFO can overflow. Debug via GPIO flags (lines 311, 326, 337, 350).
• WS/Frame sync (SAI.c:79): Only transmitter monitors word clock config errors. Receiver relies entirely on external master stability.
• Rollover protection (EQ.c:98-113): Hard limiter on right channel only (line 141); left channel limiter is commented out (line 130).
• Analysis buffer latency: 48-sample window @ 48 kHz = 1 ms, plus 48 ms aggregation = ~49 ms stats delay.

[/spoiler]

[paulca]

On the tooling question.  I'm going to explore claude's ability to "port" this project out of CubeMX and into, PlatformIO or cmake, so I don't need to install CubeMX and that whole shinanegans to fix this.

Update:  It's encouraging.  Suggests CMake exports as an easy "today" step one.  STM32Programmer is fine for flashing, but with the CMake export it doesn't need you to run CubeIDE or CubeMX.

More interestingly... I asked it about it replacing CubeMX and gave it the scenario where CubeMX does well.  Remapping the pins to alt functions when you want to layout the PCB and have constraints and conflicts. 

It's response including reflections on where it can do well and where to be careful.  It pointed out that the STM32 alt function tables are well represented in training data, but for less common, obscure peripherals or smaller, LP packages the numbering can be out, so it needs verification.

It also suggested creating an excerpt of the actual dataset and grounding claude with it rather than training data.  "Using this AF table..."

It's quite new for them to be that "meta aware" outwardly and call themselves out on where not to trust them.  We have been asking for this and it might be starting to arrive.



EDIT:  As an asides... If you even check claudes final bullet list only... it found the bodies.

[Unixon]

Why can't you just write code by yourselves?

[peter-h]

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.

[SpacedCowboy]

The amount of work it was for me to set up was:

 1) open Terminal.app and type 'curl -fsSL https://claude.ai/install.sh | bash'
 2) type 'claude'

Like most Mac developers, I have homebrew already installed, but if you don't, and it you also don't have npm installed as well, there's another couple of steps

 1.3) install homebrew with /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
 1.6) type 'brew install npm'


That's it. The two long and scary commands are copy-pasted from the "how do I install X" google query, where X = {claude code|homebrew}. They're one-offs. After their install, it's just "claude" to run Claude Code, or "brew install xxx" to install a package.

Compared to the horrors of having to edit python scripts to get around the lack of an adequate Java installation to get STCube installed (shudder), this was utterly painless, and took about 5 mins.

AI-derived code, like any code you didn't write yourself, needs to be looked over and you have to verify that it does the job. The thing is, you have an AI for that. So instead of laboriously going through every line, ask it to write regression tests to cover X, Y for all inputs A,B,C and actually test how the code works. When/If it fails, tell it to fix it. A few dozen rounds of that, with the AI finding and reporting related bugs, and you'll have a lot of regression tests.

Example: on my 6502 simulator, the AI suggested I download Klaus Dormann' 6502 regression suite. I agreed and asked it to write a fixture test to run them all. It did, and reported one issue with the BCD status register flag, and fixed it.

Then it suggested I download Tom Harte's signal waveform tests, so I asked it to, and it compared every opcode's bus waveform to known-good examples for every addressing mode. 100% pass, which gives me a reasonably warm and fuzzy feeling that this completely-machine-generated 6502 core is probably up to spec.

As for "so a re-visit in a few years' time is probably going to be impossible without doing it all again", again I don't agree. The AI will scan your source directory in seconds (maybe minutes, if it's truly huge) and be ready to rock and roll pretty shortly afterwards. It has memory (stored in files in the directory) of what it did last time, and notes on implications and user preferences etc. You'd be up and running in no time.

I don't agree with pretty much anything in your last paragraph either. I think there's quite a bit of copium being expressed there, sorry. I can honestly say I've never used the AI tools for web stuff. Everything I've asked it to do is in the embedded / embedded-related field. That 6502 core is on an RP2354, and it has PIO code to manage bus waveforms, DMA'd to the CPU core running on 1 ARM core with a logger/debugger running on the other. I didn't code any of it.

I'm still not sure if you've actually tried Claude Code, or if you're still talking about the red-headed step-child that is the web version...

[nimish]

Why can't you just write code by yourselves?

I can till the soil and grow my own food too but why would I?

[hans]

I predict coding will be like carpentry in a few years. Many people will just run to IKEA and buy a 10$ table that is actually made of cardboard. It works although its not the most sturdy, not the most durable, etc.
Want a solid wood table? Pay €€.
Want it custom-made for your space? Pay €€€.
Or do it yourself.
Roll back time 100-200 years ago. There was no IKEA etc. Perhaps coding will undergo a similar transformation. Especially in embedded, we have everything custom, people roll their own protocol stacks, a lot of 'not invented here' syndromes (myself included).. I think that will have to change.
When new AI's become pro's at stabbing CVE 9/10 security holes within minutes, I expect that will be the primary focus soon.

IMO having tried coding like this, I do see the upsides: its like having an extra junior programmer while you work on other things. I also had it write some Rust code for a library I wanted to use (on desktop). When it was 90% there, I just filled in the gaps it left behind.
Otherwise I would have had to learn Rust, understand how cargo works, how dependencies are managed, how tests are ran, how to make the borrow checker happy, etc. So just that it saved me a lot of time. But I also missed out on a few skills by making this choice (learning Rust ground up).. although I perhaps chose not to do this project at all.

Now, I still have my "first Rust project", even though I didn't write 90% of it. Though it is not fun at all to be staring at 2-3 prompts and wait till they are done generating.

[brucehoult]

I predict coding will be like carpentry in a few years. Many people will just run to IKEA and buy a 10$ table that is actually made of cardboard. It works although its not the most sturdy, not the most durable, etc.
Want a solid wood table? Pay €€.
Want it custom-made for your space? Pay €€€.
Or do it yourself.

I've actually had pretty good luck getting things custom-made for cheap.

For example this little trolley thing.



I got it made almost 30 years ago to house a PowerMac 8500 mini-tower, obviously long since pensioned off, but it started as a 120 MHz PPC 604, had a couple of 604e upgrades and eventually a 450 MHz G4.

Anyway, I wandered into a local office furniture place that I guess was usually making custom reception desks and the like, drawing in hand.

"What do you want it made from?" "Do you have any off-cuts?" He wanders out the back, comes back with two items. "Do you mind if the top is a different shade to the sides?" "Not in the least" "Do you need it in a hurry?" "Nope".

I can't remember now what I paid, but I don't think it can have covered more than an hour of labour plus the wheels and steel brackets in the corners. The wood must have been free, or damn near.

Very sturdy little unit. The 60 kg of LFP batteries & electronics sitting on top of it now doesn't trouble it in the least.

That's far from the only thing I've had made or repaired at very little cost. In 2018 I got a workshop in Kerikeri (ok Waipapa) to make up an aluminium adaptor from a standard photo tripod to a drawing board for my then wife to do sketches in the field. In 2011, in the same week I shot my BMW motorcycle fell over when the centre-stand sunk in soft ground, breaking one of the brackets for the panniers. Early next morning I rode 30 km into Taihape, found a truck / farm equipment workshop just opening. They let me use their tools to remove the rear wheel, seat, bodywork, some cables, so they could get in safely with a welder for a couple of minutes in the middle of doing whatever they were doing. IIRC he refused to take any payment.

There are no doubt people on this board with a well-equiped home workshop who could have done these things themselves. I don't have one. But I've found if you approach commercial places with a plan and a smile and make it easy for them to minimise their time involvement you can get things for very little outlay.

Getting back to LLMs, I find them good at researching some details when I already know what I want to do well enough that I could call Joe, who knows that stuff, and ask "how would you do ... X in Y?". A pretty big time-saver compared to poring through manuals and data sheets.

I haven't yet trusted them with the whole job.