Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ESP32-S31

espressif.com

Post reply on HN
Print view View original

111–120 of 207 posts

Re: ESP32-S31

#111

Post by wolvoleo »

gedy wrote: post #109
wolvoleo wrote: post #91

Earlier quoted context omitted.

Yes but these don't need controller hardware. The OP is using a dedicated controller and I was asking why.

Maybe not following, but I buy strips of WS2812 and if I wanted to for them to turn on and, say, display a rainbow, I need something to drive that. Not USB from another device, e.g. standalone.

Yes but as far as I understand the OP is not doing that, they are just using raw LEDs with power drivers and the whole shebang that is so nicely built into the ws2812s for us. Otherwise they wouldn't need these components they're talking about.

I just connect them to a microcontroller pin and be done with it. I power them separately off a power bank (my LEDs are almost always worn, if they are static I just use an off-the-shelf 5V supply).

Re: ESP32-S31

#112

Post by mattalex »

thehk wrote: post #55

> ESP32-S31 is particularly well suited for edge AI and machine learning workloads, including neural network inference Any way to know what kind of performance one could expect running e.g. a depth anything model on there?

Regarding specifically depth anything: You're not running this on a microcontroller. In general, CNNs still reign supreme on microcontrollers since you have a way lower peak memory demand which is what usually kills you. Here in this case you have a couple of _kilobytes_ of SRAM, potentially extendable to a couple of megabytes of PSRAM.

Even for small CNNs you often need to do some quite complex interleaving of layers (i.e. running parts of layer 1 and layer 2 in parallel interleaved to take advantage of the downsampling of CNNs) to keep performance and memory impact reasonable (see e.g. https://openreview.net/pdf?id=2O8qbyxH6X).

Think more "image classifier" less "run an image to image transformer". For depth anything, a single layer's activation is probably significantly larger than the available SRAM (I think it is (224/16)^2 patches each with activations [48, 96, 192, 384] for depth anything small: You aren't running this.)

Re: ESP32-S31

#113

Post by moffkalast »

randomint64 wrote: post #3

Espressif is on fire! And the CPU even has SIMD instructions! RISC-V cores is a big deal for embedded systems because now compiling for SoCs is only a matter of `rustup target add riscv32imac-unknown-none-elf` instead of downloading half-broken proprietary toolchains and SDKs. Take a look at https://kerkour.com/introduction-to-embedded-development-wit... and https://kerkour.com/rust-esp32-pentest to get started with…

The sooner ARM and its closed ecosystem dies, the better. The era of shitty half working blobs has gone on for quite long enough.

Re: ESP32-S31

#114

Post by topspin »

orphea wrote: post #72
topspin wrote: post #54

Earlier quoted context omitted.

S has never implied Xtensa, and C doesn't imply RISC-V. That's a widely held misunderstanding. S, C, P, etc. are product categories, not ISAs. S devices are high performance SoCs; large feature set, high frequency, not the lowest power or cost. Just appending 1 to S3 is odd though. This MCU is step change for Espressif. S4 or something would make more sense.

Not saying you're wrong (appreciate the explanation) but S has been Xtensa and C is RISC-V; even if you don't imply, it's how the things have been. And given S2, S3, and C5 are all clocked at 240 MHz, the performance difference is kinda blur.

This is how Jeroen Domburg, Espressif Technical Marketing Manager, addressed this matter in a post on hackaday.io:

"We actually never intended the CPU architecture to be part of the name, as for 99.9% of all users, it doesn’t matter: you write your code in C or some other language, and the compiler plasters over any difference in ISA. Available peripherals, supported radio protocols and CPU power and memory are more important."

Re: ESP32-S31

#115

Post by arabscum »

BenjiWiebe wrote: post #57
phkahler wrote: post #13

Earlier quoted context omitted.

>> And the CPU even has SIMD instructions! Yes, but it looks like there is no hardware floating point. The description of the CORDIC module indicates fixed-point calculations, which is consistent with the lack of any reference to floating point. I am happy the have CAN-FD and Motor PWM module, but nowhere did I see conversion times listed for the ADC. For motor control I demand 1uS conversion time or less, and in the…

Also why do you need 1uS for motor control? 1uS is 0.1 degrees of rotation at 16,666 RPM if I did the math right. I don't know much about motor control, is it normal to need that fast of feedback?

[flagged]

Re: ESP32-S31

#116

Post by thot_experiment »

This is so sick except it only has 2 pulse counters instead of the 4 on the S3 which means I can't use it as a drop in replacement on my current project. Not really complaining, I cut my teeth as an embedded dev on the ESP8266 and for years now all of my personal projects (and a fair few professional ones) have been based on the ESP32 line of chips. They're all pretty incredible for the cost, absolutely my favorite embedded target.

Re: ESP32-S31

#117

Post by tomcam »

topspin wrote: post #66
BenjiWiebe wrote: post #57

Earlier quoted context omitted.

Also why do you need 1uS for motor control? 1uS is 0.1 degrees of rotation at 16,666 RPM if I did the math right. I don't know much about motor control, is it normal to need that fast of feedback?

Field-oriented Control schemes modulate phase currents at high frequency; the feedback loop must be much faster than the motor phases. Until fairly recently, this stuff was the exclusive province of dedicated ICs (Trinamic et al.) and FPGA. Today, FoC can be done in (mostly) software with MCUs. Fast feedback loops are also necessary in SMPS, another area where precision, low latency MCU peripherals and software are a…

I didn’t know that. Thanks for letting me… meet the FOCers

I’ll see myself out of the Internet now.

Re: ESP32-S31

#118

Post by oritron »

timothyb89 wrote: post #71
oritron wrote: post #24

Earlier quoted context omitted.

Low latency in Bluetooth audio comes down to codecs and the best are proprietary. If you want to really cut down latency and need wireless with hardware like this, you could use a second ESP32 and send your own bitstream between them.

I've been experimenting with more-or-less this on the existing ESP32-S3 (well, to a smartphone/PC rather than a 2nd ESP32). Practical bandwidth limits are in the ~72kb/s range with Bluetooth and a custom wire protocol, and Opus voice-mode encoding can't run in realtime beyond complexity 3; music encoding can't run at all. Maybe there's a more compute-friendly audio codec I'm not aware of, but as far as I know these c…

I haven't benchmarked Bluetooth on these devices but have you looked at your uncompressed audio rates over WiFi? OP was asking about Bluetooth at high quality and low latency, which I don't think is a possible combo, hence suggesting another ESP32 if wireless is necessary. If it isn't, a wire difficult to beat.

ESP-NOW is another option to look at, which of course won't work to transmit to a phone directly but can do a point-to-point or multicast transmission between ESP32 devices. I've used it in some projects but not for audio, I couldn't tell you how much of a buffer would be needed to make that work smoothly.

Another option for OP, if the audio is being synthesized then the parameters could be transmitted rather than the audio samples themselves and do synthesizing on the receiving device.

Re: ESP32-S31

#119

Post by peteforde »

alnwlsn wrote: post #53

I kind of wish these all weren't called ESP32. ESP8266 and ESP8285 -> ESP32 made sense, but now we have 10+ different versions with different features and different architectures. Kind of like how in every thread involving a Raspberry Pi Pico (RP2030/RP2350), there's always someone confusing it with the single board computer version. The ESP32 (Classic, usually WROOM-32E) is still usually what comes to mind when I he…

You're fundamentally misunderstanding how MCU families work, I'm afraid.

There's not 10+ versions with different features. The word version strongly implies that there's an incremental progression over time, and they keep screwing up by adding and taking away modules. What jerks!

What's actually happening is that you have 4-5 different product lines that all share the same SDK, design philosophy, pricing structure, supply chain and support channels. Each one of these dimensions is extremely important to engineering teams designing products around them. It's not about hobbyists who are learning the ropes, although IMO they do a pretty good job of supporting those folks, too.

Within those lines (at this point, primarily S, C, H and P) you actually do have versions; for example, ESP32-S2 is no longer recommended for new designs because you should use ESP32-S3.

Ultimately, the lens you need to use to understand this stuff is: can I place an ESP32-labeled chip on my PCB and program it using the same SDK?

The same is true for the RP2XXX series of MCUs; if someone is confused by the difference between a microcontroller and a SBC then they might just be in the wrong place.

Bigger picture, some advice: when confronted by something like this, you will get further faster if you don't lead with the assumption that you have things figured out and everyone else is doing it wrong. Instead, keep an open mind and ask lots of questions. We're living in a golden era of enabling autodidacts but that's only true for folks who go long on humble curiosity.

Re: ESP32-S31

#120

Post by Teknoman117 »

moffkalast wrote: post #113
randomint64 wrote: post #3

Espressif is on fire! And the CPU even has SIMD instructions! RISC-V cores is a big deal for embedded systems because now compiling for SoCs is only a matter of `rustup target add riscv32imac-unknown-none-elf` instead of downloading half-broken proprietary toolchains and SDKs. Take a look at https://kerkour.com/introduction-to-embedded-development-wit... and https://kerkour.com/rust-esp32-pentest to get started with…

The sooner ARM and its closed ecosystem dies, the better. The era of shitty half working blobs has gone on for quite long enough.

Almost everything we hate about ARM based systems is the result of everyone in the SoC ecosystem, not just ARM. It's just unfortunate for them from an optics perspective that they've been basically the only CPU core on the block so they get the brunt of the hate.

I place far, far more blame on companies like Qualcomm, Broadcom, Imagination Technologies (PowerVR), etc.

Go look at any of the non-microcontroller RISC-V based SoCs. It's not any better on any metric. Upstream software support is little to non-existent. Basically every RISC-V board needs a vendor kernel and they all have device tree and u-boot hell.

The SoC providers that make powerful chips are in the market of selling more chips - bad external support is a feature for them. Means that when they stop supporting the product you have to come buy a new chip. And if everyone does that, there's no better company to switch to because they all treat you the same.

About the only SoC vendor I have any respect for is Texas Instruments because they actually upstream a bunch of their code. Honestly I think this is because most of their parts are aimed industrial products and have support cycles >10 years.

I intentionally didn't say Rockchip because while they're in a bunch of hobby boards they don't really help with open source hardware work. They just take the position of "we won't stop you, but we're not going to help you".

Post reply on HN