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