MicroController control for switching regulator

On 12/26/2012 8:31 PM, rickman wrote:
> On 12/25/2012 8:45 AM, Nico Coesel wrote:
>> "RogerN"<regor@midwest.net> wrote:
>>
>>>
>>> I'm wanting to use a microcontroller to control the output of a
>>> switching
>>> regulator, maybe something like a LM2576 simple switcher. I see the
>>
>> Use a fast microcontroller (IOW: ARM) and use the PWM + ADC from the
>> controller to do what you want.
>>
>
> Wouldn't a PWM be rather slow to control the feedback to the switcher? A
> PWM takes time to settle to a new value if it has much resolution.
>
> Rick
This discussion has been all over the place, so we probably have different
perceptions of what's being discussed.

If you integrate the PWM and use it to control a switcher chip,
the integrator only affects the slew rate of the control input.
The dynamic characteristics are controlled by the switcher chip.

If you use the pulse output of the PWM to control the switch element,
there is no integrator.  You can have instantaneous control of the pulse
width by writing a register.  The dominant pole is the output filter.
As long as you can measure and calculate new pulse widths much faster
than the output filter will let it change, you're good to go.  At least
most of the engineers I've worked with would think they're good to go.
The more thoughtful ones might want to synchronize those register
writes with the current state of the PS subsystem so as not to put
undue stress on the components requiring even more time-critical
CPU timing resources.

And that smug look on the designer's face gets wiped clean the
first time he gets a call from manufacturing...
"hey Bill, we've got 25 piles of smoking chips come fix it...NOW!!!"
And you find that they got a run of boards with solder missing from
one end of a resistor.
The processor gets caught in an interrupt loop till the stack
overflows.  The switcher transistor turns on and smokes every
semiconductor on the board.

Good times...

I'm sure you can come up with
many situations where any bit of cleverness is a good thing.  But it's 
not a general solution.

If I have an 8-bit PIC that's already overkill for my device, it may be
sitting doing nothing 90% of the time.  But the timing requirements
of the power supply control loop may be incompatible with that 90% free
resource.  And even if you could apply your considerable creativity
and program interleaving skills, you create a maintenance nightmare.
Any time you make a change, you might have to worry more about how it
affects power supply stability than the feature itself.  That really
becomes a nightmare if there are two or more people on the development team.
And after you've moved on, who fixes bugs?

You don't just decide to let the microcontroller control the PS loop in
real time in every case.

It all depends on context.  A computer is not the optimal solution
for everything...even if YOU are clever enough to make it work.

On 12/27/2012 6:12 AM, Nico Coesel wrote:
> mike<ham789@netzero.net>  wrote:
>
>> On 12/27/2012 1:17 AM, Nico Coesel wrote:
>>
>>>
>>> Yes. PIC and other 8 bit controllers are a stepping stone anyway. At
>>> some point you have to move forward. Besides that the software to
>>> compile for ARM microcontrollers is completely free.
>>>
>> I could use a project.  Point me to your favorite free basic-like compiler
>> for the ARM.  Something with lots of available functions so I don't have
>> to reinvent
>> the wheel for I/O or display drivers or keyboard muxes data formatting etc.
>> Life is too short to program in C.
>> Period...I don't need or want to hear otherwise.
>
> http://www.eluaproject.net/
>
Thanks for the link.  Interesting read.
I'm sure that it's wonderful for a lot of stuff, but the overlap for me
is zip.

I only studied it or an hour, but I'm having a hard time believing
I can write a power supply control loop using an interpreted language
running on a virtual machine and have it fit in 8K. ;-)

I do hobby projects that interface hardware and do real-time-ish stuff
on a PIC.
The data gets sent out the rs232 port to a PalmIIIC that does all the
heavy lifting and user interface in an interpreted language where time
don't matter.  Saves a LOT of packaging grief for the touch screen
and display.

I keep trying to justify buying an Arduino, but giving up on all the
PIC infrastructure I've built over the years for no obvious gain
keeps it on the back burner.

mike <ham789@netzero.net> wrote:

>On 12/27/2012 6:12 AM, Nico Coesel wrote:
>> mike<ham789@netzero.net>  wrote:
>>
>>> On 12/27/2012 1:17 AM, Nico Coesel wrote:
>>>
>>>>
>>>> Yes. PIC and other 8 bit controllers are a stepping stone anyway. At
>>>> some point you have to move forward. Besides that the software to
>>>> compile for ARM microcontrollers is completely free.
>>>>
>>> I could use a project.  Point me to your favorite free basic-like compiler
>>> for the ARM.  Something with lots of available functions so I don't have
>>> to reinvent
>>> the wheel for I/O or display drivers or keyboard muxes data formatting etc.
>>> Life is too short to program in C.
>>> Period...I don't need or want to hear otherwise.
>>
>> http://www.eluaproject.net/
>>
>Thanks for the link.  Interesting read.
>I'm sure that it's wonderful for a lot of stuff, but the overlap for me
>is zip.
>
>I only studied it or an hour, but I'm having a hard time believing
>I can write a power supply control loop using an interpreted language
>running on a virtual machine and have it fit in 8K. ;-)

The idea is that you hire someone to write the fast bits in C and do
the rest yourself. If I look at the microcontroller projects I've
worked on (while getting paid) I see that about 95% of the code
doesn't need to be fast and doesn't deal with hardware but with
displays, buttons, network, etc.

-- 
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------

On 12/27/2012 9:21 PM, mike wrote:
> On 12/26/2012 8:31 PM, rickman wrote:
>>
>> Wouldn't a PWM be rather slow to control the feedback to the switcher? A
>> PWM takes time to settle to a new value if it has much resolution.
>>
>> Rick
> This discussion has been all over the place, so we probably have different
> perceptions of what's being discussed.
>
> If you integrate the PWM and use it to control a switcher chip,
> the integrator only affects the slew rate of the control input.
> The dynamic characteristics are controlled by the switcher chip.
>
> If you use the pulse output of the PWM to control the switch element,
> there is no integrator. You can have instantaneous control of the pulse
> width by writing a register. The dominant pole is the output filter.
> As long as you can measure and calculate new pulse widths much faster
> than the output filter will let it change, you're good to go. At least
> most of the engineers I've worked with would think they're good to go.
> The more thoughtful ones might want to synchronize those register
> writes with the current state of the PS subsystem so as not to put
> undue stress on the components requiring even more time-critical
> CPU timing resources.

Yes, after I wrote my post I read someone else's post who talked about 
using the PWM output to directly control the switch element.  So now I 
get it.


> And that smug look on the designer's face gets wiped clean the
> first time he gets a call from manufacturing...
> "hey Bill, we've got 25 piles of smoking chips come fix it...NOW!!!"
> And you find that they got a run of boards with solder missing from
> one end of a resistor.
> The processor gets caught in an interrupt loop till the stack
> overflows. The switcher transistor turns on and smokes every
> semiconductor on the board.
>
> Good times...

Aren't these types of designs done with a failsafe on the control output 
so that if the processor goes south the output shuts down?


> I'm sure you can come up with
> many situations where any bit of cleverness is a good thing. But it's
> not a general solution.
>
> If I have an 8-bit PIC that's already overkill for my device, it may be
> sitting doing nothing 90% of the time. But the timing requirements
> of the power supply control loop may be incompatible with that 90% free
> resource. And even if you could apply your considerable creativity
> and program interleaving skills, you create a maintenance nightmare.
> Any time you make a change, you might have to worry more about how it
> affects power supply stability than the feature itself. That really
> becomes a nightmare if there are two or more people on the development
> team.
> And after you've moved on, who fixes bugs?
>
> You don't just decide to let the microcontroller control the PS loop in
> real time in every case.
>
> It all depends on context. A computer is not the optimal solution
> for everything...even if YOU are clever enough to make it work.

Another reason to use an FPGA instead of an MCU.  In an FPGA everything 
can be done in parallel with no worry of having to time "share" the 
single resource.

Rick

On 12/27/2012 5:18 PM, krw@attt.bizz wrote:
> On Wed, 26 Dec 2012 23:51:09 -0500, rickman<gnuarm@gmail.com>  wrote:
>>
>> Hmmm... I guess it would require another chip or two, but would a
>> switched capacitor be a viable alternative to a bunch of resistors and
>> transistors?  I looked at these some ten or more years ago in filter
>> circuits; the capacitor switched between the input and output shuttling
>> current.  The faster it was switched the more current it carried and so
>> the lower resistance it appeared to be.   This allowed analog filters to
>> be continuously varied.  In this case it could allow for *relatively*
>> continuous adjustment of the feedback ratio by adjusting the switching
>> frequency.  This likely would be best done in an FPGA that can use a DCO
>> to drive the switch rate.  It has similar limitations to digital designs
>> and so needs a switching rate far above the frequency of interest.  I
>> guess that would rule it out for this app since the feedback has to be
>> adjusted fairly quickly.
>
> That sounds like it should work but just PWMing a switch and resistor
> in parallel with the bottom resistor will do the same thing.  The
> problem with either of these solutions is that you're going to see
> noise in the output because you can't easily filter the feedback node.

Yes, I see.  It would need to be switched pretty fast to mitigate the 
noise issue.

Rick

On 12/28/2012 8:15 AM, Nico Coesel wrote:
> mike<ham789@netzero.net>  wrote:
>
>> On 12/27/2012 6:12 AM, Nico Coesel wrote:
>>> mike<ham789@netzero.net>   wrote:
>>>
>>>> On 12/27/2012 1:17 AM, Nico Coesel wrote:
>>>>
>>>>>
>>>>> Yes. PIC and other 8 bit controllers are a stepping stone anyway. At
>>>>> some point you have to move forward. Besides that the software to
>>>>> compile for ARM microcontrollers is completely free.
>>>>>
>>>> I could use a project.  Point me to your favorite free basic-like compiler
>>>> for the ARM.  Something with lots of available functions so I don't have
>>>> to reinvent
>>>> the wheel for I/O or display drivers or keyboard muxes data formatting etc.
>>>> Life is too short to program in C.
>>>> Period...I don't need or want to hear otherwise.
>>>
>>> http://www.eluaproject.net/
>>>
>> Thanks for the link.  Interesting read.
>> I'm sure that it's wonderful for a lot of stuff, but the overlap for me
>> is zip.
>>
>> I only studied it or an hour, but I'm having a hard time believing
>> I can write a power supply control loop using an interpreted language
>> running on a virtual machine and have it fit in 8K. ;-)
>
> The idea is that you hire someone to write the fast bits in C and do
> the rest yourself. If I look at the microcontroller projects I've
> worked on (while getting paid) I see that about 95% of the code
> doesn't need to be fast and doesn't deal with hardware but with
> displays, buttons, network, etc.
>
Well, I believe you're mostly correct.  You can write your own
fast bits in whatever language works for you.
Still doesn't mean you can
always just cobble on something like a power supply control loop and
have it all work reliably and maintainably.
If you can, great.
Getting paid to write code is not the same job as getting paid
to decide what code to write.

On Tue, 25 Dec 2012 06:05:02 -0600, "RogerN" <regor@midwest.net>
wrote:

>
>I'm wanting to use a microcontroller to control the output of a switching 
>regulator, maybe something like a LM2576 simple switcher.  I see the 
>adjustability is on the feedback lead but what's the best way make it 
>adjustable from a microcontroller.  I'm guessing the feedback may be used in 
>switching timing, ie, I guess I can't just use a DAC and get an output of 
>1.23V more than the DAC output?  I want to monitor voltage and current and 
>use a control algorithm in the microcontroller (Arduino at first for 
>experimentation) for custom battery charging experimentation.
>
>RogerN
>

Somebody should do a GUI, vaguely LabView-ish, Windows app to design
digital power supply controllers around a uP or a DSP-based power
supply controller chip. Fill in the boxes and get both documentation
and compiled code. It may as well simulate, while it's at it. It could
output a nice PDF document for the record.

On Fri, 28 Dec 2012 11:56:05 -0500, rickman <gnuarm@gmail.com> wrote:

>On 12/27/2012 9:21 PM, mike wrote:
>> On 12/26/2012 8:31 PM, rickman wrote:
>>>
>>> Wouldn't a PWM be rather slow to control the feedback to the switcher? A
>>> PWM takes time to settle to a new value if it has much resolution.
>>>
>>> Rick
>> This discussion has been all over the place, so we probably have different
>> perceptions of what's being discussed.
>>
>> If you integrate the PWM and use it to control a switcher chip,
>> the integrator only affects the slew rate of the control input.
>> The dynamic characteristics are controlled by the switcher chip.
>>
>> If you use the pulse output of the PWM to control the switch element,
>> there is no integrator. You can have instantaneous control of the pulse
>> width by writing a register. The dominant pole is the output filter.
>> As long as you can measure and calculate new pulse widths much faster
>> than the output filter will let it change, you're good to go. At least
>> most of the engineers I've worked with would think they're good to go.
>> The more thoughtful ones might want to synchronize those register
>> writes with the current state of the PS subsystem so as not to put
>> undue stress on the components requiring even more time-critical
>> CPU timing resources.
>
>Yes, after I wrote my post I read someone else's post who talked about 
>using the PWM output to directly control the switch element.  So now I 
>get it.
>
>
>> And that smug look on the designer's face gets wiped clean the
>> first time he gets a call from manufacturing...
>> "hey Bill, we've got 25 piles of smoking chips come fix it...NOW!!!"
>> And you find that they got a run of boards with solder missing from
>> one end of a resistor.
>> The processor gets caught in an interrupt loop till the stack
>> overflows. The switcher transistor turns on and smokes every
>> semiconductor on the board.
>>
>> Good times...
>
>Aren't these types of designs done with a failsafe on the control output 
>so that if the processor goes south the output shuts down?


I like to AC couple the drive to switching mosfets, so a stuck-high
control signal doesn't turn them on full-blast.

Another trick is to have the software keep goosing a retriggerable
one-shot that enables the power stages somehow. Like, with a relay.


>
>
>> I'm sure you can come up with
>> many situations where any bit of cleverness is a good thing. But it's
>> not a general solution.
>>
>> If I have an 8-bit PIC that's already overkill for my device, it may be
>> sitting doing nothing 90% of the time. But the timing requirements
>> of the power supply control loop may be incompatible with that 90% free
>> resource. And even if you could apply your considerable creativity
>> and program interleaving skills, you create a maintenance nightmare.
>> Any time you make a change, you might have to worry more about how it
>> affects power supply stability than the feature itself. That really
>> becomes a nightmare if there are two or more people on the development
>> team.
>> And after you've moved on, who fixes bugs?

Put lots of comments in the source code. And fully document and
archive the build chain.


>>
>> You don't just decide to let the microcontroller control the PS loop in
>> real time in every case.
>>
>> It all depends on context. A computer is not the optimal solution
>> for everything...even if YOU are clever enough to make it work.
>
>Another reason to use an FPGA instead of an MCU.  In an FPGA everything 
>can be done in parallel with no worry of having to time "share" the 
>single resource.

A cheap-ish ARM has enough power to handle most switching power supply
loops.

On 12/28/2012 5:53 PM, John Larkin wrote:
> On Fri, 28 Dec 2012 11:56:05 -0500, rickman<gnuarm@gmail.com>  wrote:
>
>> On 12/27/2012 9:21 PM, mike wrote:
>>>
>>> You don't just decide to let the microcontroller control the PS loop in
>>> real time in every case.
>>>
>>> It all depends on context. A computer is not the optimal solution
>>> for everything...even if YOU are clever enough to make it work.
>>
>> Another reason to use an FPGA instead of an MCU.  In an FPGA everything
>> can be done in parallel with no worry of having to time "share" the
>> single resource.
>
> A cheap-ish ARM has enough power to handle most switching power supply
> loops.

I'm sure.  But once I started doing projects in small FPGAs I found the 
only real limitations are 1) packaging, not too many "dense" FPGAs in 
small packages (often not much of a limit really)  and 2) Inertia, most 
designers are just more comfortable with MCUs even if an FPGA is 
inherently simpler because no resources have to be shared.

BTW, are you physically unable to trim your posts?  It gets to be a real 
PITA try to read some of your stuff.

Rick

On 12/28/2012 5:48 PM, John Larkin wrote:
> On Tue, 25 Dec 2012 06:05:02 -0600, "RogerN"<regor@midwest.net>
> wrote:
>
>>
>> I'm wanting to use a microcontroller to control the output of a switching
>> regulator, maybe something like a LM2576 simple switcher.  I see the
>> adjustability is on the feedback lead but what's the best way make it
>> adjustable from a microcontroller.  I'm guessing the feedback may be used in
>> switching timing, ie, I guess I can't just use a DAC and get an output of
>> 1.23V more than the DAC output?  I want to monitor voltage and current and
>> use a control algorithm in the microcontroller (Arduino at first for
>> experimentation) for custom battery charging experimentation.
>>
>> RogerN
>>
>
> Somebody should do a GUI, vaguely LabView-ish, Windows app to design
> digital power supply controllers around a uP or a DSP-based power
> supply controller chip. Fill in the boxes and get both documentation
> and compiled code. It may as well simulate, while it's at it. It could
> output a nice PDF document for the record.


Open source or would you pay for this?  Sounds like a good companion app 
for LT Spice.

Rick