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’ll see myself out of the Internet now.

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.

If one is trying to do some assembly line (max # of operations per second), the power requirements alone get hard to manage. And then you're managing back EMF, eddy currents, heck, air resistance!

My rule: have dedicated low-level hw provide smooth PID response, mostly on the P term; and have a higher-level control produce the setpoint. Faster response means less need to rely on I or D terms as much (just because delta-T is so relatively small).

Well no. Probably not...

[0]: https://github.com/esp-rs/esp-hal/

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

Needn't use the long thing.

The point I wanted to make is that nowadays a lot of the extensions do not have such a nice (semi) easy to remember name.

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.

* https://docs.riscv.org/reference/isa/unpriv/m-st-ext.html

Something that combines: 3d printing; auto procurement of parts; custom software writing; maybe a robot arms or something, all in a nice box on my desk that I feed parts into like a mail slot. PROFIT.

- PCB etching/engraving

- Solder placement

- component placement

- solder oven

This gets you one layer populated PCBs out the other side. Commercial systems like this exist in various forms, and open source projects for all of these also exist. It would be up to you to integrate them together.

As it stands, the frontier models are actually pretty ok at firmware dev at a high level. If you need max performance, they won't be any good at all (learning from the dregs of the internet isn't exactly helpful here). You'll also need to bring at least a willingness to learn about what is involved so you can debug the machine's mistakes.

But with the weird alignment thing fixed

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".

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.

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.

Espressif only have 312 SKUs [0]. You're telling me nobody could come up with a naming scheme where more than 2/3 of them don't have part numbers longer than 18 characters?

Doesn't really matter either way, but short part numbers do fit nicely in a BOM table without using really wide columns. (even though I usually find capacitors to have even longer names).

0 - https://products.espressif.com/#/product-selector

https://www.digikey.ca/short/2v4t0n5m

Part number was still just 15 characters, and that's enough to specify if you want the tape and reel version. Not that anyone's counting :).

I guess those long part numbers do get burned into your head after a while after all.

You're seeing either incompetence or conspiracy when the opposite is true.

(I don't have an issue with Espressif's ESP32-* naming scheme, but I don't think the ESP-IDF angle is a good argument for not changing it.)

They've been hanging around with Sony.

Apple: AirPods

Sony: WMDF559J649Q-1

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.

WS2812 with any ESP32 board is one way, and that's a perfectly fine way; individual addressable LEDs sure are neat as hell. Amazing stuff can be done with them. And as you already know, a Chinese ESP32 dev kit costing $2 is enough to do ~all the things with this on the controller side. :)

But there's other ways, too. At perhaps its simplest: Maybe RGB isn't your bag, and you just want groups (which could be strips or any other shape) of all one color that are smoothly-controllable with WLED.

This is electrically simpler: While individual WS2812 pixels each work as a little computer-brain repeater for a serial bus, a group of dumb LEDs can be as simple as just being a group of dumb LEDs. And that's easy; perhaps as easy as one PWM channel.

Or maybe it's more complex: Maybe the goal is something like a par can that shines RGBAW all in one direction. Now we need 5 PWM channels.

Anyway, the power electronics for doing PWM with dumb LEDs can be built or they can be bought, but they need to exist and to live somewhere.

QuinnLED sells devices with power electronics in packages ranging from bare boards, to complete units with metal housings that have power and real ethernet on one side of the box and LED outputs on the other side.

Since skillsets and willingness to go full-DIY vary, they present pretty nice range of options.

One box I just looked at, the QuinLED An-Penta-Plus: It's a box that has 5 channels of PWM, does up to 10A per channel, or up to 30A combined per box -- at up to 48VDC.

That's [up to] 30*48=1440 Watts of LED, which is getting in the realm of the silly. But environment/projects come in all sizes, people do silly things with LEDs sometimes, and that's all perfectly OK. WLED projects don't have to be small. :)

My question was why use bare LEDs with a separate PWM controller like QuinnLED instead of WS2812. But yes size could be an issue. Long strings of WS2812 tend to get slow and if they all need to do the same thing at the same time it's ok.

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.

It was probably my use of the word 'controller' that is a bit confusing.

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).

Then I'd pack 16 of them, and build a tiny Connection Machine cube.

Not sure what I'd use a cluster of 512 very puny servers for though... I guess it'd be for learning how to manage clusters with unreasonable numbers of nodes.

And yes the main goal is to figure out how to program the thing in a way that balances ease of use with performance.

I also like the idea of a PSRAM junction, so that every core gets a PSRAM, but neighbours can swap ownership.

I had wondered what happens to the wireless spectrum if you tried it with ESP32. 512 devices in a small space yelling at each other.

> Since bitwise operations can be relatively CPU-intensive and DMA is designed specifically to offload such work from the CPU, ESP32-S31 integrates two dedicated peripherals called BitScramblers. These modules are designed to transform data formats during transfers between memory and peripherals. One BitScrambler handles memory-to-peripheral (or memory-to-memory) transfers, while the other is dedicated to peripheral-to-memory transfers. While BitScramblers can handle the bitwise operations mentioned earlier, they are in fact flexible, programmable state machines capable of performing more advanced transformations as well.

Here's hoping that it's as useful as the Pi Pico's PIO

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

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.

Code is here:

https://github.com/bschwind/walkie-talkie

What exactly did you try?

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.

It's been a few years since the last time I actually tried it myself, instead of just checking user reports. I do remember I followed the DAW company's FAQ, set a mode in the DAW, and switched something in Windows settings related to BT. The wired latency (MIDI in and audio out) was excellent but switching either to BT tanked it.

It's frustrating that it appears to not have improved at all in a decade. I get the whole "good, fast, cheap" triangle and that most of the BT ecosystem only cares about "cheap" while being just good enough 128Kbps MP3s don't sound too much worse on $50 cuff link-sized earbuds. But I can't help naively thinking that on decadal timescales, the rising tide should lift even the "cheapest" corner of the triangle enough to yield slightly better minimum baseline quality - especially when it's been stuck forever at barely usable. Even more surprising is that BT gaming controllers still have such high latency, most BT controllers also come with a proprietary wireless dongle. Talk about pointless COGS and landfill.

I guess maybe the reason is those who really care can go wired, use non-BT wireless dongles or lock themselves to a proprietary vendor who controls both ends of the stack. But it kind of nerfs the point of having a short range wireless "standard" if doesn't cut COGS, landfill waste and never improves more 'serious' use cases even a little.

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 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.

"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."

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...

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.

Any way to know what kind of performance one could expect running e.g. a depth anything model on there?

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.)

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.

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"

Course more PSRAM and hardware encoding would drive up the price...

finally i can make party mode home speaker arrays

(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.

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.

[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 didn't expect to see that for a while yet. Not the usual Espressif announce and wait a year+ pattern.

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!

We must constantly fight to have open source and audited chips and software made in commodity fashion.

https://www.crowdsupply.com/baochip/dabao/updates/our-campai...

Probably the most open chip on the market, and sits between a pi and a pico

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.

Could this theoretically be used as a router or wireguard vpn instance?

0. https://news.ycombinator.com/item?id=48378136

https://news.ycombinator.com/item?id=48386133

Their product naming could be better; S3 is going to show S31 in the search results.