OTA Speeds + tips on powering your lab collection of strips.

[robertlipe]

So I worked through the bootstrapping issues of upgrading to the trunk so that I could enable OTA on Mesmerizer. The build I was using had badly sized partitions so I couldn't upgrade to upgrade, but I worked that out.

That takes me from:
➜ nightdriverstrip git:(balls) ✗ time ~/.platformio/penv/bin/pio run --target uploadfs --upload-port /dev/cu.usbserial-110 -e mesmerizer
Hard resetting via RTS pin...
========================= [SUCCESS] Took 11.72 seconds =========================

Environment Status Duration

---

mesmerizer SUCCESS 00:00:11.722
========================= 1 succeeded in 00:00:11.722 =========================
~/.platformio/penv/bin/pio run --target uploadfs --upload-port -e mesmerizer 4.33s user 1.21s system 44% cpu 12.506 total

To:

======================== [SUCCESS] Took 130.99 seconds ========================
Environment Status Duration

---

mesmerizer SUCCESS 00:02:10.986
========================= 1 succeeded in 00:02:10.986 =========================

That's sub-awesome. I get that flash isn't fast in doing sub-sector block sizes and SPI flash is worse, but that's not the variable here've gone back to a pretty fully featured build so ./.pio/build/mesmerizer/spiffs.bin is about 1.7MB. I don't know if it's doing single character round-trips over the network or what.

Do I have something on the network side misconfigured? Are the rest of you pushing similar times? I've had no luck in opening sockets to 49152 or 49153 (I've admittedly barely tried) to see if pushing/pulling frame data suffers from similar performance issues. Are there existing ways to separately test the I/O speeds of {OTA, network, flash write, pio's network handling}? Two of those could be symptomatic in actual use case for frame delivery/serving.

Is the flash on these on the QSPI bus? Or is this all on the internal bus with the external Flash used for SPIFFS? I have projects on BL602 where QSPI is available. It takes a bit of setup to enable it, but it really helps performance on bursting writes. It's possible that an Arduino-generic library doesn't know how to turn that on with an ESP32.

Also, on Mesmerizer hardware, Is the power screw connection isolated via a diode or such so that feeding the board via an external brick does not dump backwash current into the USB-C connector? (Schematics...) I started this exercise thinking about being able to detach my build system from the cabling requirement, but need to understand the rules about externally powering the board + display and what happens when it IS connected to a computer, such as the need to capture panic() information for, say, a divide by zero or attaching a JTAG probe. Should the board be disconnected from external power first?

Here's a helpful tip to others that are also trying to break free of the bench supply. Use low-cost USB-C trigger boards to get 5, 12, and sometimes 24V from your laptop or better phone chargers. You can't get really high current at the low voltages, but most of us have USB-C PD adapters everywhere. "Trigger boards" speak just enough USB-PD to ask the power supply to send higher voltage and current combinations than the default 0V (some default to 5V). These trigger boards have switches, but some can be reconfigured by moving a wire, jumper, or resistor. If you're switching between 2811's and 2812's that need 5 or 12V, you'll find it either handy or disastrous to have basically the same power configuration. I have a couple of these (heavily marked) that go to terminal blocks like https://www.amazon.com/dp/B0BMTKGCM6 that go to a bouquet of https://www.amazon.com/BTF-LIGHTING-Connectors-WS2812B-WS2811-WS2812/dp/B01DC0KIT2 that I have in a variety of lengths (I use generics for all of these...) so that I can power from banana jacks from my bench supply, USB-C PD, or 5525 jacks from dedicated bricks. Unlike Dave, my lights are in a box and get rotated in and out and do not require a ladder. :-) The ability to power and quickly move between configurations is pretty nifty.

Oh, there are usually often breakers/fuses and reverse polarity diodes on the blocks. Sizes are a bit of a game since the "right" power range for lab gear is such a wide range, but it's usually worth a few extra $$ to reduce the smoke risk.

What's YOUR hot tip for managing a fleet of boards + bulbs?

[davepl]

In my fork I've got a samples file called flash.sh that writes N ESP32s in parallel over the Wifi. It's how I update mine. This one just shows doing half a dozen S3s. So I can do a dozen in under a minute.

To write s single S3 flash over wifi on my system takes 33 seconds, which I don't think is bad. But I used to assemble code from a 1541 floppy drive, so maybe I'm just conditioned to be more patient.

1.12s user 0.39s system 4% cpu 33.474 total

[robertlipe]

If you're really able to do the flash in 33 seconds, that's 4x as fast as mine, so something IS up. (Heck, pio takes almost that to do nothing, just wandering around in the "checking for dependency" weeds.) Once I get caught up, I'll look into network and other timing issues. Just knowing that there's a difference is important and now I have a reason to go study it, so thank you. A 4x difference is a big deal.

I wrote assembly code IN the 1541 that used both the clock AND the data pin to make it whopping 2-bit parallel (and just handled timing like a uart) and resyncing the clock edges every few frames to make it WAY faster. There a a sector retry and everything. I mailed the idea to Jim Butterfield at Compute to pitch for an article (Run! had each already published a disassembler of mine), but they already had Turbodisk under development. I don't do slow. (And I think we're about the same age, so we were both big nerds in high school...)

[robertlipe]

Oh Ho! That's an article I didn't expect to be able to find: https://www.atarimagazines.com/compute/issue59/turbodisk.php

I spent a big chunk of my early career design communications boards and working with weird protocols, so that wasn't just Stupid Vic Tricks, but rather a path to actual employable skills. Looks like it worked for both of us!

[davepl]

I sped it up a lot in recent weeks, so make sure you have the current bits!

…

On Jul 25, 2023, at 5:11 PM, Robert Lipe ***@***.***> wrote: Oh Ho! That's an article I didn't expect to be able to find: https://www.atarimagazines.com/compute/issue59/turbodisk.php I spent a big chunk of my early career design communications boards and working with weird protocols, so that wasn't just Stupid Vic Tricks, but rather a path to actual employable skills. Looks like it worked for both of us! — Reply to this email directly, view it on GitHub <#373 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4HCF5FVDIBNYWSRW4JCNLXSBOBVANCNFSM6AAAAAA2VE7I3U>. You are receiving this because you commented.

[robertlipe]

Oh Ho! Current trunk + ESP32-S3 (Pictures at 11...)

~/.platformio/penv/bin/pio run --upload-port 192.168.2.168 --target upload -e lilygo-tdisplay-s3-demo

32 seconds.

So is the 2+ minutes the fault of mesmerizer or my branch destined for mesmerizer being ~ 2 weeks old? That brings OTA pushes down from the 'maddening' range. That's close enough to serial speed that the freedom from a wire is worth it.

I'll figure this out in a sleep or two, but a different code base (today vs ~2.5 weeks ago) on a different project ( lilygo-tdisplay-s3-demo vs. mesmerizer) on different hardware (esp32s3 vs. mesmerizer) makes it ~4x as fast and absolutely, positively, cannot change any other variables that I can imagine.. :-) Something about an "espota" flies by the screen and my feeble attempts to capture it with shell redirection and with typescript both failed.

I'll triage it soon, but maybe everyone else's experience with pushing OTAs for development won't be as rotten as mine originally was. I'll have to get the same hardware on the same AP with the same server on the same code later, when I can actually get out of bed.

Come on in. The water's clear.

At least probably. We still need more test points.

[davepl]

We used to have a delay() in the ArduinoOTA.handle() loop, but now as soon as detect an OTA start we loop tightly on handle() until its over. - Dave

…

On Jul 25, 2023, at 11:45 PM, Robert Lipe ***@***.***> wrote: Oh Ho! Current trunk + ESP32-S3 (Pictures at 11...) ~/.platformio/penv/bin/pio run --upload-port 192.168.2.168 --target upload -e lilygo-tdisplay-s3-demo 32 seconds. So is the 2+ minutes the fault of mesmerizer or my branch destined for mesmerizer being ~ 2 weeks old? That brings OTA pushes down from the 'maddening' range. That's close enough to serial speed that the freedom from a wire is worth it. I'll figure this out in a sleep or two, but a different code base (today vs ~2.5 weeks ago) on a different project ( lilygo-tdisplay-s3-demo vs. mesmerizer) on different hardware (esp32s3 vs. mesmerizer) makes it ~4x as fast and absolutely, positively, cannot change any other variables that I can imagine.. :-) Something about an "espota" flies by the screen and my feeble attempts to capture it with shell redirection and with typescript both failed. I'll triage it soon, but maybe everyone else's experience with pushing OTAs for development won't be as rotten as mine originally was. I'll have to get the same hardware on the same AP with the same server on the same code later, when I can actually get out of bed. Come on in. The water's clear. At least probably. We still need more test points. — Reply to this email directly, view it on GitHub <#373 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4HCF3WNUZJZVYXLRAIVVLXSC4JZANCNFSM6AAAAAA2VE7I3U>. You are receiving this because you commented.

[JustinCredible-]

Robert, any chance this project would run on the arudino uno r4 with its esp32 chip? Been looking for something for it to do ever since I got it in!Justin DaleOn Jul 26, 2023, at 9:59 AM, David W Plummer ***@***.***> wrote: We used to have a delay() in the ArduinoOTA.handle() loop, but now as soon as detect an OTA start we loop tightly on handle() until its over. - Dave

On Jul 25, 2023, at 11:45 PM, Robert Lipe ***@***.***> wrote: Oh Ho! Current trunk + ESP32-S3 (Pictures at 11...) ~/.platformio/penv/bin/pio run --upload-port 192.168.2.168 --target upload -e lilygo-tdisplay-s3-demo 32 seconds. So is the 2+ minutes the fault of mesmerizer or my branch destined for mesmerizer being ~ 2 weeks old? That brings OTA pushes down from the 'maddening' range. That's close enough to serial speed that the freedom from a wire is worth it. I'll figure this out in a sleep or two, but a different code base (today vs ~2.5 weeks ago) on a different project ( lilygo-tdisplay-s3-demo vs. mesmerizer) on different hardware (esp32s3 vs. mesmerizer) makes it ~4x as fast and absolutely, positively, cannot change any other variables that I can imagine.. :-) Something about an "espota" flies by the screen and my feeble attempts to capture it with shell redirection and with typescript both failed. I'll triage it soon, but maybe everyone else's experience with pushing OTAs for development won't be as rotten as mine originally was. I'll have to get the same hardware on the same AP with the same server on the same code later, when I can actually get out of bed. Come on in. The water's clear. At least probably. We still need more test points. — Reply to this email directly, view it on GitHub <#373 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AA4HCF3WNUZJZVYXLRAIVVLXSC4JZANCNFSM6AAAAAA2VE7I3U>. You are receiving this because you commented.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[robertlipe]

Probably. From what I can tell, that board is just an overpriced esp that uses Arduino pinouts. Go for it. On Wed, Jul 26, 2023, 3:54 PM JustinCredible- ***@***.***> wrote:

…

Robert, any chance this project would run on the arudino uno r4 with its esp32 chip? Been looking for something for it to do ever since I got it in!Justin DaleOn Jul 26, 2023, at 9:59 AM, David W Plummer ***@***.***> wrote: We used to have a delay() in the ArduinoOTA.handle() loop, but now as soon as detect an OTA start we loop tightly on handle() until its over. - Dave > On Jul 25, 2023, at 11:45 PM, Robert Lipe ***@***.***> wrote: > > > Oh Ho! Current trunk + ESP32-S3 (Pictures at 11...) > > ~/.platformio/penv/bin/pio run --upload-port 192.168.2.168 --target upload -e lilygo-tdisplay-s3-demo > > 32 seconds. > > So is the 2+ minutes the fault of mesmerizer or my branch destined for mesmerizer being ~ 2 weeks old? That brings OTA pushes down from the 'maddening' range. That's close enough to serial speed that the freedom from a wire is worth it. > > I'll figure this out in a sleep or two, but a different code base (today vs ~2.5 weeks ago) on a different project ( lilygo-tdisplay-s3-demo vs. mesmerizer) on different hardware (esp32s3 vs. mesmerizer) makes it ~4x as fast and absolutely, positively, cannot change any other variables that I can imagine.. :-) Something about an "espota" flies by the screen and my feeble attempts to capture it with shell redirection and with typescript both failed. > > I'll triage it soon, but maybe everyone else's experience with pushing OTAs for development won't be as rotten as mine originally was. I'll have to get the same hardware on the same AP with the same server on the same code later, when I can actually get out of bed. > > Come on in. The water's clear. > > At least probably. We still need more test points. > > — > Reply to this email directly, view it on GitHub < #373 (comment)>, or unsubscribe < https://github.com/notifications/unsubscribe-auth/AA4HCF3WNUZJZVYXLRAIVVLXSC4JZANCNFSM6AAAAAA2VE7I3U>. > You are receiving this because you commented. > —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***> — Reply to this email directly, view it on GitHub <#373 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACCSD36NKLRB7P3U2UKLWR3XSF7WTANCNFSM6AAAAAA2VE7I3U> . You are receiving this because you authored the thread.Message ID: <PlummersSoftwareLLC/NightDriverStrip/repo-discussions/373/comments/6556005 @github.com>