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.
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.
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 last year I've switched from fixed point to floating point after holding off on that switch for ~15 years.
The datasheet apparently doesn't say, but judging by their other products' listed 12 bit SAR ADC sampling rates (and assuming this one is similar to what appears to be their standard ADC ) the conversion time will be on the order of 10uS.
It's not that important if you use current sensors on the motor phases. But then you're looking at HALL sensors or a shunt with a very high gain amplifier with good common mode rejection - looking for mV signals on top of a +12V or +48V square wave at PWM frequency.
By using low-side shunts under each half-bridge you don't need the common mode rejection, but you can only measure phase current while the low side FET for that phase is on. That means limiting the PWM duty cycle to ensure that FET is on long enough to measure current, so we trade available voltage range for sample time.
I've also written code to measure all phase voltages with a single low-side current shunt under the whole 3-phase bridge. That requires careful phase shifting of the PWM signals and very fast conversion time, but you don't have to compromise available voltage range 0-100 percent duty cycle is possible.
Typically we run the control loop at PWM frequency, but the measurements need to be faster than that.
The closed loop experiences a phase margin loss that is exponential with the frequency. At lower frecuencies it is negligible, but if you get close to the frequency of the delay the phase margin reduction becomes dramatic and the control goes from stable to unstable very fast.
If the sensor has a limited bandwidth, you add the conversion delay and then the computation delay on top of that you end up with a max workable loop bandwidth in the low tens of kHz and anything higher will have overshoots, oscillations, etc.
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 actively displacing traditional approaches.
The core set of extensions has pretty friendly single letters, but the flip side is you run out of letters pretty quickly.
The non-single-letter extensions should make you feel more at home. Like the supervisor instructions. You have Smcntrpmf which helps with benchmarking by pausing perf counters during traps. I think Smcntrpmf just rolls off the tongue nicely.
Then there's a lot of extensions that start with Z followed by a sprinkling of random letters which is secretly an abbreviation you couldn't have guessed. For instance you have your SHA-2 instructions in Zvknha and Zvknhb, since that's the Vector Krypto NIST Hashes.
I see you are unfamiliar with `rv64mafdcbvh_zicsr_zicntr_zihpm_ziccif_ziccrse_ziccrse_ziccamoa_zicclsm_za64rs_zihintpause_zic64b_zicbom_zicbop_zicboz_zfhmin_zkt_zihintntl_zicond_zimop_zcmop_zcb_zfa_zawrs_supm_svade_ssccptr_sstvecd_sstvala_sscounterenw_svpbmt_svinval_svnapot_sstc_sscofpmf_ssnpm_ssu64xl_sstateen_shcounterenw_shvstvala_shtvala_shvstvecd_shvsatpa_shgatpa` also known as `RVA23`
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 hear ESP32.
ESP-IDF is only compatible with the ESP32 range of devices, not all ESP-prefixed devices, so "ESP" alone is not sufficient information to satisfy the earlier comment.
It's like these for other families too, you've got your STM32, then you can get the sub-models ranging from entry-level STM32C0 to the full Linux chips like the STM32MP2, with lots of options in the middle
Showing up in search results, or in this day and age LLM results, is still king. If your famous product is known as the ESP32, it doesn't hurt sales to spin other products off the same line. It might hurt clarity, glance value and many other things, but it will drive people to you.
I've been building hobby LED art projects with WLED (exclusively built on the ESP32 platform). It's been a blast. These little boards are so powerful and the open source community continues to amaze me.
My preferred controller platform is of the QuinLED line - comes with power distribution, voltage regulators, fat copper lines, configurable data-line resistors, and smart auxiliary hardware support all for an affordable $30-$50 per controller. (quinled.info)
<https://kno.wled.ge/> - WLED homepage and probably my favorite clever URL of all time.
I use a few hundred at most and in those cases I just feed power at several points in the chain to reduce resistive losses in the wiring. But yeah I'm kinda interested what kind of huge installations would need that and how they work.
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).
I mean a power controller. This is part of every WS2812 itself but with regular LEDs (be it RGB or not) you need power drivers for it, which I call the 'controller' too. You need to drive them at a certain amperage, then PWM them to get the right brightness. But with WS2812 you don't need to mess with power driver circuitry the OP mentioned. You just chain them to a microcontroller pin.
It was probably my use of the word 'controller' that is a bit confusing.
The specs look great, will see how long it takes to get these as WROOM modules or on little dev boards; my two form factors of choice for Espressif devices. I'm also curious about the pricing, so far they've impressed me with how much more you get in successive generations at a similar price.
Not "just", it's (presumably) 8 dedicated pins that form an RMII interface. This is not the same 8 pins as you'll find in your 4-pair Ethernet cable, it's a separate protocol which can be connected to an Ethernet PHY transciever like a TI DP83867E [1], which is further connected to "magnetics" [2], a convenient package of 8 integrated transformers and chokes that provide the galvanic isolation feature of an Ethernet connection.
A few SoCs provide integrated PHY transceivers, but usually it's an external chip.
Great to hear the adoption of RISC-V across the ESP32 line. The old Xtensa-based parts were fine, but RISC-V should make tooling, compiler support, and long-term ecosystem work cleaner
Is there any reason you want wireless? Bluetooth audio is a disaster, AFAIK. You don't want to use it for music. Just go wired, the ether is too cramped already.
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 chips just aren't quite powerful enough for high-quality music encoding, unfortunately. I'm hoping the S31 might be a bit better fit here (decent CPU boost + better SIMD).
Latency is still a bit rough with BT overhead. There might be some new options with LE audio on the S31 but I haven't found a way to get below ~80ms with the existing ESP32-S3 stack.
tl;dr, high quality voice is doable today with okay latency, music probably less so, maybe the S31 will be better
> I'm interested in audio out because I dabble in musical instruments.
Sorry, I don't know. I'm just responding to echo and expand on another reply that Bluetooth for anything related to serious music, from audio playback to MIDI input is a dumpster fire on Windows.
Several years ago I tried to set up a high-end Windows laptop for hobby DAW composition on the go. The real-world BT audio latency just from laptop to headphones/earbuds was unworkable and, separately, the input latency from BT midi controllers was unworkable. Stacked together the total lag was laughable.
At the time, the issues were widely known and much lamented. Some tech blogs (including one at MSFT) indicated there were issues at every level of the stack (drivers, firmware, silicon) and work was proceeding to address the end to end shit show. The only workable Windows solutions referenced online involved using specific non-Bluetooth wireless devices. Needing to have a dedicated USB dongle hanging off the laptop combined with having a choice of either one specific device or a receiver dongle to support all devices, is less appealing than just having a wire.
Since then I've looked again every year or so but have seen no reports yet of meaningful progress and there's even less discussion of work in progress. Very disappointing. And the situation on the BT audio quality side doesn't seem much better. If you don't want degraded audio quality it's either choosing very specific devices which support a proprietary BT codec or switching to non-BT wireless dongle hardware. At least there is talk of improvement on audio quality but no clear indication better baseline minimum audio quality will ever be mandated in the BT audio standard.
If anyone has info the baseline latency or quality (input or output) of standard BT devices in Windows configs will improve, I'd be delighted to hear it.
I'll mention that you usually need to put the BT connection in a low latency audio profile or else you're likely to get something more suitable for mp3-style high buffer playback.
This looks like the long-awaited replacement for the original ESP32. The S and C series have been relatively low performance (the S better than the C but stuck on the outgoing Xtensa architecture), the P4 is powerful but lacks wireless. This is a relatively high performance, dual core MCU with wireless; a nice default option for low volume designs where being able to copy a previous implementation is more important than saving a few cents. Just like the ESP32. Nice.
Has TLS been an issue since ESP32? I know ESP8266 had to increase CPU speed to be able to do RSA without timing out the watchdog. Wonderful hack. Didn't think ESP32 had the same issue.
I'm excited that this MCU and the P4 has RISC-V CLIC. That puts it at least on par with Cortex NVIC and enables bare metal frameworks like Rust RTIC to work really well.
Also 4x MCPWM peripherals; that's a first for any Espressif MCU.
The additional GPIOs are very welcome as well. CAN-FD!
This device is going to be a big hit for Espressif.
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.)
I was wondering this as well. What exactly makes this a good AI chip vs others.
Unless they're not listing a major feature in their spec, a dual core 320Mhz microcontroller is not bad but youre not going to be running any kind of vision model on it, at least very fast.
Memory is the main constraint. You have what, 8mb of psram.
Compute wise you can manage. You can do quantisation and run a small 10-15 layer CNN perhaps. Image classification is possible. Keep in mind the channel count and input resolution cannot be high since memory will be a problem. You can maybe do face _detection_, "is my cat on my keyboard" classification as well maybe.
Audio, you can do a lot more. Wake word detection happens on _much_ smaller accelerators inside iphones. In this one you can do slightly heavier classifications. Maybe speaker identification "which member of family" or maybe "which dog is barking"
As I understand it, Z-Wave is substantially more closed/proprietary. Both Thread and Zigbee are protocols that run on top of 802.15.4, which Espressif already has in other products.
I think Z-Wave is a bit more open now but everything I’m seeing indicates Zigbee has pretty thoroughly killed it by not requiring arduous certification processes and being generally easier to work with. Z-Wave is technically superior with the ability to have devices directly communicate with each other for basic functionality but at least for me that wasn’t worth the massive markup and I’m slowly replacing anything z-wave with Zigbee equivalents.
Zigbee supports binding, allowing devices to directly control each other without the intervention of a controller. For example, I've Inovelli light switches that communicate directly with Zigbee smart bulbs.
Z-Wave is completely different from Zigbee. Different frequency bands, modulation, etc.
And there are still just two suppliers of Z-Wave radios, as far as I know. I haven't bothered to re-check recently. Up until ~2022 there was just _one_ supplier, you could open any Z-Wave device and find exactly the same chip. Sometimes on a cute little daughter board.
How do I order a few samples, seem like there is a MOQ ?
Also I want to dive into hardware stuff but I'm always clueless as to what I do afterwards when this would arrive? Are you using a generic board or are you ordering and designing PCBs to hook this up to?
What are you using it for ? How do I go from a prototype to mass production via kickstarter?
Typically you look for a development board with the chip embedded on it. The dev board will have a usbc port and multiple pins that can be routed to LEDs, miniscreens, audio devices, etc. To program it you can usually use Lua (a very simple embedded language, almost JS-like) or you can use C/Rust/Zig as well. Arduino IDE works for it, too. You code from desktop and upload ROMs via USBC.
You can plug the dev board into sandwich board for easier prototyping. To go to mass production, you'll need to hand off your prototype spec to a custom PCB maker that you can order from, prices vary a lot based on volume and some shops specialize in low volume for early products.
Your end product should basically be a circuit board, case, battery, and any external components like LEDs or screens, then you assemble with plugs or wiring/soldering.
It is sometimes possible to make a product from the dev boards, especially the small ones, but your product still has to get a custom FCC certification (not a deal breaker, just a hoop to jump through), whether using dev board or custom.
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."
Espressif is all-in on RISC-V, expanding their portfolio of RISC-V devices where they previously had only XTensa: ESP32-S31 is the first big departure from the coincidental alignment of ISAs within their product structure and definitively ends further debate about what those letter designations mean.
BTW, S3 has an RISC-V core in addition to the XTensa cores. That's the part that's running in deep sleep.
In practice, most Espressif users barely know or care what ISA is in play: they have ESP-IDF and the Espressif libraries papering over the difference for nearly all purposes.
Corrected my comment, thank you. I mean, if productizing with them, global trade dynamics are certainly a supply chain risk factor, however, security concerns would be the primary reason such chips would be restricted from import.
Apparently available on AliExpress as a dev board[0]
[0] "ESP32-S31-Korvo-1 Development Board Espressif System AI Intelligent Multimedia Development Board Engineering Sample" for £54.79 from the (allegedly official) Espressif store at https://www.aliexpress.com/item/1005012333744553.html
I would like to make sure the library can be used on this SoC, and other RISC-V systems; which it probably can, but if there are any issues cross-compiling for it, or using the toolchain Espressif provides, please consider filing a bug report on GitHub at the link above. Same of course goes for any FOSS librar/tool that you're trying out.
Let's help foster a rich(er) ecosystem of software available on these babies!
And even if you don't need WiFi + BLE for a particular project, you may need it for other projects, and it might have value for you to standardise on one ecosystem.
Theoretically, yeah. Though at 320Mhz, with only 2.4ghz wireless, even with two cores, I doubt it's going to get anywhere near the throughput to fill the gigabit connection.
About the only one I can think of is connectivity in electronically noisy situations. It's a lot easier to find gigabit sfp modules for linking with fiber than it is to find 100 mbit modules.
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.
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 modern (Rust ;) embedded development.
>> 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 last year I've switched from fixed point to floating point after holding off on that switch for ~15 years.
From the ESP32-S31 datasheet: "Single-precision floating-point unit (FPU) per core"
The datasheet apparently doesn't say, but judging by their other products' listed 12 bit SAR ADC sampling rates (and assuming this one is similar to what appears to be their standard ADC ) the conversion time will be on the order of 10uS.
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?
>> Also why do you need 1uS for motor control?
It's not that important if you use current sensors on the motor phases. But then you're looking at HALL sensors or a shunt with a very high gain amplifier with good common mode rejection - looking for mV signals on top of a +12V or +48V square wave at PWM frequency.
By using low-side shunts under each half-bridge you don't need the common mode rejection, but you can only measure phase current while the low side FET for that phase is on. That means limiting the PWM duty cycle to ensure that FET is on long enough to measure current, so we trade available voltage range for sample time.
I've also written code to measure all phase voltages with a single low-side current shunt under the whole 3-phase bridge. That requires careful phase shifting of the PWM signals and very fast conversion time, but you don't have to compromise available voltage range 0-100 percent duty cycle is possible.
Typically we run the control loop at PWM frequency, but the measurements need to be faster than that.
The closed loop experiences a phase margin loss that is exponential with the frequency. At lower frecuencies it is negligible, but if you get close to the frequency of the delay the phase margin reduction becomes dramatic and the control goes from stable to unstable very fast.
If the sensor has a limited bandwidth, you add the conversion delay and then the computation delay on top of that you end up with a max workable loop bandwidth in the low tens of kHz and anything higher will have overshoots, oscillations, etc.
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 actively displacing traditional approaches.
> I don't know much about motor control
Then shut up.
I similarly don't know much about motor control or hardware in general, but would this maybe open up multiplexing options?
People will always find a reason to complain or pretend they are controlling rocket motor servos with their ESP32
where did you find cordic mention?
Curious: What does the "imac" stand for in the architecture target name ?
IMAC are the RISC-V extensions supported:
I = Base integer instruction set, 32-bit
M = Standard extension for integer multiplication and division
A = Standard extension for atomic instructions
C = Standard extension for compressed instructions
https://en.wikipedia.org/wiki/RISC-V#ISA_base_and_extensions
Thanks.I can't believe they chose non-arcane, memory-friendly letters. Kind of rare in naming hardware I feel (unless it's not ?)
The core set of extensions has pretty friendly single letters, but the flip side is you run out of letters pretty quickly.
The non-single-letter extensions should make you feel more at home. Like the supervisor instructions. You have Smcntrpmf which helps with benchmarking by pausing perf counters during traps. I think Smcntrpmf just rolls off the tongue nicely.
Then there's a lot of extensions that start with Z followed by a sprinkling of random letters which is secretly an abbreviation you couldn't have guessed. For instance you have your SHA-2 instructions in Zvknha and Zvknhb, since that's the Vector Krypto NIST Hashes.
I see you are unfamiliar with `rv64mafdcbvh_zicsr_zicntr_zihpm_ziccif_ziccrse_ziccrse_ziccamoa_zicclsm_za64rs_zihintpause_zic64b_zicbom_zicbop_zicboz_zfhmin_zkt_zihintntl_zicond_zimop_zcmop_zcb_zfa_zawrs_supm_svade_ssccptr_sstvecd_sstvala_sscounterenw_svpbmt_svinval_svnapot_sstc_sscofpmf_ssnpm_ssu64xl_sstateen_shcounterenw_shvstvala_shtvala_shvstvecd_shvsatpa_shgatpa` also known as `RVA23`
There are a few lettered extensions to the base RV32I instruction set. e.g.:
* https://docs.riscv.org/reference/isa/unpriv/m-st-ext.html
where did you find it?
The sooner ARM and its closed ecosystem dies, the better. The era of shitty half working blobs has gone on for quite long enough.
Nice. Been meaning to try rust on these sort of devices but the riscv I saw thus far seemed to be mixed arm and riscv which seemed weird
very interesting, do you have a pointer with more info on what kind of SIMD support it has?
Hopefully comparable or better than ESP32S3.
But with the weird alignment thing fixed
Why on earth SIMD instead of the risc-v vector extensions that are supposed to be better?
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 hear ESP32.
But it's the same scheme as STM32, EFM32, GD32, …
Yes and those schemes are just as bad as Espressif's
It signals ESP-IDF compatibility
They can signal that with numbers other than 32, the "ESP" part is what matters.
ESP-IDF is only compatible with the ESP32 range of devices, not all ESP-prefixed devices, so "ESP" alone is not sufficient information to satisfy the earlier comment.
It's like these for other families too, you've got your STM32, then you can get the sub-models ranging from entry-level STM32C0 to the full Linux chips like the STM32MP2, with lots of options in the middle
I kind of wish these all weren't called ESP32. ESP8266 and ESP8285 -> ESP32 made sense, but now we have 10+ different version
They've been hanging around with Sony.
Apple: AirPods
Sony: WMDF559J649Q-1
Showing up in search results, or in this day and age LLM results, is still king. If your famous product is known as the ESP32, it doesn't hurt sales to spin other products off the same line. It might hurt clarity, glance value and many other things, but it will drive people to you.
it's a marketing thing now
And toss away the brand name ?
I've been building hobby LED art projects with WLED (exclusively built on the ESP32 platform). It's been a blast. These little boards are so powerful and the open source community continues to amaze me.
My preferred controller platform is of the QuinLED line - comes with power distribution, voltage regulators, fat copper lines, configurable data-line resistors, and smart auxiliary hardware support all for an affordable $30-$50 per controller. (quinled.info)
<https://kno.wled.ge/> - WLED homepage and probably my favorite clever URL of all time.
I do a lot of LED projects too but I just use ws2812s. What do you need the controller for? Large brightness perhaps? Just curious.
WLED is a system that runs on the ESP32 for some cool capabilities to drive the ws2812s, OP linked above.
Yes but these don't need controller hardware. The OP is using a dedicated controller and I was asking why.
Probably the scale and usability of things. It's different if you're controlling 100 LEDs vs 5,000.
Yeah exactly that's what I was wondering about.
I use a few hundred at most and in those cases I just feed power at several points in the chain to reduce resistive losses in the wiring. But yeah I'm kinda interested what kind of huge installations would need that and how they work.
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).
WS2812 absolutely need a controller, without one they would simply not light up.
I mean a power controller. This is part of every WS2812 itself but with regular LEDs (be it RGB or not) you need power drivers for it, which I call the 'controller' too. You need to drive them at a certain amperage, then PWM them to get the right brightness. But with WS2812 you don't need to mess with power driver circuitry the OP mentioned. You just chain them to a microcontroller pin.
It was probably my use of the word 'controller' that is a bit confusing.
cr.yp.to/ is also a pretty cool URL, and has been around for a looong time
The specs look great, will see how long it takes to get these as WROOM modules or on little dev boards; my two form factors of choice for Espressif devices. I'm also curious about the pricing, so far they've impressed me with how much more you get in successive generations at a similar price.
If you're excited about the (relatively) speedy RISC-V cores and SIMD, look at the P4 which is available now. It has a slightly faster clock but no wireless: https://products.espressif.com/#/product-comparison?names=ES...
There's some cool work out there using the dsp functionality and built in image handling to crunch a lot of pixel data, which should work similarly on the S31: https://www.reddit.com/r/WLED/comments/1ry2jd7/wledmmp4_with...
Good to have WiFi and wired ethernet on the same part again.
Although we lost the MIPI support that the P4 dual-core RISC-V line has.
Dang would love to have both in the same chip.
How does wired internet technically work on these chips? Is it just 8 dedicated GPIO pins?
Not "just", it's (presumably) 8 dedicated pins that form an RMII interface. This is not the same 8 pins as you'll find in your 4-pair Ethernet cable, it's a separate protocol which can be connected to an Ethernet PHY transciever like a TI DP83867E [1], which is further connected to "magnetics" [2], a convenient package of 8 integrated transformers and chokes that provide the galvanic isolation feature of an Ethernet connection.
A few SoCs provide integrated PHY transceivers, but usually it's an external chip.
[1]: https://www.ti.com/lit/ds/symlink/dp83867e.pdf
[2]: https://yageogroup.com/content/datasheet/asset/file/DATASHEE...
Looks like you need an external PHY. It can talk to the PHY with RGMII which uses 12 pins, which are muxed with GPIO8-19.
You need a transceiver chip which then hooks up to the Ethernet jack.
Usually have to do this for any interface when the signals don't come in right at logic level, like CAN, RS-485...
although it's not always exactly 'just' logic level conversion.
Previous discussion from two months ago, when this was announced: https://news.ycombinator.com/item?id=47561678
Great to hear the adoption of RISC-V across the ESP32 line. The old Xtensa-based parts were fine, but RISC-V should make tooling, compiler support, and long-term ecosystem work cleaner
I'm interested in audio out because I dabble in musical instruments.
What's the state of Bluetooth audio out on microcontrollers? Is low latency and high quality output possible?
Is there any reason you want wireless? Bluetooth audio is a disaster, AFAIK. You don't want to use it for music. Just go wired, the ether is too cramped already.
There are alternatives, but being able to use an external amplified speaker and also move around easily would be nice. Maybe it's not feasible yet.
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.
You don't just use four simultaneously connected audio profiles and interleave 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 chips just aren't quite powerful enough for high-quality music encoding, unfortunately. I'm hoping the S31 might be a bit better fit here (decent CPU boost + better SIMD).
Latency is still a bit rough with BT overhead. There might be some new options with LE audio on the S31 but I haven't found a way to get below ~80ms with the existing ESP32-S3 stack.
tl;dr, high quality voice is doable today with okay latency, music probably less so, maybe the S31 will be better
> I'm interested in audio out because I dabble in musical instruments.
Sorry, I don't know. I'm just responding to echo and expand on another reply that Bluetooth for anything related to serious music, from audio playback to MIDI input is a dumpster fire on Windows.
Several years ago I tried to set up a high-end Windows laptop for hobby DAW composition on the go. The real-world BT audio latency just from laptop to headphones/earbuds was unworkable and, separately, the input latency from BT midi controllers was unworkable. Stacked together the total lag was laughable.
At the time, the issues were widely known and much lamented. Some tech blogs (including one at MSFT) indicated there were issues at every level of the stack (drivers, firmware, silicon) and work was proceeding to address the end to end shit show. The only workable Windows solutions referenced online involved using specific non-Bluetooth wireless devices. Needing to have a dedicated USB dongle hanging off the laptop combined with having a choice of either one specific device or a receiver dongle to support all devices, is less appealing than just having a wire.
Since then I've looked again every year or so but have seen no reports yet of meaningful progress and there's even less discussion of work in progress. Very disappointing. And the situation on the BT audio quality side doesn't seem much better. If you don't want degraded audio quality it's either choosing very specific devices which support a proprietary BT codec or switching to non-BT wireless dongle hardware. At least there is talk of improvement on audio quality but no clear indication better baseline minimum audio quality will ever be mandated in the BT audio standard.
If anyone has info the baseline latency or quality (input or output) of standard BT devices in Windows configs will improve, I'd be delighted to hear it.
I'll mention that you usually need to put the BT connection in a low latency audio profile or else you're likely to get something more suitable for mp3-style high buffer playback.
This looks like the long-awaited replacement for the original ESP32. The S and C series have been relatively low performance (the S better than the C but stuck on the outgoing Xtensa architecture), the P4 is powerful but lacks wireless. This is a relatively high performance, dual core MCU with wireless; a nice default option for low volume designs where being able to copy a previous implementation is more important than saving a few cents. Just like the ESP32. Nice.
Can it cope with TLS? The esp32 having a viable TLS stack has been a big win
Has TLS been an issue since ESP32? I know ESP8266 had to increase CPU speed to be able to do RSA without timing out the watchdog. Wonderful hack. Didn't think ESP32 had the same issue.
Anyway, the S31 has SHA, AES, ECC, RSA, and ECDSA accelerators, so that should be fine. https://documentation.espressif.com/esp32-s31_datasheet_en.p...
It looks like they've been adding more hardware crypto offloads too!
I'm excited that this MCU and the P4 has RISC-V CLIC. That puts it at least on par with Cortex NVIC and enables bare metal frameworks like Rust RTIC to work really well.
Also 4x MCPWM peripherals; that's a first for any Espressif MCU.
The additional GPIOs are very welcome as well. CAN-FD!
This device is going to be a big hit for Espressif.
> 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.)
I was wondering this as well. What exactly makes this a good AI chip vs others.
Unless they're not listing a major feature in their spec, a dual core 320Mhz microcontroller is not bad but youre not going to be running any kind of vision model on it, at least very fast.
Memory is the main constraint. You have what, 8mb of psram.
Compute wise you can manage. You can do quantisation and run a small 10-15 layer CNN perhaps. Image classification is possible. Keep in mind the channel count and input resolution cannot be high since memory will be a problem. You can maybe do face _detection_, "is my cat on my keyboard" classification as well maybe.
Audio, you can do a lot more. Wake word detection happens on _much_ smaller accelerators inside iphones. In this one you can do slightly heavier classifications. Maybe speaker identification "which member of family" or maybe "which dog is barking"
nope. not happening. at most YOLO or mayyybe FastDepth
Any reason why this device wouldn't have Z-Wave? Is the wireless protocol significantly different than Thread and Zigbee?
As I understand it, Z-Wave is substantially more closed/proprietary. Both Thread and Zigbee are protocols that run on top of 802.15.4, which Espressif already has in other products.
I think Z-Wave is a bit more open now but everything I’m seeing indicates Zigbee has pretty thoroughly killed it by not requiring arduous certification processes and being generally easier to work with. Z-Wave is technically superior with the ability to have devices directly communicate with each other for basic functionality but at least for me that wasn’t worth the massive markup and I’m slowly replacing anything z-wave with Zigbee equivalents.
Zigbee supports binding, allowing devices to directly control each other without the intervention of a controller. For example, I've Inovelli light switches that communicate directly with Zigbee smart bulbs.
I don't know for sure but Bluetooth, WiFi and Zigbee are on the same frequency band. Z-Wave is not.
(at least in the US, not sure about other countries)
This device only has a 2.4GHz radio. Z-Wave is sub-1GHz.
Z-Wave is completely different from Zigbee. Different frequency bands, modulation, etc.
And there are still just two suppliers of Z-Wave radios, as far as I know. I haven't bothered to re-check recently. Up until ~2022 there was just _one_ supplier, you could open any Z-Wave device and find exactly the same chip. Sometimes on a cute little daughter board.
How do I order a few samples, seem like there is a MOQ ?
Also I want to dive into hardware stuff but I'm always clueless as to what I do afterwards when this would arrive? Are you using a generic board or are you ordering and designing PCBs to hook this up to?
What are you using it for ? How do I go from a prototype to mass production via kickstarter?
Typically you look for a development board with the chip embedded on it. The dev board will have a usbc port and multiple pins that can be routed to LEDs, miniscreens, audio devices, etc. To program it you can usually use Lua (a very simple embedded language, almost JS-like) or you can use C/Rust/Zig as well. Arduino IDE works for it, too. You code from desktop and upload ROMs via USBC.
You can plug the dev board into sandwich board for easier prototyping. To go to mass production, you'll need to hand off your prototype spec to a custom PCB maker that you can order from, prices vary a lot based on volume and some shops specialize in low volume for early products.
Your end product should basically be a circuit board, case, battery, and any external components like LEDs or screens, then you assemble with plugs or wiring/soldering.
It is sometimes possible to make a product from the dev boards, especially the small ones, but your product still has to get a custom FCC certification (not a deal breaker, just a hoop to jump through), whether using dev board or custom.
ty!!!!
It being RISC-V is awesome, but how does it make sense that it's S series when S series have been Xtensa cores? Why is it not C series?
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."
Espressif is all-in on RISC-V, expanding their portfolio of RISC-V devices where they previously had only XTensa: ESP32-S31 is the first big departure from the coincidental alignment of ISAs within their product structure and definitively ends further debate about what those letter designations mean.
BTW, S3 has an RISC-V core in addition to the XTensa cores. That's the part that's running in deep sleep.
In practice, most Espressif users barely know or care what ISA is in play: they have ESP-IDF and the Espressif libraries papering over the difference for nearly all purposes.
Love to see more RISC-V in the wild
Is anyone else worried that these chips are all made in China?
I am concerned by all chips and software made by giant corporations. None of them are trustable, and any one of them will sell me out for a buck.
We must constantly fight to have open source and audited chips and software made in commodity fashion.
For what its worth, Espressif chips are open source, but yes, I wouldn't run national security or government devices on these.
Edit: I take it back on OS comment, they are not OS but some components of the SDK are:
https://zeus.ugent.be/blog/23-24/open-source-esp32-wifi-mac/
> Espressif chips are open source
No they're not? Anyway I assume GP was asking due to procurement concerns, not security.
Corrected my comment, thank you. I mean, if productizing with them, global trade dynamics are certainly a supply chain risk factor, however, security concerns would be the primary reason such chips would be restricted from import.
When can we buy these?
Apparently available on AliExpress as a dev board[0]
[0] "ESP32-S31-Korvo-1 Development Board Espressif System AI Intelligent Multimedia Development Board Engineering Sample" for £54.79 from the (allegedly official) Espressif store at https://www.aliexpress.com/item/1005012333744553.html
The dev boards are already up for sale. I'm personally looking forward to the modules being stocked on LCSC, no idea when though.
> The dev boards are already up for sale.
I didn't expect to see that for a while yet. Not the usual Espressif announce and wait a year+ pattern.
I'm the maintainer of a standalone printf library, targeting mostly embedded devices and other no-standard-library use cases:
https://github.com/eyalroz/printf/
I would like to make sure the library can be used on this SoC, and other RISC-V systems; which it probably can, but if there are any issues cross-compiling for it, or using the toolchain Espressif provides, please consider filing a bug report on GitHub at the link above. Same of course goes for any FOSS librar/tool that you're trying out.
Let's help foster a rich(er) ecosystem of software available on these babies!
This looks like a nucleo144, except its risc-v... but why would I use it over said nucleo144?
Better connectivity. The Nucleo 144 only has 100mbit ethernet, as far as I can tell, but the new ESP chip has gigabit, along with wireless.
WiFi+BLE?
And even if you don't need WiFi + BLE for a particular project, you may need it for other projects, and it might have value for you to standardise on one ecosystem.
I wish Espressif was an American company and publicly traded. I'd invest heavily. I have nothing but good things to say about their products.
Their product naming could be better; S3 is going to show S31 in the search results.
if it were American it probably would have been hostile-takeovered by Qualcomm or someone else and tightened down long ago.
The 1GB bandwidth is interesting. It also has Simd instructions too.
Could this theoretically be used as a router or wireguard vpn instance?
Theoretically, yeah. Though at 320Mhz, with only 2.4ghz wireless, even with two cores, I doubt it's going to get anywhere near the throughput to fill the gigabit connection.
Yeah, I’m not entirely sure what use cases there are which include both an ESP32 and gigabit networking.
About the only one I can think of is connectivity in electronically noisy situations. It's a lot easier to find gigabit sfp modules for linking with fiber than it is to find 100 mbit modules.