I'm looking at designing a PIC based synchronous buck lithium ion battery charger for volume production.
I am considering the NCP5901 synchronous buck mosfet driver with the PIC providing the PWM input. The schematic looks as if it should be fairly simple.
The tricky bit is doing the current and voltage control loops in software.
Has anyone tried anything like this? If so how successful was it?
I did several similar designs using an LPC2000 series ARM controller (most recently a quad output 130W 'special purpose' supply). You'll need a micro which has an internal PWM controller. A PIC will be way too slow if you want switching frequencies over 200kHz.
-- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------
We did an ARM-based thing that has a bunch of modes, including a constant-voltage/constant-current power supply mode. We did use the on-chip 10-bit DAC to control a linear mosfet output stage.
The 2-channel ADC digitized the actual output voltage and current and interrupted the ARM at 100 KHz. The IRQ ran a PID loop with smooth crossover from constant-voltage to constant-current modes. All the math was 32-bit fixed-point, easy on the ARM.
Turns out that the 10-bit ADC on the LPC1754 is pretty bad, and we wound up doing a lookup table calibration for every channel on the board, 12 channels total. Nuisance.
I simulated the control loop, including the voltage/current crossover, in LT Spice, then translated that to uP pseudocode. There was enough noise dithering that quantization issues sort of went away. [1]
Anyway, it works fine. I may have some design notes that I could post... let me look. The C programmer didn't understand PID loops. In fact he didn't really understand fixed-point math or fractional multiplies or exponential filtering, so I had to give him step-by-step directions. He's not with us any more.
John
[1] I tried including a quantizer in the Spice sim, but the runtimes exploded to unusability.
With just 80 counts available in the PWM register, I would certainly call a PIC "way slow" even at 200kHz -- but if you could stand that 1.25% of full range worth of quantization, perhaps it wouldn't be _too_ slow.
On a battery charger, you could probably stand that level of quantization, particularly if you add in some intentional dithering ala sigma-delta. But if you add in the dithering, you'll be consuming lots of clock ticks for the ISR. Which can be done, if you program in assembly.
-- www.wescottdesign.com
Dangit!
I wrote the above based on the Microchip website, which was listing PIC18 clock rates at 16MHz. Then I go to Digikey, and it's listing speeds up to 64MHz!
Argh. I'm glad I'm not designing in a PIC today (although with a 64MHz clock -- or even 50MHz -- a 200kHz buck converter ought to be a snap).
-- www.wescottdesign.com
Nah. That's the easy part.
For a battery charger speed is not of the essence. You probably just need simple integral control. For the current vs. voltage part, you can generally get smooth switching by calculating the current error and the voltage error, then applying the minimum of the two to the integrator. This will let either one overrule the other in pulling the output down, but if both agree that the output should rise then the output will rise.
(This sounds too easy. But I've applied this technique to loops that had four different "do not exceed" values, and saw the control hand off smoothly from one to the other as the system reached target).
I'm currently working on one that uses a microprocessor controlled boost converter. Things are going smoothly so far.
-- www.wescottdesign.com
Right. I simulated that with ideal diodes in Spice, and used a simple high-select in the uP code. Works great. You just fiddle the error gain in each path, ahead of the high select, so it behaves over the range of expected loads and conditions.
We have a user-settable "slow" bit in our 4-20 mA gadget, in case he has some bizarre load to drive.
John
Yes, but not with a PIC. Bank switching is evil.
Marginally.
I wasn't smart enough to figure out how to get rid of the approx. two second hunting cycle, but the project died on the wire anyway because the 68HC11 and its 68-pin socket were too expensive.
But Good Luck! Rich
Hi,
This is a bit unrelated, but for a synchronous buck the biggest problem I've seen that limits power output at high frequency is the high side switch transition losses. Any ideas if the microprocessor could implement some form of resonant zero voltage switching for that case?
cheers, Jamie
No, as long as the high side fet is on, the current will only rise.
-- Failure does not prove something is impossible, failure simply indicates you are not using the right tools... nico@nctdevpuntnl (punt=.) --------------------------------------------------------------
AVR is the best kind of PICs.
I've built many MCU controlled power supplies up to 10KW class. An MCU controlled SMPS is nice and easy. No problems with soft startup and shutdown, sequencing, protection and regulation. In the software, you could do things very optimally and exactly in the way you like. The low resolution of the digital PWM is not a problem as it could be improved by noise shaping methods.
Vladimir Vassilevsky DSP and Mixed Signal Design Consultant
Search on "Transition mode" and "resonant mode" power supply, and maybe the UCC28060 from TI. I don't think it's exactly what you want -- but maybe.
Converters like this use the inherent timing of the circuit for part of their operation, and this doesn't play well with a regular microcontroller with fixed-period PWM generation. You either need to try to phase-lock the period to the circuit (which will always leave you a bit off), or you need to have a microcontroller that can adjust on the fly.
Microchip has some DsPIC parts that are rich in comparators and timer logic, and advertise the ability to be used as controllers in resonant- mode power supplies -- you may want to take a look at those.
-- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
When I look at the AVR from a programming point of view I have to agree. When I look at pin drive capabilities, cost, power supply flexibility, reliable supply, and a bunch of other factors -- well, of the two I've designed in PICs but not AVRs.
Yup. It's amazing what you can do with a coarse DAC and even a simple sigma-delta modulator:
-- Tim Wescott Control system and signal processing consulting www.wescottdesign.com
ARM is kind of winning. The 32-bit RISC thing gives a huge amount of compute power.
We are using LPC1754s in a fast PID loop/signal filtering app, 100K hits per second... runs a heap of code in 4 usec, with the CPU clock throttled down to 50 MHz to save power. This chip has a mux'd ADC, a DAC, flash and ram, SPI, PWM, Uarts, Ethernet, internal clock, all kinds of goodies. We are buying them in moderate quantities, programmed and laser labeled, from Arrow for $4.75 each.
John
I think the reasons that ARM is winning is the wide variations in performance and features offered by the multiple vendors. It really doesn't matter who makes the parts. Don't like one, switch.
...and here I thought you were still using 68Ks. ;-)
ARM definitely has its place under the Sun, however:
VLV
Small PICs have as miserable peripherals as small AVRs. However the small PICs are not programmable in C whereas the AVRs could be programmed in C very well. PICs are about 3 times slower then AVR. The price depends on the particular chip; ATMega48/88 or ATTiny13 are not bad at all.
The noise shaping with PWM is far less trivial then the noise shaping with PCM.
VLV
Alas, not for new designs. The future is ARM, C, and people other than me writing the code. That's OK; I find writing code to be depressing if I have to do it for more than a week at a time.
I do define architectures and algorithms and state machines, for uPs and FPGAs, and let other people drive the tools. And I like to draw the schematics and participate in the board layouts. I guess it makes sense to specialize nowadays.
The ARMs are immensely complex compared to the 68Ks, and the documentation and tech support is much worse. The only way to figure out how some things work, like the SPI blocks for example, is to fiddle with it.
John
Maybe so. Our products aren't that cost sensitive, so we prefer to use one architecture and not stock too many different chips. I think there are ARMs under a dollar.
The architecture isn't bad, it's not designed for programming in assembly, and the ARM9 interrupt structure is indeed barbaric. The single vector, then a software search to discover whodunnit, is pure PDP-8.
Classic PIC, and anything Intel, are really ancient architectures.
John
Cortex M3 is nice though don't you think?
I'm currently designing one into a product line.
[...]-- John Devereux
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.