[randomint64]

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.

[phkahler]

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

[polpo]

From the ESP32-S31 datasheet: "Single-precision floating-point unit (FPU) per core"

[BenjiWiebe]

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.

[BenjiWiebe]

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?

[phkahler]

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

[namibj]

You can also have two shunts per phase, one low side and one high side. The "hall" "shunts" are pretty good though.

[actionfromafar]

That's wild. Would never have guessed.

[topspin]

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.

[imtringued]

But even if you update your PWM signal on every PWM cycle, you won't go much beyond 30kHz. At some point you're running into high switching losses on your MOSFETs.

[namibj]

There are solutions to those worries.... https://epc-co.com/epc/products/gan-fets-and-ics/epc23102

[tomcam]

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

I’ll see myself out of the Internet now.

[PowerElectronix]

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.

[topspin]

You see this in low cost products like MKS SERVO42x, where they're doing FoC with a GD32 MCU. It works; the motor runs cool, smooth and quiet, but the system is limited to 3000 RPM, and struggles with rapid acceleration because the control loop is too slow.

[mianos]

I have tried one. It has no torque. For what looks like an awesome product, it does not have the power to drive a peristaltic pump. I used the same motor on a TMC stepper controller and it's completely silent and works. It's open loop, so comparing apples to oranges but I am not sure what the MKS servo driver on a motor could actually do, aside from spin unloaded.

[topspin]

These can deliver 2.5-3A/phase, which should ample for a pump. Respectfully, I wonder what motor was involved and whether the current was configured: they come out of the box with conservative configuration so people don't burn up motors.

[GeorgeTirebiter]

This is exactly correct. Low 10s of kHz is quite functional for machines moving in human space / speed.

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

[nathanfries]

I similarly don't know much about motor control or hardware in general, but would this maybe open up multiplexing options?

[greenavocado]

People will always find a reason to complain or pretend they are controlling rocket motor servos with their ESP32

[andynerd]

Both HP cores have single-precision FPU. But only HP core 1 has SIMD, unlike S3 and P4.

[NooneAtAll3]

where did you find cordic mention?

[amelius]

Yeah but the moment you need IP blocks like for wifi or ethernet or usb, it's back to square one.

[nine_k]

I suppose ESP32-based modules usually carry networking and USB hardware which is immediately usable, without esoteric IP licenses, don't they?

[kelnos]

The wifi bits are closed-source blobs. The rust embedded community has reverse-engineered some of it for some chips, but not sure how complete that work is.

[jamesmunns]

It's worth noting that the support for ESP32 in Rust is official [0], and there are multiple full time engineers at Espressif working on developing and maintaining it.

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

[cassepipe]

Curious: What does the "imac" stand for in the architecture target name ?

[mentalpagefault]

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

[cassepipe]

Thanks.I can't believe they chose non-arcane, memory-friendly letters. Kind of rare in naming hardware I feel (unless it's not ?)

[NekkoDroid]

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`

[snvzz]

rva23 is pretty friendly.

Needn't use the long thing.

[NekkoDroid]

Yea, but remove any one of the extensions and you have a distinct arch with a name that is basically just as confusing.

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.

[sukuva]

RISC-V went wild with the extension naming in the past few years with the recently ratified extensions. The original extensions are all clubbed to be labelled as G.

[tux3]

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.

[JdeBP]

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

[NooneAtAll3]

where did you find it?

[taude]

I need the equivalent of Claude Code, but for hardware projects, so I can actually do all the projects I envision with the EPS32s.

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.

[all2]

Tbh, we're pretty close to that. This would essentially be the following set of work cells:

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

[ecesena]

For firmware dev, Claude is amazing. Just plug the dev board and tell him what you need. Great learning tool too!

[hugojan]

At least part of what you describe is already being built: https://www.schematik.io/

[Havoc]

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

[nekiwo]

ESP32-S3 already had SIMD, but Xtensa wasn't quite friendly about it.

https://bitbanksoftware.blogspot.com/2024/01/surprise-esp32-...

[ape4]

Its good you can do that but the command doesn't exactly roll off the tongue.

[moffkalast]

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

[Teknoman117]

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

[tosh]

very interesting, do you have a pointer with more info on what kind of SIMD support it has?

[bobmcnamara]

Hopefully comparable or better than ESP32S3.

But with the weird alignment thing fixed

[andylinpersonal]

The same as P4 rev 3.x, which is still undocumented. Assembler source and esp-nn/esp-dsp are your friend. Some people have also tried some stuff. And HP core 0 is scalar-only now.

[throwaway81523]

Why on earth SIMD instead of the risc-v vector extensions that are supposed to be better?

[andynerd]

For compatibility and simplicity. Most SIMD instructions in P4 and S31 (compatible with P4 rev 3.x) are an direct evolution from S3. Espressif just doesn't want to rewrite their optimized assembly libraries.