Sujet : Re: irrational Spicing
De : klauskvik (at) *nospam* hotmail.com (Klaus Vestergaard Kragelund)
Groupes : sci.electronics.designDate : 02. Nov 2024, 00:44:39
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vg3p57$3evvh$1@dont-email.me>
References : 1 2 3 4 5 6 7 8
User-Agent : Mozilla Thunderbird
On 01-11-2024 15:44, john larkin wrote:
On Fri, 1 Nov 2024 08:41:35 +0100, Klaus Vestergaard Kragelund
<klauskvik@hotmail.com> wrote:
On 31-10-2024 21:50, john larkin wrote:
On Thu, 31 Oct 2024 12:17:49 -0700, dplatt@coop.radagast.org (Dave
Platt) wrote:
>
In article <rdg5ijl8fkfqe3u3kjffoa90rupsgdot48@4ax.com>,
john larkin <jl@glen--canyon.com> wrote:
>
The Pi Pico CPU, the RP2040, has integer math hardware but the floats
are "hardware assisted" subroutines in the rom bios. Single
add/sub/mul floats take around 600 ns, roughly 100 instructions, which
is kinda slow for my application, four power supply control loops.
>
Roger that. I've recently finished porting a simple software "modem"
(ham-radio packet TNC) over from an STM32F411-based prototype, to a
Pico. The STM part has hardware single-precision floating point, and
each signal pipeline (a bunch of biquad filters) was taking about 5%
of the CPU. On the Pico, using the generic libc software floating-
point libraries (which are pretty poor for the M0 core) each pipeline
was taking about 35% of the CPU, and since I wanted three of them running
in parallel, it was a no-good situation. I haven't yet figured out how
to get the Zephyr library system to link into the "hardware assisted"
floating-point emulation in the ROM, and I'm not sure even that would
be fast enough for my needs.
>
I switched over to a simple 1.15.16 fixed-point implementation of the
biquad filters. The performance was about 3x better, even though the
M0 doesn't have a 32x32->64 integer multiplier in hardware (the library
emulates one using four 16x16->32 multiplies).
>
>
I'm planning to use the same math format, only I call it S16.16. That
covers +-32 kilovolts with 15 uV resolution, which should be fine.
>
The RP2040 manual says it will do a 32x32 mul in one clock, 7 ns. If
that's not true, we can do hacks, like what you suggest, or round
parameters up or down enough to use shifts instead of multiplies.
>
I'll have four power supplies to service. We'll need to read an
8-channel SPI ADC to slurp the voltages and currents, do the voltage
regulation and current limit loops, and generate four PWMs into the
DRV8962 quad switcher thing.
>
The power supply loop bw will be under 1 KHz, so we should have plenty
of horsepower to do the math. It's a dual core ARM, so we will
dedicate one core to just those four control loops.
>
You would need to sample at least 40 times faster than the crossover, to
get phase erosion of less than 10 degrees. So in your case 40kHz.
>
Using fixed point math, this should be doable on a small
microcontroller, not needing a Pico to do that, but I guess, in your
application cost is not an issue.
RP2040 costs 70 cents in any quantity. It is cool that the Pi products
have no quantity pricing.
>
Of course the advantage of the RP2040 is plenty of RAM
40x seems extreme, but I'll add a couple of sample/hold blocks in the
sim and see what happens. It's just a power supply.
40x is not extreme. If you do not come close to that, then you need to design the loop for much higher phase margin (PM). Say you use 20x, then ypu will have phase erosion of 18degrees, so for actual 45 degrees PM, you would need to design for 64 degrees loop PM.
It's quite simple. When you sample, the loop runs, and you update the PWM after some time. That delay is subtracted from the designed phase margin. In analog controllers that happens without much delay.
But I'm confident we could run the required code at 40 KHz on a
dedicated CPU in the RP2040. That code would run entirely out of RAM.
Yes, should be doable.
We could even consider using floats. If we assume a 1 milliscond time
response, that's a 350 Hz loop bw, and 40x that is 14 KHz. That's
enough time for about 140 fp instructions, 35 per power supply.
Reducing loop BW means you need more output capacitance, so increases cost and slows transient response.
(People brutally overclock this chip too.)
I have used the Rpi, but not the Pico. Maybe I need to take that step. How does the supply chain look, are you sure you can get it after 5 years etc?