randomint64
16 hours ago
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
16 hours ago
>> 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
15 hours ago
From the ESP32-S31 datasheet: "Single-precision floating-point unit (FPU) per core"
BenjiWiebe
15 hours ago
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
15 hours ago
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
15 hours ago
>> 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.
actionfromafar
10 hours ago
That's wild. Would never have guessed.
topspin
15 hours ago
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.
tomcam
11 hours ago
I didn’t know that. Thanks for letting me… meet the FOCers
I’ll see myself out of the Internet now.
PowerElectronix
12 hours ago
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
11 hours ago
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
6 hours ago
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.
nathanfries
14 hours ago
I similarly don't know much about motor control or hardware in general, but would this maybe open up multiplexing options?
greenavocado
15 hours ago
People will always find a reason to complain or pretend they are controlling rocket motor servos with their ESP32
NooneAtAll3
16 hours ago
where did you find cordic mention?
amelius
10 hours ago
Yeah but the moment you need IP blocks like for wifi or ethernet or usb, it's back to square one.
nine_k
8 hours ago
I suppose ESP32-based modules usually carry networking and USB hardware which is immediately usable, without esoteric IP licenses, don't they?
kelnos
an hour ago
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.
taude
9 hours ago
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
9 hours ago
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.
hugojan
3 hours ago
At least part of what you describe is already being built: https://www.schematik.io/
ecesena
6 hours ago
For firmware dev, Claude is amazing. Just plug the dev board and tell him what you need. Great learning tool too!
cassepipe
16 hours ago
Curious: What does the "imac" stand for in the architecture target name ?
mentalpagefault
16 hours ago
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
15 hours ago
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
15 hours ago
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
10 hours ago
rva23 is pretty friendly.
Needn't use the long thing.
tux3
15 hours ago
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
16 hours ago
There are a few lettered extensions to the base RV32I instruction set. e.g.:
NooneAtAll3
16 hours ago
where did you find it?
ape4
9 hours ago
Its good you can do that but the command doesn't exactly roll off the tongue.
Havoc
15 hours ago
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
tosh
16 hours ago
very interesting, do you have a pointer with more info on what kind of SIMD support it has?
bobmcnamara
15 hours ago
Hopefully comparable or better than ESP32S3.
But with the weird alignment thing fixed
throwaway81523
14 hours ago
Why on earth SIMD instead of the risc-v vector extensions that are supposed to be better?
moffkalast
12 hours ago
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
11 hours ago
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".