espconnect: new tool for care and feeding of your ESP32 menagerie #794
Replies: 1 comment 2 replies
-
|
@robertlipe This caught my eye: I spent the last couple of hours doping out how to get it working on my Windows 11 ARM 64 (QualComm X-Elite) based CoPilot PC. Magically, I landed on this webpage; With the driver in place I was able to spin up ESP Connect on my ARM64 CoPilotPC. Than I was able to backtrack to the NightDriverLED ESP32 Installation Wizard |
Beta Was this translation helpful? Give feedback.
-
|
I have no idea why they don't include FTDI drivers. Microsoft didn't ask me. When I was in the OS biz and leading the development of the USB stack, FTDI support took us less than a week to implement and doc, IIRC. It wasn't like it was particularly complicated, though our customers were very different from Microsoft's. But it does track that ARRL types are the kind of people that share interest in things connected via serial ports[1]. I suspect that WebUSB means something different than you think it means. WebUSB is a way for BROWSERS to interact with USB thingos that don't really otherwise conform to a given USB class specification, like a storage device, keyboard, or media player. If we wanted Chrome to interact directly with our label printer or a custom DVR that we just built (as one does) or some other crazy USB device that may or may not be supported by whatever OS is running our browser, WebUSB is the ticket. It exposes plumbing that's very much like part of the raw USB protocol (higher than the host controller drivers, lower than the class drivers) that would let my app (usually Javascript, but potentially Java or anything that builds to WASM, which is about anything now) scan for attached devices, identify them, claim them as 'mine,' and open bulk or control pipes to communicate with them. WebUSB is very much like libusb if you're familiar with that. (Well, it's very much like libusb whether you are or not. 🤠) It's a way for a web app to talk to custom USB thingies. One example of such a web app might be ESPConnect, but it's actually not. ESPConnect doesn't actually connect to arbitrary USB things. ESPConnect connects to USB things pretending to be serial ports specifically. This is actually a different spec called...wait for it... webserial. You can see this in the [code] (https://github.com/thelastoutpostworkshop/ESPConnect/blob/af327eb6139dc432430281f9b3dbb029da7a6c63/package-lock.json#L14} This is quite a bit higher level still, offering methods much like the traditional UNIX driver model has since the early 70's: open, close, read, write, and ioctl, though they all now have goofy names and Javascript accents, which makes sense in browserland. This is a level way above WebUSB's handling of bulk vs. interrupt pipes and toggles and stalls and other such USB plumbing. The nifty thing for us embedded nerds is that all the ESP32s we care about offer a serial port, which means it's easy (< ~$1 USD) to bridge to the host. For an ESP32-Nothing (like the one in your Mesmerizer), it's a separate USB/Serial bridge chip (CH340, FTDI, CP2102, etc. which requires something in the host OS to deal with it); for the ESP32-S3, S2, C3, P4, C5, C6, and everything since 2020 or so, the chip itself offers a USB-CDC/ACM protocol on the wire, which is usually handled by the OS itself, as most OSVs did shortly after the turn of the century, though I think Windows did it only around Win8 or so. This means it's fairly mechanical to take existing code (like Espressif's esptool) that runs on real operating systems and rebuild it with WASM so it executes inside a browser but still talks in mostly normal serial ways to our beloved ESP32's to ask things like "How much memory do you have?" and "What are the contents of bytes 500-600 of flash memory?" or to send commands like "Erase all your flash memory." If you look at the feature set of ESPConnect (and it's pretty awesome) you can see it's a superset that's riding atop ESPTool, ESPFuse, and such. A page like https://plummerssoftwarellc.github.io/NightDriverStrip/ probably uses WebSerial. NightDriverLED hardware and firmware themselves don't really know about either WebUSB or WebSerial. Bits placed by the OS just appear on the serial port pins of the ESP32 or inside the 'pretend' serial port on the newer chips; the ESP32 doesn't really know how those bits got there. They're just signals wiggling on wires. Now if we wanted a reason to use WebUSB with an ESP32, let's say I built a special kind of camera that would recognize one of four specific squirrels in my neighborhood, offered cropped and captioned image upload when they're near, and could control a motor to feed these, our Chosen Squirrels. A lovely chip choice to develop this around would be to build it using an ESP32-S3 or ESP32-P4, both because they have features that would be good at squirrel recognition from a controlled camera AND because they can appear as a custom USB device to the host computer. To our dismay, there isn't an existing standard for SquirrelID, SquirrelHotOrNot, or SquirrelFeed. Criminally, there is no version of RedHat, Windows, or any other OS that knows how to do these. We COULD make drivers for all the OSes our squirrel devotees might care about, but really this is a low-volume market, and we just want to make our own custom USB protocol implementation nimble so we can change it all quickly. Besides, the USB Implementer's Forum issued a restraining order against us from sending any more strongly worded requests that they support the SquirrelOMaticPro3000Plus USB protocol posthaste! We thus have our embedded team write the code that implements the custom USB protocols that run on our embedded S3 or P4, but what do we do for software? Drivers are a big pain...for everyone. We want the ability to quickly change the code on our device and have features available to users immediately. What if we make a web page with a download for all the OSes? Gross. What if we instead made a web page that asked the browser (which has already cut a deal with the OS for 'behind the scenes' access—probably via LibUSB-like interfaces) directly? Now our web page opens our camera, gets the pictures, the captions, and the estimated weights of the squirrels; dispenses the day's vittles; and does all this other weirdo stuff that's WAY beyond what a sensible webcam would ever implement, and just talks to the USB device directly. That's now a pretty clean interface straight from the web browser all the way through to our custom SquirrelOMaticPro3000Plus cluster that's occupying the first 6 ports of our USB hub. If you've stuck with all this nonsense so far, good for you. Let's recap:
Though your links are confused (GitHub tends to mangle them, especially through the email gateways) I really do suspect that your happiness chain depended upon A) finding the magic chant to get your USB/Serial bridge to work on your Windows install and B) ESPConnect using ESPTool and related technologies to find your device as "just a COM port" and treating it as such. C) ESPConnect being awesome and generally doing helpful/interesting things with that serial port, and thus your Mesmerizer. Man, it used to be a lot easier to explain how keyboards or printers worked in WordStar for CP/M. Protocols and software stacks are just gnarly these days. Come for the blinky lights, stay to have 30 years of protocols explained! [1] Trivia: I recognize the lat/long of the repeater last associated with that call sign. It's about 3 miles away from me right now. (Yes, I DO generally recognize lat/longs...ultimately because of yet other serial devices in my life.) |
Beta Was this translation helpful? Give feedback.
-
|
In addition to what @robertlipe mentioned: the NightDriverStrip web installer indeed also uses WebSerial - hence the question what serial port to use at the start of the flash process. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
A new browser or npm/electron app for managing ESP32s has hit the streets. I don't think there's anything particularly new here, but it wraps up a bunch of independent tools to flash, identify devices, change selected registers, monitor serial output, copy files to/from the board, edit partition tables, and such.
https://thelastoutpostworkshop.github.io/microcontroller_devkit/espconnect/
Source: https://github.com/thelastoutpostworkshop/ESPConnect?tab=readme-ov-file
Somewhat interestingly (or not) it overlaps with a set of changes I've had pending for this project for a while that I've been prepping to submit. I make unsightly things, as shown on the left. You can see a pretty version on the right. It's still just a directory listing, but it's an example of something that the tool does pretty well.
Beta Was this translation helpful? Give feedback.
All reactions