| Deutsch English Français Italiano |
|
<vg3pad$3evvh$2@dont-email.me> View for Bookmarking (what is this?) Look up another Usenet article |
Path: ...!weretis.net!feeder9.news.weretis.net!news.quux.org!eternal-september.org!feeder2.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Klaus Vestergaard Kragelund <klauskvik@hotmail.com> Newsgroups: sci.electronics.design Subject: Re: irrational Spicing Date: Sat, 2 Nov 2024 00:47:25 +0100 Organization: A noiseless patient Spider Lines: 82 Message-ID: <vg3pad$3evvh$2@dont-email.me> References: <s235ijtgigajtlkef252jj38k0s0elvusj@4ax.com> <mu75ijtakpr25p7iu23a8lln3vc14r25iq@4ax.com> <6722af50$4$212409$882e4bbb@reader.netnews.com> <rdg5ijl8fkfqe3u3kjffoa90rupsgdot48@4ax.com> <tn1dvk-f20h.ln1@coop.radagast.org> <11p7ij12mv37pnq1du8fki8n4fn8ibqrm1@4ax.com> <vg20nf$35bfs$1@dont-email.me> <1bp9ijlocsml03er6doctbjh3jo57kq6bl@4ax.com> <vg3p57$3evvh$1@dont-email.me> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Sat, 02 Nov 2024 00:47:25 +0100 (CET) Injection-Info: dont-email.me; posting-host="7b3b8cdf96b36f4a407c97e6c30dc63c"; logging-data="3637233"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18uwoJxBdnLmBkBfp7xuGXXHqdalsugMjU=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:v1PBF2TB0trQfVi9w/Zcdlb/3aA= In-Reply-To: <vg3p57$3evvh$1@dont-email.me> Content-Language: en-US Bytes: 5395 On 02-11-2024 00:44, Klaus Vestergaard Kragelund wrote: > 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. > https://www.youtube.com/live/a64UIK1dFXA?si=N7CTuunNsOVWi1jq&t=1101