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.
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.
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.
I don't know much about motor control, is it normal to need that fast of feedback?
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.
Fast feedback loops are also necessary in SMPS, another area where precision, low latency MCU peripherals and software are actively displacing traditional approaches.
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
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.
But with the weird alignment thing fixed
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.
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...
Although we lost the MIPI support that the P4 dual-core RISC-V line has.
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...
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.
What's the state of Bluetooth audio out on microcontrollers? Is low latency and high quality output possible?
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.
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
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.
Any way to know what kind of performance one could expect running e.g. a depth anything model on there?
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.
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.
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?
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.
(at least in the US, not sure about other countries)
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.
Just appending 1 to S3 is odd though. This MCU is step change for Espressif. S4 or something would make more sense.
BTW, S3 has an RISC-V core in addition to the XTensa cores. That's the part thats 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.
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/
No they're not? Anyway I assume GP was asking due to procurement concerns, not security.
I didn't expect to see that for a while yet. Not the usual Espressif announce and wait a year+ pattern.
Their product naming could be better; S3 is going to show S31 in the search results.
Could this theoretically be used as a router or wireguard vpn instance?