Re: irrational Spicing

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.

My power supply sim is in LT Spice, and most of the actual control
loop will be coded in c. So I'll have to work with my programmer to
scale the Spice model into code.

>
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).
>
>

Right. I'll use the 2040 ADC to monitor a power rail, and the sloppy
ADC will be fine there. We will software lowpass a bit.

"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.

You can do a single-pole lowpass filter in one short line of c code,
five or so lines of ASM.