| ▲ | randomint64 6 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 5 hours ago | parent | next [-] |
| >> 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 5 hours ago | parent | next [-] | | From the ESP32-S31 datasheet: "Single-precision floating-point unit (FPU) per core" | |
| ▲ | BenjiWiebe 5 hours ago | parent | prev | next [-] | | 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 5 hours ago | parent | prev | next [-] | | 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 4 hours ago | parent | next [-] | | >> 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. | |
| ▲ | topspin 4 hours ago | parent | prev | next [-] | | 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 an hour ago | parent [-] | | I didn’t know that. Thanks for letting me… meet the FOCers I’ll see myself out of the Internet now. |
| |
| ▲ | PowerElectronix 2 hours ago | parent | prev | next [-] | | 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 an hour ago | parent [-] | | 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. |
| |
| ▲ | nathanfries 4 hours ago | parent | prev | next [-] | | I similarly don't know much about motor control or hardware in general, but would this maybe open up multiplexing options? | |
| ▲ | greenavocado 5 hours ago | parent | prev | next [-] | | People will always find a reason to complain or pretend they are controlling rocket motor servos with their ESP32 | |
| ▲ | arabscum an hour ago | parent | prev [-] | | [flagged] | | |
| ▲ | benj111 an hour ago | parent [-] | | Have you never heard something that is surprising to you, and then asked for more information? Well no. Probably not... |
|
| |
| ▲ | NooneAtAll3 5 hours ago | parent | prev [-] | | where did you find cordic mention? |
|
|
| ▲ | cassepipe 6 hours ago | parent | prev | next [-] |
| Curious: What does the "imac" stand for in the architecture target name ? |
| |
| ▲ | mentalpagefault 5 hours ago | parent | next [-] | | 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 5 hours ago | parent [-] | | Thanks.I can't believe they chose non-arcane, memory-friendly letters. Kind of rare in naming hardware I feel (unless it's not ?) | | |
| ▲ | tux3 4 hours ago | parent | next [-] | | 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. | |
| ▲ | NekkoDroid 5 hours ago | parent | prev [-] | | 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` | | |
|
| |
| ▲ | JdeBP 5 hours ago | parent | prev | next [-] | | 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 | |
| ▲ | 5 hours ago | parent | prev | next [-] | | [deleted] | |
| ▲ | NooneAtAll3 5 hours ago | parent | prev [-] | | where did you find it? |
|
|
| ▲ | Havoc 5 hours ago | parent | prev | next [-] |
| 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 |
|
| ▲ | moffkalast an hour ago | parent | prev | next [-] |
| 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 an hour ago | parent [-] | | 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 6 hours ago | parent | prev [-] |
| very interesting, do you have a pointer with more info on what kind of SIMD support it has? |
| |
| ▲ | bobmcnamara 5 hours ago | parent | next [-] | | Hopefully comparable or better than ESP32S3. But with the weird alignment thing fixed | |
| ▲ | throwaway81523 4 hours ago | parent | prev [-] | | Why on earth SIMD instead of the risc-v vector extensions that are supposed to be better? |
|
