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).
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.
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.
https://bitbanksoftware.blogspot.com/2024/01/surprise-esp32-...
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".
But with the weird alignment thing fixed