Things I've seen, and even done, in Spice sims...
Bypassing voltage sources (not me!)
Worrying about resistor power dissipation
Using standard parts values, like 4.7K ohms or 33nF, when the control
loop will be mostly code anyhow
Using +-12 or some such opamp supply voltages, and scaling signal
levels to fit. The LT Spice universal opamps will work with hundreds,
or thousands, of volt supplies.
Drawing hideously ugly schematics without a title, author, date, or
named nodes.
So I'm rescaling a power supply sim (I'm waiting for a run to finish
now) to have everything in actual 1:1 units. Then we will write the
control loop code to work in those same real engineering units, not
some goofy scaled integers or anything like that.
Keeping everything in true units as floats is ideal, but the RP2040
floating point ops are kinda slow, so we may express things as 32-bit
values, 16 bits of signed integer and 16 bits of fraction, as a sort
of fast and cheap float. But 12.5 volts is still visibly 12.5, just
as if it were a float. That will be handy for debugging.
S16.16 is plenty good to express voltages and currents in a power
supply.
Things I've seen, and even done, in Spice sims...
Bypassing voltage sources (not me!)
Worrying about resistor power dissipation
Using standard parts values, like 4.7K ohms or 33nF, when the control
loop will be mostly code anyhow
Using +-12 or some such opamp supply voltages, and scaling signal
levels to fit. The LT Spice universal opamps will work with hundreds,
or thousands, of volt supplies.
Drawing hideously ugly schematics without a title, author, date, or
named nodes.
So I'm rescaling a power supply sim (I'm waiting for a run to finish
now) to have everything in actual 1:1 units. Then we will write the
control loop code to work in those same real engineering units, not
some goofy scaled integers or anything like that.
Keeping everything in true units as floats is ideal, but the RP2040
floating point ops are kinda slow, so we may express things as 32-bit
values, 16 bits of signed integer and 16 bits of fraction, as a sort
of fast and cheap float. But 12.5 volts is still visibly 12.5, just
as if it were a float. That will be handy for debugging.
S16.16 is plenty good to express voltages and currents in a power
supply.
On 10/30/2024 4:07 PM, john larkin wrote:
Things I've seen, and even done, in Spice sims...
Bypassing voltage sources (not me!)
Worrying about resistor power dissipation
Using standard parts values, like 4.7K ohms or 33nF, when the control
loop will be mostly code anyhow
Using +-12 or some such opamp supply voltages, and scaling signal
levels to fit. The LT Spice universal opamps will work with hundreds,
or thousands, of volt supplies.
Drawing hideously ugly schematics without a title, author, date, or
named nodes.
So I'm rescaling a power supply sim (I'm waiting for a run to finish
now) to have everything in actual 1:1 units. Then we will write the
control loop code to work in those same real engineering units, not
some goofy scaled integers or anything like that.
Keeping everything in true units as floats is ideal, but the RP2040
floating point ops are kinda slow, so we may express things as 32-bit
values, 16 bits of signed integer and 16 bits of fraction, as a sort
of fast and cheap float. But 12.5 volts is still visibly 12.5, just
as if it were a float. That will be handy for debugging.
S16.16 is plenty good to express voltages and currents in a power
supply.
Floating point kind of sucks for low frequency systems with relatively
long time constants, anyway. There are applications that need 1800 dB of >dynamic range, audio isn't really one of them
On Wed, 30 Oct 2024 16:33:49 -0400, bitrex <user@example.net> wrote:
On 10/30/2024 4:07 PM, john larkin wrote:
Things I've seen, and even done, in Spice sims...
Bypassing voltage sources (not me!)
Worrying about resistor power dissipation
Using standard parts values, like 4.7K ohms or 33nF, when the control
loop will be mostly code anyhow
Using +-12 or some such opamp supply voltages, and scaling signal
levels to fit. The LT Spice universal opamps will work with hundreds,
or thousands, of volt supplies.
Drawing hideously ugly schematics without a title, author, date, or
named nodes.
So I'm rescaling a power supply sim (I'm waiting for a run to finish
now) to have everything in actual 1:1 units. Then we will write the
control loop code to work in those same real engineering units, not
some goofy scaled integers or anything like that.
Keeping everything in true units as floats is ideal, but the RP2040
floating point ops are kinda slow, so we may express things as 32-bit
values, 16 bits of signed integer and 16 bits of fraction, as a sort
of fast and cheap float. But 12.5 volts is still visibly 12.5, just
as if it were a float. That will be handy for debugging.
S16.16 is plenty good to express voltages and currents in a power
supply.
Floating point kind of sucks for low frequency systems with relatively
long time constants, anyway. There are applications that need 1800 dB of
dynamic range, audio isn't really one of them
What has that much dynamic range?
Most real systems, especially my power supply, will have lots of free
noise dithering. That makes the variables have essentially infinite resolution.
On 10/30/2024 5:11 PM, john larkin wrote:
On Wed, 30 Oct 2024 16:33:49 -0400, bitrex <user@example.net> wrote:
On 10/30/2024 4:07 PM, john larkin wrote:
Things I've seen, and even done, in Spice sims...
Bypassing voltage sources (not me!)
Worrying about resistor power dissipation
Using standard parts values, like 4.7K ohms or 33nF, when the control
loop will be mostly code anyhow
Using +-12 or some such opamp supply voltages, and scaling signal
levels to fit. The LT Spice universal opamps will work with hundreds,
or thousands, of volt supplies.
Drawing hideously ugly schematics without a title, author, date, or
named nodes.
So I'm rescaling a power supply sim (I'm waiting for a run to finish
now) to have everything in actual 1:1 units. Then we will write the
control loop code to work in those same real engineering units, not
some goofy scaled integers or anything like that.
Keeping everything in true units as floats is ideal, but the RP2040
floating point ops are kinda slow, so we may express things as 32-bit
values, 16 bits of signed integer and 16 bits of fraction, as a sort
of fast and cheap float. But 12.5 volts is still visibly 12.5, just
as if it were a float. That will be handy for debugging.
S16.16 is plenty good to express voltages and currents in a power
supply.
Floating point kind of sucks for low frequency systems with relatively
long time constants, anyway. There are applications that need 1800 dB of >>> dynamic range, audio isn't really one of them
What has that much dynamic range?
I dunno like, stars and stuff? Astrophyiscs stuff, maybe..
Most real systems, especially my power supply, will have lots of free
noise dithering. That makes the variables have essentially infinite
resolution.
All sampled signals have an ENOB, even analog storage scopes and >bucket-brigade delays have an implied resolution...I know audio BBDs
sure are noisy despite their "infinite resolution" without companding.
On "big iron" these days like x86 and smartphones all audio
processing-stuff tends to be floating point with full-scale defined as 1
and -1, for either 24 or 53 bits of mantissa, depending, so you can
leverage SIMD/MME instructions.
It usually make sense just to use double precision for everything except >long-term storage nowadays unless there's some pressing reason to need
more SIMD processing throughput and/or conserve RAM.
Things I've seen, and even done, in Spice sims...
Bypassing voltage sources (not me!)
Worrying about resistor power dissipation
Using standard parts values, like 4.7K ohms or 33nF, when the control
loop will be mostly code anyhow
Using +-12 or some such opamp supply voltages, and scaling signal
levels to fit. The LT Spice universal opamps will work with hundreds,
or thousands, of volt supplies.
Drawing hideously ugly schematics without a title, author, date, or
named nodes.
So I'm rescaling a power supply sim (I'm waiting for a run to finish
now) to have everything in actual 1:1 units. Then we will write the
control loop code to work in those same real engineering units, not
some goofy scaled integers or anything like that.
Keeping everything in true units as floats is ideal, but the RP2040
floating point ops are kinda slow, so we may express things as 32-bit
values, 16 bits of signed integer and 16 bits of fraction, as a sort
of fast and cheap float. But 12.5 volts is still visibly 12.5, just
as if it were a float. That will be handy for debugging.
S16.16 is plenty good to express voltages and currents in a power
supply.
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.
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 not getting _quite_ as good receive sensitivity on the Pico as
I was on the STM32F411, and this might be due to the slightly lower
precision of the fixed-point biquad filter... but I strongly suspect
it's actually due to the RP2040's notoriously non-linear ADC (I
think they quote ENOB of around 9.5 bits).
The RP2040 manual says it will do a 32x32 mul in one clock, 7 ns.
"Biquad filter" is interesting. I like to simuate classic analog
filters in code, biquads or even sallen-keys. Real DSP jocks sneer and
want a forest of swirling s-1's and muls and adds, but the analog
models usually work better.
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.
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.
Of course the advantage of the RP2040 is plenty of RAM
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.
Of course the advantage of the RP2040 is plenty of RAM
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.
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.
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.
(People brutally overclock this chip too.)
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.
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?
In article <vg3p57$3evvh$1@dont-email.me>,
Klaus Vestergaard Kragelund <klauskvik@hotmail.com> wrote:
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?
The company has committed to making the RP2040 and Pico available for
the next ten years. The newer Pico2 is good for a couple of years
beyond that. That's not to say that things couldn't go BLOOIE sooner
than that, of course... but the Pi company seems to be staking some
of their rep on making this a product with a good long supply
lifetime.
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.
Reducing loop BW means you need more output capacitance, so increases
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.
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?
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 418 |
| Nodes: | 16 (1 / 15) |
| Uptime: | 03:13:34 |
| Calls: | 8,787 |
| Calls today: | 14 |
| Files: | 13,296 |
| Messages: | 5,965,640 |