On Sun, 1 Aug 2021 11:51:48 -0700, Don Y <blockedofcourse@foo.invalid>
wrote:

>On 8/1/2021 8:07 AM, Piotr Wyderski wrote:
>> Ed Lee wrote:
>>
>>> But FPGA cannot do the deep sleep as micro. Many micros can sleep in 100uA.
>>
>> Some FPGAs can go well below that, e.g. MachXO2. And this is a lot for an MCU;
>> MSP430 can go well below 1uA in sleep mode. They say it is in the 100nA range,
>> but I have never had the need to go that low, so I can't confirm.
>>
>> But the FPGA addresses the hard real time requirements of a switched converter
>> in a very natural way. In the case of an MCU it is always a PITA.
>
>There are MCUs that address those needs. The advantage of an MCU is that
>it is considerably easier to get it to do *other* things, as well.

The advantage of an FPGA is that it does everything simultaneously.

There are overlaps between procedural code and hard state machines,
but nobody wants to implement a web page server in a pure FPGA.

We have one pretty fancy control loop that runs at 40 MHz. Kinda tough
for a uP.

--

John Larkin Highland Technology, Inc

The best designs are necessarily accidental.

Don Y wrote:

> There are MCUs that address those needs.  The advantage of an MCU is that
> it is considerably easier to get it to do *other* things, as well.

The other things is precisely what will eventually lead you astray.
Power control is no joke, don't mess with it with an MCU, at least if
you don't plan to roast some marshmallows.

Best regards, Piotr

On 8/1/2021 12:37 PM, Piotr Wyderski wrote:
> Don Y wrote:
>
>> There are MCUs that address those needs. The advantage of an MCU is that
>> it is considerably easier to get it to do *other* things, as well.
>
> The other things is precisely what will eventually lead you astray.

Only if you aren't disciplined in your design approach.

> Power control is no joke, don't mess with it with an MCU, at least if you don't
> plan to roast some marshmallows.

I'm designing a PoE PD controller with one, presently.

On Sun, 1 Aug 2021 21:37:22 +0200, Piotr Wyderski
<bombald@protonmail.com> wrote:

>Don Y wrote:
>
>> There are MCUs that address those needs.  The advantage of an MCU is that
>> it is considerably easier to get it to do *other* things, as well.
>
>The other things is precisely what will eventually lead you astray.
>Power control is no joke, don't mess with it with an MCU, at least if
>you don't plan to roast some marshmallows.
>
> Best regards, Piotr

We have a programmable constant voltage/current supply thing, 12
channels per board, with each channel having its own floating uP that
does filtering and PID control. We use an LPC1754 at a 100 KHz
interrupt rate; the code runs for about 5 us per hit as I recall. We
cranked the CPU clock down to save power.

Arrow programs the chips for us.

A uP is fine for power supply control. They have ADCs, DACs, and PWMs.
Just do the code right.

--

John Larkin Highland Technology, Inc

The best designs are necessarily accidental.

On 8/2/2021 1:15, jlarkin@highlandsniptechnology.com wrote:
> On Sun, 1 Aug 2021 21:37:22 +0200, Piotr Wyderski
> <bombald@protonmail.com> wrote:
>
>> Don Y wrote:
>>
>>> There are MCUs that address those needs.  The advantage of an MCU is that
>>> it is considerably easier to get it to do *other* things, as well.
>>
>> The other things is precisely what will eventually lead you astray.
>> Power control is no joke, don't mess with it with an MCU, at least if
>> you don't plan to roast some marshmallows.
>>
>> Best regards, Piotr
>
> We have a programmable constant voltage/current supply thing, 12
> channels per board, with each channel having its own floating uP that
> does filtering and PID control. We use an LPC1754 at a 100 KHz
> interrupt rate; the code runs for about 5 us per hit as I recall. We
> cranked the CPU clock down to save power.
>
> Arrow programs the chips for us.
>
> A uP is fine for power supply control. They have ADCs, DACs, and PWMs.
> Just do the code right.
>
>
>

Of course they are fine. The first time I designed one for such
purposes was back in 1993... in this: http://tgi-sci.com/tgi/fr64.gif .
A HC11 was dedicated to monitor all the convertors (+5, +/-15, +/-24,
I may be forgetting some) and shut them off on over/undervoltage within
a ms or so, it also did the pwm to charge/maintain the battery,
connected to a ps2 keyboard (so the main CPU - a "mighty" 68340 - would
access it through it via spi) .... etc. etc. Ah yes, it stored
a lot of board unique trim values in its eeprom.
If designed correctly - with reset conditions etc. in mind - MCU-s
are a real blessing for power supply usage, have been for decades.

Dimiter

======================================================
Dimiter Popoff, TGI http://www.tgi-sci.com
======================================================
http://www.flickr.com/photos/didi_tgi/

On 2/8/21 1:07 am, Piotr Wyderski wrote:
> Ed Lee wrote:
>> But FPGA cannot do the deep sleep as micro.  Many micros can sleep in
>> 100uA.
> Some FPGAs can go well below that, e.g. MachXO2. And this is a lot for
> an MCU; MSP430 can go well below 1uA in sleep mode. They say it is in
> the 100nA range, but I have never had the need to go that low, so I
> can't confirm.
The MSP430 can keep a 32KHz real-time clock alive on under 1uA. That's
what drew me to it for a project in 2005, which had to run ten years off
a 2032 coin cell.

On 8/1/2021 3:42 PM, Dimiter_Popoff wrote:
> Of course they are fine. The first time I designed one for such
> purposes was back in 1993... in this: http://tgi-sci.com/tgi/fr64.gif .
> A HC11 was dedicated to monitor all the convertors (+5, +/-15, +/-24,
> I may be forgetting some) and shut them off on over/undervoltage within
> a ms or so, it also did the pwm to charge/maintain the battery,
> connected to a ps2 keyboard (so the main CPU - a "mighty" 68340 - would
> access it through it via spi) .... etc. etc. Ah yes, it stored
> a lot of board unique trim values in its eeprom.
> If designed correctly - with reset conditions etc. in mind - MCU-s
> are a real blessing for power supply usage, have been for decades.

How is it any different than letting a processor control a
delicate mechanism (that could be expensive to replace, recalibrate,
etc.)?

At it's heart, it's just "electronics" sequenced in a KNOWN manner.
You just need to be sure that "known manner" has been designed
robustly.

Or, that you are willing to tolerate some number of faults/failures
in the name of some sort of economy. Why do power supplies fail?
Isn't that an old, established technology??

On Monday, August 2, 2021 at 2:50:18 AM UTC+10, jla...@highlandsniptechnology.com wrote:
> On Sun, 1 Aug 2021 09:34:07 -0700 (PDT), Fred Bloggs <bloggs.fred...@gmail.com> wrote:
> >On Sunday, August 1, 2021 at 12:30:12 PM UTC-4, jla...@highlandsniptechnology.com wrote:
> >> On Sun, 1 Aug 2021 17:07:45 +0200, Piotr Wyderski <bom...@protonmail.com> wrote:
> >> >Ed Lee wrote:

<snip>

> >Stupid thread started by Sloman hallucinating about something he can't build in a million years. And all this in response to that mediocre moron Habib posing as an engineer again.

Fred Bloggs is seriously confused. The thread involved - "Low noise, high bias voltage on picoAmp TIA's input, howto?" was started by Timo, not me.

> Sloman hasn't designed anything in decades.

The thread "Low noise, high bias voltage on picoAmp TIA's input, howto?" did provoke me me into designing yet another version of the Baxandall Class-D oscillator.
John Larkin wasn't interested, so he didn't notice.

>The only thing he creates now and silly droning insults.

I don't flatter John Larkin as fulsomely as he thinks he deserves and he process that as "silly droning insults".
He finds the suggestion that he isn't quite as wonderful as he likes to think he is very painful, and he lashes out at the source of the pain.

Trimming his inflated self-image down to man-size might work better. He' s no Paul Bunyan.

> Being retired is mostly a choice, and that makes some people happy,
> but being a bitter old git sounds boring. It doesn't take much space
> or money to have a workbench and play with electronics.

Being retired isn't my choice. I do keep on applying for jobs, though I'm well aware that I'm much too old to be likely get one.
LTSpice does let me play with electronics. I've got a couple of projects that I could turn into working hardware if there was any prospect that I could find a customer who would want to use them

> I recently did a class-D power amp for my alternator simulator. People wanted to make that digital, but the PWM loop just took a few analog parts, and that was easy to Spice first.

He has given up posting his Spice simulations here. I remember one that was set up to run for 2msec. When I ran it there was something odd going on at 2msec, and I ran it for 10msec and found a problem that needed fixing and was easy to fix. John has been less specific in his boasting since then.

--
Bill Sloman, Sydney

On a sunny day (Sun, 1 Aug 2021 21:37:22 +0200) it happened Piotr Wyderski
<bombald@protonmail.com> wrote in <se6t5u$jltd$1@portraits.wsisiz.edu.pl>:

>Don Y wrote:
>
>> There are MCUs that address those needs.  The advantage of an MCU is that
>> it is considerably easier to get it to do *other* things, as well.
>
>The other things is precisely what will eventually lead you astray.
>Power control is no joke, don't mess with it with an MCU, at least if
>you don't plan to roast some marshmallows.
>
> Best regards, Piotr

Oh I dunno, my (own designed) lab supply has been running for > 15 years on a PIC
Point is many micro controllers have build in hardware,
that PIC has a PWM generator, (to drive the switcher) and hardware comparators
working directly on that PWM generator (for current and voltage control).
Have not put it to sleep at uA level, but you could.
The 'software' part drives the LCD display, the PIC has a build in multi channel ADC that reads voltage and current settings
from potmeters on front, the software via RS232 can set timers (for battery charging).

On Sunday, August 1, 2021 at 11:17:16 AM UTC-4, Piotr Wyderski wrote:
> Rick C wrote:
>
> > If you are using USB you can run that at 48 MHz all the time. The rest of the chip can run at 180 MHz all the time. Where's the issue?
> Anything useful running on an ICE40 at 180MHz? Boy, I would like to see
> that. My experience shows it is a decent small FPGA for the 50-100MHz
> range, but hardly more without heroic pipelining.

"Heroic pipelining"??? If you design ignoring speed, you will get a slow design in any FPGA. Pipelining is not particularly difficult when designing logic. I don't know the details of this design, but it sounds fairly simple to me. Then again, maybe you are right about the performance of the iCE40 line. The DSP sections which can run pipelined are only rated for 50 MHz if not pipelined. Not sure how that number should even be considered since it would require registers on the input and output to measure a clock rate. Are they the internal registers to the DSP section or fabric registers? This is a goofy spec to publish without information on what it means.

--

Rick C.

--+-+ Get 1,000 miles of free Supercharging
--+-+ Tesla referral code - https://ts.la/richard11209

On Sunday, August 1, 2021 at 12:48:33 PM UTC-4, Piotr Wyderski wrote:
> jla...@highlandsniptechnology.com wrote:
>
> > Analog comparators are cheap and don't need code!
> The need for code I took for granted, don't know Bill's requirements.
> But you are sort of right, an analog comparator driven by a DAC turns
> out to be a way cheaper and much faster option than an ADC followed by
> fully digital processing. Hybrid approaches work best.

Something is not right with your comparison. In one case you are starting with an analog signal and digitizing it in the other you are starting with a digital signal and turning it into analog (analogizing it?). Either the starting signal is analog or the starting signal is digital...

--

Rick C.

--++- Get 1,000 miles of free Supercharging
--++- Tesla referral code - https://ts.la/richard11209

On Sunday, August 1, 2021 at 3:37:40 PM UTC-4, Piotr Wyderski wrote:
> Don Y wrote:
>
> > There are MCUs that address those needs. The advantage of an MCU is that
> > it is considerably easier to get it to do *other* things, as well.
> The other things is precisely what will eventually lead you astray.
> Power control is no joke, don't mess with it with an MCU, at least if
> you don't plan to roast some marshmallows.

I've had this discussion with power control designers and they much prefer a processor. Sometimes a simple MCU is fast enough other times they want a DSP. Few of them use FPGAs or will even consider the possibility of using one. They typically want to shave the dollar or two extra the FPGA would cost coupled with an external ADC.

--

Rick C.

--+++ Get 1,000 miles of free Supercharging
--+++ Tesla referral code - https://ts.la/richard11209

On Sunday, August 1, 2021 at 7:50:41 PM UTC-4, Don Y wrote:
> On 8/1/2021 3:42 PM, Dimiter_Popoff wrote:
> > Of course they are fine. The first time I designed one for such
> > purposes was back in 1993... in this: http://tgi-sci.com/tgi/fr64.gif .
> > A HC11 was dedicated to monitor all the convertors (+5, +/-15, +/-24,
> > I may be forgetting some) and shut them off on over/undervoltage within
> > a ms or so, it also did the pwm to charge/maintain the battery,
> > connected to a ps2 keyboard (so the main CPU - a "mighty" 68340 - would
> > access it through it via spi) .... etc. etc. Ah yes, it stored
> > a lot of board unique trim values in its eeprom.
> > If designed correctly - with reset conditions etc. in mind - MCU-s
> > are a real blessing for power supply usage, have been for decades.
> How is it any different than letting a processor control a
> delicate mechanism (that could be expensive to replace, recalibrate,
> etc.)?
>
> At it's heart, it's just "electronics" sequenced in a KNOWN manner.
> You just need to be sure that "known manner" has been designed
> robustly.

I have actually seen data sheets that tell you to design "carefully", whatever that means. Is there an ISO spec for "carefully"? Designing "robustly" is the same sort of vague statement. It means whatever the speaker intends to to mean.

--

Rick C.

-+--- Get 1,000 miles of free Supercharging
-+--- Tesla referral code - https://ts.la/richard11209

Rick C wrote:

> Something is not right with your comparison. In one case you are starting with an analog signal and digitizing it in the other you are starting with a digital signal and turning it into analog (analogizing it?). Either the starting signal is analog or the starting signal is digital...

Digital gives you fancy control algorithm, analog gives you low latency.
If you need to react fast to the instant value of the current waveform,
the price of a sufficiently fast ADC can exceed the cost of the FPGA it
feeds, not to mention its output stream is often serial (crossing the
isolation boundary with fewer wires is one reason), which adds to the
delay. Moving the boundary conditions checking to the analog domain can
result in a cheaper and more reliable product. But I am referring to the
front-end, the control is provided by the FPGA in both cases.

In other words, relying on the ADC data implies relying on the events
long gone, whereas reconfiguring the DAC for the next cycle is preparing
for a future event with minimal delay. Closing this gap is certainly
possible, but requires $$$.

Best regards, Piotr

Rick C wrote:

> "Heroic pipelining"??? If you design ignoring speed, you will get a slow design in any FPGA.

https://www.latticesemi.com/-/media/LatticeSemi/Documents/DataSheets/iCE/FPGA-DS-02008-1-9-iCE40-UltraPlus-Family-Data-Sheet.ashx?document_id=51968

This FPGA is slow, to begin with. Have a look at the
register-to-register performance, section 4.19.2. A 16-bit adder is
specified to run at 100MHz and a 16:1 mux at 110MHz. And you want to
crank it at 180MHz while doying something non-trivial.

> Pipelining is not particularly difficult when designing logic.

If you want to go 63% faster than a 16:1 mux can go according to the
vendor, who is not interested in downplaying the performance of the
chip, nothing is straightforward.

> Then again, maybe you are right about the performance of the iCE40 line.

I'm just quoting the datasheet. This FPGA is slow, but cheap and rich
with features and has loads of RAM for the price.

Best regards, Piotr

On Monday, August 2, 2021 at 2:11:34 PM UTC-4, Piotr Wyderski wrote:
> Rick C wrote:
>
> > Something is not right with your comparison. In one case you are starting with an analog signal and digitizing it in the other you are starting with a digital signal and turning it into analog (analogizing it?). Either the starting signal is analog or the starting signal is digital...
> Digital gives you fancy control algorithm, analog gives you low latency.
> If you need to react fast to the instant value of the current waveform,
> the price of a sufficiently fast ADC can exceed the cost of the FPGA it
> feeds, not to mention its output stream is often serial (crossing the
> isolation boundary with fewer wires is one reason), which adds to the
> delay. Moving the boundary conditions checking to the analog domain can
> result in a cheaper and more reliable product. But I am referring to the
> front-end, the control is provided by the FPGA in both cases.
>
> In other words, relying on the ADC data implies relying on the events
> long gone, whereas reconfiguring the DAC for the next cycle is preparing
> for a future event with minimal delay. Closing this gap is certainly
> possible, but requires $$$.

You did not address a single issue I raised. Please read my post again and consider what I was talking about.

--

Rick C.

-+--+ Get 1,000 miles of free Supercharging
-+--+ Tesla referral code - https://ts.la/richard11209