Recommit patch 732

[robertlipe]

Description

Reconstituted change from #732

Contributing requirements

• I read the contribution guidelines in CONTRIBUTING.md.
• I understand the BlinkenPerBit metric, and maximized it in this PR.
• I selected main as the target branch.
• All code herein is subjected to the license terms in COPYING.txt.

[robertlipe]

A build-all succeeded. I'm officially happy with this now.

I'd probably be happier to move spectrum-electrow to the I2S_PINS scheme, but I don't have one, so I'm trying to touch it as lightly as possible. This at least puts it back on the same path with the same values.

[robertlipe]

Confirmed building everywhere.

Platformio even lies about how slow it is. Scrolling up I can see that it refetched and reinstalled every library and then recompiled all our objects for all 41 of our committed targets (never mind that it had done so an hour before for a build-all instead of a buddy-build or a pio-run or something) so every one of these builds is 5+ minutes.

We can't parse an error message out of the demo build in 7.2 seconds. Hrmph.

========================= [SUCCESS] Took 66.12 seconds =========================

Environment               Status    Duration
------------------------  --------  -------------
demo                      SUCCESS   00:00:07.208
m5demo                    SUCCESS   00:00:09.151
m5plusdemo                SUCCESS   00:00:09.664
m5stackdemo               SUCCESS   00:01:03.991
heltecdemo                SUCCESS   00:00:07.611
heltecv2demo              SUCCESS   00:01:03.357
heltecv3demo              SUCCESS   00:01:07.794
helteclorav3demo          SUCCESS   00:01:07.033
lilygo-tdisplay-s3-demo   SUCCESS   00:01:06.415
demo_amoled               SUCCESS   00:01:23.637
ledstrip                  SUCCESS   00:00:08.506
ledstrip_feather          SUCCESS   00:00:09.400
ledstrip_feather_hexagon  SUCCESS   00:01:17.548
ledstrip_feather_wrover   SUCCESS   00:01:06.944
ledstriplite              SUCCESS   00:01:09.799
ledstrip_pico             SUCCESS   00:01:00.208
spectrum                  SUCCESS   00:00:11.106
spectrum2                 SUCCESS   00:01:11.232
helmet                    SUCCESS   00:01:16.952
spectrum_elecrow          SUCCESS   00:00:10.752
spectrumstack             SUCCESS   00:01:17.1000
spectrumlite              SUCCESS   00:01:45.739
spectrum_wrover_kit       SUCCESS   00:00:56.503
mesmerizer                SUCCESS   00:00:08.532
mesmerizer_lolin          SUCCESS   00:01:00.582
laserline                 SUCCESS   00:01:02.686
lantern                   SUCCESS   00:01:01.339
pdpgrid                   SUCCESS   00:01:04.813
chieftain                 SUCCESS   00:00:07.862
umbrella                  SUCCESS   00:00:07.537
generic                   SUCCESS   00:00:07.797
panlee                    SUCCESS   00:00:08.428
ttgo                      SUCCESS   00:00:55.517
xmastrees                 SUCCESS   00:00:09.893
insulators                SUCCESS   00:01:02.918
magicmirror               SUCCESS   00:01:05.439
atomlight                 SUCCESS   00:00:54.629
spirallamp                SUCCESS   00:01:05.857
platecover                SUCCESS   00:01:02.949
fanset                    SUCCESS   00:01:04.486
cube                      SUCCESS   00:01:06.122
========================= 41 succeeded in 00:32:25.937 ======================

[rbergen]

This is why I delegate the "confirmation builds" to the GitHub Actions workflows in my fork. You could do the same. :)

I've noticed that the USE_I2S_AUDIO(_PINS) defines are not set or checked anywhere else. As a general principle I don't like adding "dead defines", but I assume there is a solemn intention to use these very shortly? Disclaimer: I did not review the other 2 PRs you opened, yet.

[rbergen]

By the way, #733 and #734 suffer from the same problem #732 did, so I think they will have to undergo the same (or similar) treatment.

[robertlipe]

Oddly, I think that's part of my problem, I think. My laptop wants to make forks in your tree and not mine. I'm not sure if that's better or worse. Yes, that was the motivation behind this whole tortured process. I have a board that I've been working to integrate for some time that I was trying to add audio support to. I beat my head to figure out why I could change AUDIO_INPUT all day long and get nothing. Then I found these two hardcoded numbers not in src, but in a header file. You know the story from there. So, yes, there is a custom_robertsboard.ini that uses those two defines so I can put an INMP441 on pins that are actually accessible on this controller.

e way, #733

<#733> and #734 <#734> suffe [ Censored ] And now soundanalyzer changes are in those trees when that's not even related. I intentiaonlly put those on separate forks! Aaaaargh! I'll deal with 'em. Sorry. I'll let you batch them if you wish since I'm sure you incur the same penalty I do. ...also, within the last ten minutes, I have my first build with sccache in the cross env. Next up: distributed builds so I can get more compilers to throw at these hour-long builds. The 49 downloads of every stupid library we build are still on my list. If we can get those 18-26 3p libraries that are built 49 times under control, maybe this code would be less torturous to work on. These changes are so trivial (this was the big one - by far) that I would just do them in the web editor, but then I can't run a presubmit to confirm they build because that requires an approval. They just collapse in our infrastructure. I'm torturing myself with too many work trees, trying to integrate all the arduino3 work, the hexagon work, and the YULC work. When five-line changes take an hour per tree, and then another hour screwing with github, it's just a killer. ccache --show-stats | head Compile requests 808 Compile requests executed 798 Cache hits 590 Cache hits (C/C++) 590 Cache misses 196 Cache misses (C/C++) 196 Cache hits rate 75.06 % Cache hits rate (C/C++) 75.06 %

…

On Thu, Jul 24, 2025 at 2:01 AM Rutger van Bergen ***@***.***> wrote: *rbergen* left a comment (PlummersSoftwareLLC/NightDriverStrip#735) <#735 (comment)> By the way, #733 <#733> and #734 <#734> suffer from the same problem #732 <#732> did, so I think they will have to undergo the same (or similar) treatment. — Reply to this email directly, view it on GitHub <#735 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD32OEMDEP4MFICE4KU33KCAGHAVCNFSM6AAAAACCHDNYYGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTCMJSGI4DSMBZHA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[rbergen]

I did mean to say "execute GitHub Actions on [the branches in] your fork".

Your laptop is probably doing that because of how your git remotes are set up, but I can't be sure without looking over your shoulder, so to speak.

Concerning the PR branches: again I can't be sure, but it looks like the branches for #733 and #734 are based on the branch for #732, thereby incorporating its changes as well.

Concerning the otherwise unused defines: you're getting a Most Valued Contributor pass on those, then. :) Which I know sounds extremely elitarian/arrogant on my part, but isn't: it is a genuine expression of appreciation for the work you do here.

Which brings me to the final point: the conversion of magic numbers to defines is solid and CI is happy, so I'll merge this after posting this comment.

[robertlipe]

Thanx. That should pull those changes back out of the diffs now that it's in the base. I knew I was taking some MVP points on loans on that. (That's why you got a private pre-submit explanation.) It's laying the foundation for other work that's on the way. Much like tricking you into helping replace JsonSerializer and ESPAsyncStuff was a long game to prepare for Arduino3 and modern C++, there's a plan to it. * I have two valid plans for the remote code that I've not yet chosen between. * I do not have a plan for the SmartMatrix code. Rebasing Mesmerizer on CodeTastic's matrix code would be nice and would also get us S3 and P4, but it's a lot of work in a path that's presumably making money for one of us. "Fixing" that for Arduino3 just might be where I land on that. So there, I have two options and not really a plan yet. * I *finally* have demo building (with remote disabled and no idea if it even BOOTs yet) with Arduino3 but we blow out some fundamental space rules. The guideline that the NVS partition be 3 pages and not 2 like we have now? Well, we can push ours down one page and make it all FIT, but then we blow our saved settings. That' a mere matter of code to fix during an upgrade, though, right? Oh, but we also blow out our partition size. Code doesn't get smaller over time. Not NightDriver's native or Javascript code or ESP-IDF or Arduino3 and they all crashed into one big, ugly merge collision today. I don't have a plan there. I have a feeling that's going to hurt, and if it hurts, I may byte the bullet while we're anesthetized and push from spiffs to littlefs just to get us off a deprecated and unsupported filesystem. Then I have to write recovery/upgrade code. More anesthesia, but it'll be good for us. It _probably_ won't kill us. Maybe we move SOME of our GUI or resources out to the file system instead of baking them into our filesystem image? I dunno. Once I have a rainbow on a strip, that's on the short list. * I've been messing with YULC now for almost a year and have a collection of patches for it that generally awesomize things but also crack open all kinds of sharp edges, like "What happens if you have multiple effects on one pin and want to whack a GPIO latch that detects that lights are 'idle' and actually pops a "relay" for vampire drain? Uhm, I don't know. Multi-strip support in this code is just a landmine. * I figured out how to make POST-able settings parameters into consts to fool FastLED so we could reconfigure strip size and pin numbers and such on the fly. Maybe we reboot (meh, so do commercial controllers, but I think we can do better), but at least don't require a recompile. That's something, right? * I've literally filled a trashcan with scribbles from https://www.redblobgames.com/grids/hexagons/ and related materials. I think I have hexagons cracked. I'm not sure anyone cares, but that code is based on YULC, which is based on my stuff with thermal cut-out, which is based on my stuff with dynamic settings, which is based on debug command shell, which is based on my work with other YULC stuff. I really painted myself into a corner on that. But I can do things like a gyroscope in the hexagon display, which is pretty freaking cool. But then I went to add a heartbeat. Oh, did I not mention the MAX30102 work that reversed the pattern for a heartbeat, like for beat detection in music? Well, pulse/oxy work was based on music, and the music work was dependent upon.... Finding two damned integers in a header file...and then finding some sane way to set those. ...and this is how I spent the last three quarters (year?) shaving a whole herd of yaks. This should probably go in discussions and not be buried this deeply into a PR. But, back to the point. Yes, I have a plan. Oh, so many plans. So, yes, please, I'd appreciate a little clear airspace for some slightly out-of-order landings just so I have fewer pieces to juggle in local 50GB work trees and we can move the shared code toward actually benefitting from some of these scribbles that haven't escaped Lipe Labs.

…

On Thu, Jul 24, 2025 at 3:25 AM Rutger van Bergen ***@***.***> wrote: Merged #735 <#735> into main. — Reply to this email directly, view it on GitHub <#735 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD34YHHHKBMBJK7XY2XD3KCJ7TAVCNFSM6AAAAACCHDNYYGVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJYG44TAMRYGY2TSMQ> . You are receiving this because you authored the thread.Message ID: <PlummersSoftwareLLC/NightDriverStrip/pull/735/issue_event/18790286592@ github.com>