This is shaping up nicely!
I know you may argue that some STM32s are still better, but things are catching up fast. And having a second core is something I think none of the STM32s have, also the pio peripherals. Also the main point is they are catching up really fast, it was only what 3 years ago the rp2040 was released or something?
This is also really really good for other stuff aside from motor drive. Dual core and the other peripherals really help when you are using micropython, though the second core is not really working under micropython yet.
I hope they give us more memory for the PIO peripherals, that would really help. We could even offload the waveform generation to the pio peripheral, so it produces the sine wave, and that leaves the CPU free to do all the other stuff involved in motor drive, for instance. Or other stuff. Lots of things that can be used for. I used PIO recently to precisely measure RPM by counting a bunch of pulses. Some PWM peripherals have that functionality, but the point is it can do this and far more besides. And it’s from the RBPI foundation which means it’s stable for longer term, and an interesting new paradigm for getting very serious hardcore things done.
The processing power sounds great, but overkill for one motor, and not enough ADC channels for multi-motor drivers. 4 on the 60-pin package, 8 on 80-pin. At most 2 motors with current sense, and then you can’t use linear hall encoders, which are pretty much my only choice since none of my actuator designs ever have access to the end of the shaft for a magnetic encoder. EDIT: Corrected number of channels on 80-pin (I thought it was 7 before due to one being dedicated to temperature sensor), which means I could do a 4 motor driver without current sense and have enough for 2 linear halls per motor.
No shortage of PWM channels, though. 12 pairs, and it looks like you can invert their up/down phases and adjust duty individually, so you could potentially drive 4 motors in 6PWM or 8 in 3PWM Even 4x3PWM is a busy board design, so that’s more than anyone should ever need.
Would it be enough better than voltage-based current limiting to be worth doing? I know you can calculate the third phase from the other two, but I was under the impression that you need 3 sensors for good accuracy since the change in output per change in angle is small when near the peaks of the sine waves, so the signal can get lost in the noise. Using linear halls for position sensing is like that too. For precise control with current sense, I’d probably go to 3 halls per motor so the angle can be calculated from whichever two are farthest from their peaks.
I suppose I could do a not-super-precise dual motor driver with two current sensors and two linear halls per motor. But for the same cost and smaller footprint STSpin32 has enough channels for 3 current sensors and 3 halls per motor, and has one gate driver and a buck converter and 3V regulator built in, so I’ll probably stick with that.
Agree, RPi is an educational tool. But if it brings people to the table experimenting, it’s probably worth the effort. I’m still on the fence. It might have some niche use cases. The dual core and MHz/$ is a big plus.
I’ll add support for it as soon as I can get my hands on one, at least for the ARM cores.
I’m not clear yet on whether supporting the RISC-V would be interesting or not.
I also see a way to make low side current sensing work on this chip in terms of the ADC trigger.
But unfortunately the ADC isn’t any faster than the RP2040, and there’s still only one of them. Thus converting 3 currents would take >6us, and you essentially have the same limitations as the last model on that.
STM32 has controls on how many ADC samples to take, and make it faster at the accuracy expense, for current control it’s not that critical. rpi may be can lower that too and get it out faster?
Nah, unfortunately not. according to the datasheet one conversion takes 96 cycles, or 2us on the 48MHz ADC clock. That’s the fastest it can go, 500kSamples per second.
Keep in mind if you sample and convert 2 pins on one adc, the conversion of the 2nd pin can happen when the low side mosfets are off. What matters is the sampling.
As far as I am aware there is no sampling pipeline like that.
The 500kSamples given in the Datasheet works out to exactly 2us per sample, so I guess it both samples and converts one result before doing the next one.
Although we may have a bit of leeway on the last result due to what you’re saying…
Wow, that really is attractive even for single-motor control. And double precision float hardware will pretty much eliminate our problem of PID becoming unstable when the angle gets very large (although we will have to change all the floats to double throughout the code…)
The ADC speed is only an issue for low-side sensing, correct? Simple solution is to use inline hall current sensors like qvadrans.
Yes, for sure the better solution to use inline, like you say
I don’t see us changing all the floats to doubles just for the RP2050, plus gcc would have to support these coprocessors, is that the case already? Are they a standard ARM thing or RP2050-specific?
Even 4x3PWM is a busy board design, so that’s more than anyone should ever need.