irrational Spicing

Floating point sucks for low frequency systems with relatively long time constants, anyway

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.

I dunno like, stars and stuff? Astrophyiscs stuff, maybe..

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.

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.

Real op amps don't, and SDpice is a bout modelling what real op amps do.

Every node on a Spice netlist is named, even if the names aren't user-friendly. Every .asc file has a date and a name, even if they aren't automatically designed to fit in with John Larkin's expectations.

Somebody who post pencil sketches as sloppy as his isn't really in a position to complain about LTSpice schematics.

Not always. Rounding error gets to be a problem when you subtract two big numbers and end up with a very small difference. Do it repeatedly, as you can when running a Spice simulation, and it can build up to an inconvenient error.

I ran into that as a graduate student when I was numerically integrating a differential equation to model the chemical reaction whose rate I was trying to measure. A couple of critical variables had to be triple precision numbers to keep the integral stable.

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

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

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.

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.

I believe that's correct... but you only get the low 32 bits of the

The biquad bandpass works fine for my needs... it's stable and fast enough. Since I've only got a dozen or so biquads, I don't bother to pre-compile all of the coefficients... I just compute them at startup time (based on the frequency and desired Q) using software floating-point, and then convert to fixed-point. Doesn't matter if it takes a millisecond or two at that moment :-)

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

RP2040 costs 70 cents in any quantity. It is cool that the Pi products have no quantity pricing.

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

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.

Yes, should be doable.

Reducing loop BW means you need more output capacitance, so increases cost and slows transient response.

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.

At 70 cents each, we can just buy 100,000.

This will be a "zero order" loop. I'll take my AC feedback from the half-bridge switch output, added to a slower DC feedback from the actual power supply output. So the output filter and whatever weird customer load won't affect loop dynamics.

The transfer function from 0...1 PWM to the switcher output is 48. It's not hard to close a stable loop around a dimensionless gain, so adding 18 degrees is fine.

As noted, the output capacitance won't affect loop dynamics.

The RP2040 chip (the one on the Pico board) is guaranteed available for 10 years or so. At 70 cents, we could buy a lot of them too.