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.
Adding more horsepower usually shortens time to market because it allow the software to stay simple and easy to maintain. Ofcourse this doesn't prevent an idiot from shooting his own foot but that is hardly an argument. I've seen many designs where people got creative using many PICs in one device where a real microcontroller would have been a much better solution.
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
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.
Come to think about it, I already have a basic-like compiler for my Dell Axim X51v. So I guess I already program an ARM.
On a sunny day (Wed, 26 Dec 2012 19:47:39 -0500) it happened "P E Schoen" wrote in :
Yes, good point, laziness, cut and paste from other projects, only serial interrupt and timer interrupt are used, so if that conflicts for timer main will update the LCD some ms later, for serial port you could theoretically miss a character, never seen that though, something for verion 0.4 perhaps. Never fix something that works though... Thanks for pointing it out!
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
I got the idea after reading a description of a chopper stepper motor driver. It said something like when the current dropped below the set-point, the transistor was switched ON, when the current went above, the transistor was switched OFF. When switched OFF, the current would flow through the rectifier as the motors magnetic field collapsed. Seemed to be pretty much a buck type regulator with the motor coil as the inductor. I thought of the op-amp oscillator we made in college around 30 years ago, as the capacitor would charge, once the voltage rose above the comparator voltage, the output would go low, discharging the capacitor, it would also lower the comparator voltage making a hysteresis. Seems such a circuit would make a regulator acceptable for battery charging even if not as good as a SMPS regulator.
If I'm thinking about this correctly, seems a DAC output of 0-5V could feed a voltage divider (or pot) set so that at 5V the divider output (or wiper) voltage is around 1.23V. This could then go to the feedback at the point the feedback resistor goes to ground. When the DAC output is 0V, the regulator would output at whatever the feedback pin was set for (maybe
13.8V), as the ADC output went from 0V up to 1.23V, the regulator output would go down from 13.8V to 1.23V.
My current application is to charge LiPo's in parallel limiting the maximum current for the cell with the highest current. This is so that multiple batteries could be charged in parallel and wouldn't have to be at the same level of discharge. Such as a current limit of 1C, first cell to reach 1C current limits the charge, but if all cells are balanced then each cell in parallel can get 1C of current. (C being battery capacity, my 200 milliamp hour cells are charged at 200 milliamps.
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.
Yup. That sounds about right. I wouldn't use a pot -- just a resistive divider that cuts your maximum DAC voltage down to 1.23V (or whatever voltage makes for your desired minimum output voltage).
The switching part of the circuit should work. I'm not sure that LiPo's charge that way -- if the "at rest" voltage is always constant then this scheme will work. If the "at rest" voltage depends on charge level (which is not what most batteries do, but LiPo chemistry is different) then you may have uncontrolled currents flowing as soon as you plug things together.
An alternative is to just charge at an overall current set to the maximum rate of charge of your least-capable cell. A good portion of the LiPo charge cycle is spent in constant-voltage mode, so you don't really take all that much away from the charge time, and you can pretty much just slap everything into a commercial charger at that point.
--
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?
Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com
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.
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.
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=.)
--------------------------------------------------------------
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.
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?
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.
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.
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.
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.
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.