Forums

boost-converter trouble

Started by Winfield Hill November 20, 2018
bill.sloman@ieee.org wrote...
> > On Sun, November 25, 2018, John Larkin wrote: >> On Sat, 24 Nov 2018, "Tim Williams" wrote: >>> "John Larkin" wrote >>>> >>>> I don't think you'd need to sample that fast. >>> >>> If you're okay with exploding transistors and shitty >>> control loops, sure, sample just voltage. :-) >> >> If I know the voltage and control the gate drive, >> I know the currents. > > Another of John Larkin's over-confident assertions.
I'm curious to hear John's explanation. -- Thanks, - Win
On Sat, 24 Nov 2018 18:18:49 -0500, bitrex <user@example.net> wrote:

>On 11/24/2018 04:58 PM, Klaus Kragelund wrote: >> For a boost converter, it would be wise to add a current sense resistor in the source of the FET, and use a microcontroller that has a fast comparator. >> >> That way control is current mode, easier compensator design and has over current protection. Does require a good comparator to keep sense voltage low, both due to power loss and gate drive negative feedback >> >> Using microcontroller allows for a lot of extra features, the sky is almost the limit >> >> Cheers >> > Klaus >> > >Don't forget that current-mode control has a subharmonic instability >problem at duty cycles greater than 50%:
Then don't do that. Or compensate. -- John Larkin Highland Technology, Inc lunatic fringe electronics
On 25 Nov 2018 10:51:31 -0800, Winfield Hill
<hill@rowland.harvard.edu> wrote:

>bill.sloman@ieee.org wrote... >> >> On Sun, November 25, 2018, John Larkin wrote: >>> On Sat, 24 Nov 2018, "Tim Williams" wrote: >>>> "John Larkin" wrote >>>>> >>>>> I don't think you'd need to sample that fast. >>>> >>>> If you're okay with exploding transistors and shitty >>>> control loops, sure, sample just voltage. :-) >>> >>> If I know the voltage and control the gate drive, >>> I know the currents. >> >> Another of John Larkin's over-confident assertions. > > I'm curious to hear John's explanation.
If we know the circuit elements (we designed them!) and know the input and output voltages, and drive the mosfet gate, we can design a software control loop to make a good boost switcher. Heck, I have done boost and invert switchers with a schmitt gate and a fet and a few passives; surely a uP is smarter than that. If the input voltage is fixed/known, or measured, and we have a discontinuous switcher, the inductor current is predictable. So we can dump a controlled shot of energy onto the output cap every pulse. Knowing the output voltage and the applied power, we know the output current. A few hundred lines of c can surely be as smart as a few opamps and comparators. Maybe some modern switcher chips are actually DSP inside. -- John Larkin Highland Technology, Inc lunatic fringe electronics
John Larkin wrote...
> > If the input voltage is fixed/known, or measured, and we > have a discontinuous switcher, the inductor current is > predictable. So we can dump a controlled shot of energy > onto the output cap every pulse. Knowing the output > voltage and the applied power, we know the output current.
OK, and the input currents too, should work. I'm usually reluctant to dedicate a significant fraction of my processor's time to a simple job handled by a cheap sot-23-6 part. But, it's true, while the boost converter is charging the processor has to wait anyway, before doing anything else. Then when the voltage is up, LEDs on, and the processor is busy, I could use a timer channel to provide PWM, checking the voltage every now and then to be sure it hadn't deviated too much. -- Thanks, - Win
On 25 Nov 2018 12:50:37 -0800, Winfield Hill
<hill@rowland.harvard.edu> wrote:

>John Larkin wrote... >> >> If the input voltage is fixed/known, or measured, and we >> have a discontinuous switcher, the inductor current is >> predictable. So we can dump a controlled shot of energy >> onto the output cap every pulse. Knowing the output >> voltage and the applied power, we know the output current. > > OK, and the input currents too, should work. I'm > usually reluctant to dedicate a significant fraction > of my processor's time to a simple job handled by a > cheap sot-23-6 part. But, it's true, while the boost > converter is charging the processor has to wait anyway, > before doing anything else. Then when the voltage is > up, LEDs on, and the processor is busy, I could use a > timer channel to provide PWM, checking the voltage every > now and then to be sure it hadn't deviated too much.
My suggestion was to use a cheap uP as a switcher controller, where it has nothing else to do. You could probably sneak in a serial or SPI interface, which wouldn't take much compute power. Just a thought. It wouldn't be worth writing the code unless the savings were substantial and the quantities high. -- John Larkin Highland Technology, Inc picosecond timing precision measurement jlarkin att highlandtechnology dott com http://www.highlandtechnology.com
On 11/25/2018 05:07 PM, John Larkin wrote:
> On 25 Nov 2018 12:50:37 -0800, Winfield Hill > <hill@rowland.harvard.edu> wrote: > >> John Larkin wrote... >>> >>> If the input voltage is fixed/known, or measured, and we >>> have a discontinuous switcher, the inductor current is >>> predictable. So we can dump a controlled shot of energy >>> onto the output cap every pulse. Knowing the output >>> voltage and the applied power, we know the output current. >> >> OK, and the input currents too, should work. I'm >> usually reluctant to dedicate a significant fraction >> of my processor's time to a simple job handled by a >> cheap sot-23-6 part. But, it's true, while the boost >> converter is charging the processor has to wait anyway, >> before doing anything else. Then when the voltage is >> up, LEDs on, and the processor is busy, I could use a >> timer channel to provide PWM, checking the voltage every >> now and then to be sure it hadn't deviated too much. > > My suggestion was to use a cheap uP as a switcher controller, where it > has nothing else to do. You could probably sneak in a serial or SPI > interface, which wouldn't take much compute power. > > Just a thought. It wouldn't be worth writing the code unless the > savings were substantial and the quantities high. > >
idk what the counter-argument was exactly, that it can't be done or....? Clearly building switching controllers of some type are what uP manufacturers often expect people to do with their parts or why would they include hardware dead-time generators with a bunch of 'em cheap uPs have compute cycles to burn nowatimes as compared to e.g. a 6502, they're not your granpa's 8 bit. A 16 bit by 16 bit signed multiply on an AVR 8 bit takes only around 200 clocks average _without_ a hardware multiplier unit, you can run them to 20 MHz!
bitrex wrote...
> On 11/25/2018 05:07 PM, John Larkin wrote: >> On 25 Nov 2018 12:50:37 -0800, Winfield Hill wrote: >>> John Larkin wrote... >>>> >>>> If the input voltage is fixed/known, or measured, and we >>>> have a discontinuous switcher, the inductor current is >>>> predictable. So we can dump a controlled shot of energy >>>> onto the output cap every pulse. Knowing the output >>>> voltage and the applied power, we know the output current. >>> >>> OK, and the input currents too, should work. I'm >>> usually reluctant to dedicate a significant fraction >>> of my processor's time to a simple job handled by a >>> cheap sot-23-6 part. But, it's true, while the boost >>> converter is charging the processor has to wait anyway, >>> before doing anything else. Then when the voltage is >>> up, LEDs on, and the processor is busy, I could use a >>> timer channel to provide PWM, checking the voltage every >>> now and then to be sure it hadn't deviated too much. >> >> My suggestion was to use a cheap uP as a switcher controller, >> where it has nothing else to do. You could probably sneak >> in a serial or SPI interface, which wouldn't take much >> compute power. >> >> Just a thought. It wouldn't be worth writing the code unless the >> savings were substantial and the quantities high.
Well, it'd be a big pain, after automated assembly of a pile of boards, to have to program uP hardware on each one.
> idk what the counter-argument was exactly, that it can't be done or....? > > Clearly building switching controllers of some type are what uP > manufacturers often expect people to do with their parts or why would > they include hardware dead-time generators with a bunch of 'em
some good part numbers? ... -- Thanks, - Win
On 11/25/2018 08:36 PM, Winfield Hill wrote:
> bitrex wrote... >> On 11/25/2018 05:07 PM, John Larkin wrote: >>> On 25 Nov 2018 12:50:37 -0800, Winfield Hill wrote: >>>> John Larkin wrote... >>>>> >>>>> If the input voltage is fixed/known, or measured, and we >>>>> have a discontinuous switcher, the inductor current is >>>>> predictable. So we can dump a controlled shot of energy >>>>> onto the output cap every pulse. Knowing the output >>>>> voltage and the applied power, we know the output current. >>>> >>>> OK, and the input currents too, should work. I'm >>>> usually reluctant to dedicate a significant fraction >>>> of my processor's time to a simple job handled by a >>>> cheap sot-23-6 part. But, it's true, while the boost >>>> converter is charging the processor has to wait anyway, >>>> before doing anything else. Then when the voltage is >>>> up, LEDs on, and the processor is busy, I could use a >>>> timer channel to provide PWM, checking the voltage every >>>> now and then to be sure it hadn't deviated too much. >>> >>> My suggestion was to use a cheap uP as a switcher controller, >>> where it has nothing else to do. You could probably sneak >>> in a serial or SPI interface, which wouldn't take much >>> compute power. >>> >>> Just a thought. It wouldn't be worth writing the code unless the >>> savings were substantial and the quantities high. > > Well, it'd be a big pain, after automated assembly of a > pile of boards, to have to program uP hardware on each one. > >> idk what the counter-argument was exactly, that it can't be done or....? >> >> Clearly building switching controllers of some type are what uP >> manufacturers often expect people to do with their parts or why would >> they include hardware dead-time generators with a bunch of 'em > > some good part numbers? ... > >
I use the ATiny85 in DIP or SOIC as a "generic compute block" for all sorts of tasks nowadays, 8kB flash 512 bytes SRAM 512 bytes EEPROM, 4 channels of 10 bit ADC, three hardware PWM channels, dead-time generator, USI pins for i2c or SPI interfacing as you like, it bit-bangs regular 8N1 serial in and out just fine too if the baud rate isn't extreme (9600 seems to work reliably enough when it's running off the internal RC oscillator at 8MHz, maybe could do faster than that off a crystal.) I don't mess with assembly or C I use use the Arduino "language" which is just C++11 with some API calls like digitalRead, analogRead, etc., with this implementation: <https://github.com/SpenceKonde/ATTinyCore> There are some newer "ATTiny" parts from Microchip, I use "ATTiny" in quotes because they're really an AVR core with PIC peripherals bolted on, maybe a sensible thing to do but are a bit harder to work with this way, the libraries haven't been written yet. The top-of-the-line 8x series is just $1 in quantity tho from a reputable supplier, probably too rich for some folks blood here, but using one part family which will compile and run more or less ANSI/ISO standard C++ code lets me do most of my "algorithm development" and debugging such as it is on a desktop x86 machine in a real IDE with a plug-in like Compiler Explorer, where I can see the generated assembly for many processor architectures, AVR, MIPS, MSP430, ARM, x86, PowerPC, etc. in real time and can immediately by-inspection ballpark about how much code space and how many clocks a certain function or implementation will take. When it works OK there and passes the test cases I can basically just drag and drop it over to the real compiler for the AVR and compile it there and it works fine. I like treating uPs like generic computational blocks and not having to think too hard about their specifics when I don't have to, it cuts down on development time.
"bitrex" <user@example.net> wrote in message 
news:rrpKD.679878$MK2.218387@fx35.iad...
> an AVR with hardware multiplier can do a 4 byte single precision > "float"-type multiply in about 200 clocks, a core without a hardware > multiplier takes around twice that.
I put together a raycaster demo for AVR. Started with the stock (floating point) code I've had floating around for years. Once that worked, I was getting maybe 6-30 FPS, depending on how much was redrawn (flat colored walls; the SPI display was a huge bottleneck). Then I changed it to 8.8 fixed point (give or take, where applicable -- juuust adequate accuracy for the screen resolution, the walls weren't much jaggier), and got maybe 6-40 FPS. The calculation rate for the raycast core was a tiny, tiny fraction of overall execution time, either way. I think that corresponds to a throughput of roughly ~100kFLOPs on a 28MHz core, which is in the right ballpark. Tim -- Seven Transistor Labs, LLC Electrical Engineering Consultation and Design Website: https://www.seventransistorlabs.com/
"John Larkin" <jjlarkin@highlandtechnology.com> wrote in message 
news:l5fjvd1029vg0ij38he6pkmt3k5h8cdube@4ax.com...
>>If you're okay with exploding transistors and shitty control loops, sure, >>sample just voltage. :-) >> >>Tim > > If I know the voltage and control the gate drive, I know the currents. >
Only in DCM. In CCM, there's that pesky "...PLUS A CONSTANT!!" from Calculus. Tim -- Seven Transistor Labs, LLC Electrical Engineering Consultation and Design Website: https://www.seventransistorlabs.com/