>Do you wish the PIC to be the controller or to provide some
>secondary control over and above the National parts? If the
>PIC is the controller, would that be a cost advantage over the
>large array of switching converters available out there? If you are
>trying to combine the switching function with other
>functions in the application, you may consider using a PIC
>with PWM to drive the switching element (i.e. logic level mosfet) and
>A/D to periodicaly test and adjust the conversion duty. I don't have
>much experience with battery charging, so perhaps there are others
>who can suggest what parameter to regulate.
>
> Mike
Thanks for the reply mike
Just to clarify, I'm trying to get away from using specilised DC-DC
converter control chips and use the PIC that is already in my circuit. I
want the switching circuit to be similar to that used by the National Simple
Switcher Series ie. small components- 50uH, 250uF etc operating at 20-100kHz.
I need the DC-DC converter to boost my input voltage from 12 up to 15.5V
This is used to charge the battery. The plan is to use a 71 with an A/D and
periodically check on the charging voltage and current.
At present I plan to let the switcher run using the CLKout of the PIC as the
timebase. I cna externally gate this signal, depending on the output
voltage level and the current drawn from the battery. What I am unsure of
is if I will need to sample the output voltage of the switcher every
switching cycle, or if it will be sufficient to check the output voltage
every millisecond or so (as the load on the switcher will be relatively
constant). I'm pretty sure what I'm doing is feasible, it will just be a
bit of a control & stability problem. I will be using a logic level MOSFET
as the switching element - have read the existing letters concerning these. Ta.
Hamish
>
1) Use an external Current Mode Control Pulse Width Modulator like the x3842.
This way, cycle by cycle control is relegated to the PWM IC and not the PIC.
The duty cycle and consequently the output voltage can be controlled by varying
the voltage on the feedback/compensation of the PWM IC. In other words, you can
add or subtract to the normal feedback signal to vary the output voltage.
2) Be careful using 12 volts as your charging voltage. This will force you to
use
a flyback topology (== transformer) as opposed to a simpler boost circuit
(==inductor). The reason is that a "12 volt" lead-acid battery has a fully
charged
terminal voltage of 14.4V and a fully discharged terminal voltage of about
10.2V.
Since this range of voltages crosses the 12 volt boundary, you will be required
to
buck and boost the DC-DC converter.
3) Beware of Logic level MOSFETs. They can be controlled with 0/5V gate to
source
voltages. However, they have a fair amount of gate capacitance. Thus if you want
to have a quasi efficient power supply, you will need something with a little
umph
to drive them. (Soft edges in switching power supplies == power loss).
4) Don't forget your temperature sensor.
5) Don't count on the PIC for fail-safe operation. I am not knocking the PIC.
But,
there will be times when PIC is not active but the DC-DC converter is. (Like on
power up, and software crashes). Dangerous high voltages could develop in these
situations.
Scott Dattalo makes some excellent points in his response. I might
add a few comments:
>3) Beware of Logic level MOSFETs. They can be controlled with 0/5V gate
> to source voltages. However, they have a fair amount of gate
> capacitance.
Caution is required here. The capacitance is largely a function of
die size. However, the application doesn't require a large output
current, probably a couple of amps peak during the energy
storage cycle, so a mosfet smaller than a TO220, with a
less-than-ideal switching transition would probably be ok in this
application.
>there will be times when PIC is not active but the DC-DC converter is. (Like
>on power up, and software crashes).
Hamish mentioned he was using the '71 which doesn't have a PWM output.
If he has enough overhead in his code to provide a software PWM, than
it would most likely not function during software crashes or power-up.
I can imagine might be more of a concern if he used the hardware PWM
on the '74 for example.
> However, the application doesn't require a large output
> current, probably a couple of amps peak during the energy
> storage cycle, so a mosfet smaller than a TO220, with a
> less-than-ideal switching transition would probably be ok in this
> application.
Again, in my experience with switching power supplies of this type,
you want to have very hard MOSFET on/off transitions. If you don't,
you will have a less-than-efficient design. This extra power loss
winds up mostly in the MOSFET. So if you want to use a smaller
FET with less than ideal switching characteristics, you will need a
rather larger heat sink, and even then you are likely to exceed the
junction temperature. I've fried a few MOSFETs this way before.
> Hamish mentioned he was using the '71 which doesn't have a PWM output.
> If he has enough overhead in his code to provide a software PWM, than
> it would most likely not function during software crashes or power-up.
> I can imagine might be more of a concern if he used the hardware PWM
> on the '74 for example.
PWM safety:
Both flyback and boost DC-DC converter topologies have a DC path from
power to ground when the MOSFET is turned on. If the PIC fails in a mode
with the MOSFET turned on, something will get toasted (hopefully just the
fuse). My real concern is if you have an external PWM IC and wish to fiddle
with the feedback voltage. If the PIC fails in mode that tells the PWM to
put out maximum voltage, it's possible to produce dangerously high voltages.
Concerns about PWM ICs:
People have been using hardware PWM's for years with much success. There
are many many features in them that make them very reliable. I really don't
think there should be a concern about them. Think about what they do and
what you would have to do with a PIC to get the same functionality. First,
there is a voltage feedback circuit that varies the pulse width based on the
converter's output voltage. The loop response is typically on the order of
milliseconds. This could be implemented with a PIC. However, in the
current-mode PWM's, there is another feedback circuit that senses the cycle-
by-cycle switching current. If the current exceeds a certain threshold, the
FET is turned off. The response time of this loop is on the order of micro-
seconds. You would be hard pressed to reliably implement this with a PIC
(and do anything else at the same time). There are several other features
like under voltage lock-out, integrate MOSFET drivers, etc. that would also
be difficult to implement. (In fact, a MOSFET driver e.g. ICL7667 costs
almost as much as a UC3842 PWM).
Hamish wrote:
> Thanks to Scott and Mike etc. for the replies. I'm still not sure that what
> I'm trying to do is the most practical thing to do - I was more sounding
> things out to see if anyone else had done this sort of thing.
In my last battery charger design I wanted to use a microcontroller too.
However,
I wasn't convinced at the time (and neither were my peers or my boss) that it
was the best thing to do. My opinion has definitly changed. The only reason you
don't see more microprocessors in power supplies/battery chargers is that the
analog guys for the most part think PICs are something used to break rocks with.
(Given enough time I'm sure someone will write a program to do that). If you
look at the flexibility vs dollars spent, there is no doubt that a PIC is an
excellent choice for a design like yours.
I'll address your specfic battery/charging algorithm in a seperate e-mail
off-line.
>Again, in my experience with switching power supplies of this type,
>you want to have very hard MOSFET on/off transitions. If you don't,
>you will have a less-than-efficient design. This extra power loss
>winds up mostly in the MOSFET.
I'm not trying to knock your apparent knowledge in this area, but
I assumed you were implying that the PIC's port pin was inadequate
to drive a MOSFET with a large capacitance. As for size, I picked an
IRLL014 device out of the IRF Hexfet data book with the
following characteristics:
Vdss = 60V
Rdson = 0.2ohm
Id = 2.7A
Ciss = 400pF
Package = SOT223 (small indeed)
Under ambient temperatures this device will dissipate 2W
into a 1" sq. area of the PCB.
IRF has a table of turn-on and turn-off times for standard CMOS
and TTL gate drives for logic level MOSFETS in thier APP note AN971.
I picked a worst case approximation for the above device
compared to a device with similar gate and miller
capacitance. I rounded up both times to the nearest 100nS.
ton = 200nS
toff = 100nS
I assumed a boost converter topology for simplicity and convenience:
Energy of the turn-on was approximated with a linear transition from
10V to 0V with a load current on the inductor as an initial condition
which is approximated as a constant for the turn on switch time. This
should give a VERY converative estimate.
>
>Scott Dattalo wrote:
>
>
>>Again, in my experience with switching power supplies of this type,
>>you want to have very hard MOSFET on/off transitions. If you don't,
>>you will have a less-than-efficient design. This extra power loss
>>winds up mostly in the MOSFET.
>
>I'm not trying to knock your apparent knowledge in this area,
Neither am I,as by your email address, you have a better chance than many of
having some, but
The basic problem I saw with your approach was the assumption about
drive capability. A PIC is NOT going to produce the rise and fall times
you gave.
The reason you need high drive capability to drive a FET is to quickly
charge/discharge the miller capacitance when the drain is falling.
Without the ability to quickly transition out of that region your
power dissipation can get out of hand. That is one of the things that
dedicated hardware will get you.
Much can be done with the PIC output, but if you are looking for a high
switching frequency to allow better response/smaller inductor, you will
have real problems with a PIC
In the example you gave, the power dissipation is 65% higher by my
calculation but still doesn't need a heat sink.
However someone trying to the mythical max of 2W dissipation in the
transistor will find themselves in for an unplesant surprise
based on your assumptions.
>
>IRF has a table of turn-on and turn-off times for standard CMOS
>and TTL gate drives for logic level MOSFETS in thier APP note AN971.
>I picked a worst case approximation for the above device
>compared to a device with similar gate and miller
>capacitance. I rounded up both times to the nearest 100nS.
>
> ton = 200nS
> toff = 100nS
Try using the gate charge graphs in the IR datasheet, adjusted for the
voltage and current conditions you are using.
Capacitance during switching varies widely as the miller effect multiplies
the gate-drain capacitance, and that capacitance changes during the
transition. It is more accurate to use gate charge and the equations
I= C*dV/dt
Q = C*V
Using Voh/Ioh values from the 16C74 datasheet to get output resistances,
I calculated
ton = 1000ns
toff = 350ns
This changes the total power dissipation from 133mW to 220 mW.
Trying to switch extra current will quickly cause problems with
these switching times.
> Much can be done with the PIC output, but if you are looking for a
> high switching frequency to allow better response/smaller
> inductor, you will have real problems with a PIC
I probably wouldn't use a switching frequency above 20KHZ with
a PIC anyway.
>However someone trying to the mythical max of 2W dissipation in the
>transistor will find themselves in for an unplesant surprise
>based on your assumptions.
The 2W was just stated verbatim as a max Pdiss from the data sheet.
I should have mentioned the linear derating factor of 25mW per
degC that you have to subtract from this for every degree above
a 25degC ambient that the package is at during normal operation.
Thanks for calling me on this one.
>Try using the gate charge graphs in the IR datasheet, adjusted for
>the voltage and current conditions you are using.
Thanks again John for the points on my sloppy research. I assumed
the PIC was going to provide the same drive as the 74HC00 nand gate
that IR used in there app. note. They were also switching resistive
loads.
> Trying to switch extra current will quickly cause problems with
> these switching times.
Is this extra current greater than the design peak current? I guess
I'm asking if you should use, as the bottom line, a MOSFET driver for
this application.
At the risk of being flamed, I might add that the thermal resistance
of the device Mike quoted is 15 degrees C/watt for junction to case and
42 degrees C/Watt from junction to ambient. I'm not exactly sure of the
thermal resitance of the 1 inch square copper foil heat sink. However,
I'll buy a six pack for the first person that can keep their pinky on
that puppy and sing one verse of "Row-Row Your Boat" while the converter
supplies 15 watts!
Well, I'm not being exactly fair. The junction is rated for 150 degrees
Centigrade, while your finger is rated for only about 70-80 degrees. But
you get the point, it will be _very_ hot if you do not use an appropriate
driver.
At 03:15 PM 5/17/96 -0400, you wrote:
>
>Johnathan King wrote:
>d
>> Trying to switch extra current will quickly cause problems with
>> these switching times.
>
> Is this extra current greater than the design peak current? I guess
>I'm asking if you should use, as the bottom line, a MOSFET driver for
>this application.
>
At that power level, I guess if it works, it works. One other thought was
if this was for a home project( instead of production), I would definately
add a driver chip, if nothing else to protect the PIC from the day that the
MOSFET died and took its driver with it. The thought of losing my expensive
ceramic PIC instead of a $1 chip ruin my day :(
What is the relationship between using the MPASM config directive and
actually writing your software to program the PIC configuration bits?
If config takes care of the bits, do the appropriate programming
instructions just magically get embedded into your machine code?
I have an example of config from Microchip:
__config (_XMC_MODE & _EC_OSC & _WDT_OFF)
Note: These symbols are defined in p17c43.inc
The __config directive it generates the bit pattern for the configuration
you specified, and places it in the memory location it should go; for the
16c84 that would be 2007h. That means, that writing the line:
__config _xt_osc & _wdt_off
is just as writing
org 2007
dw _xt_osc & _wdt_off
except that the first one won't generate a warning in mpasm
> Hello,
>
> What is the relationship between using the MPASM config directive and
> actually writing your software to program the PIC configuration bits?
> If config takes care of the bits, do the appropriate programming
> instructions just magically get embedded into your machine code?
> I have an example of config from Microchip:
> __config (_XMC_MODE & _EC_OSC & _WDT_OFF)
> Note: These symbols are defined in p17c43.inc
>
> Magic or not?
>
> -Brian-
>
>
At 06:54 PM 12/3/96 -0500, you wrote:
> Hello,
>
> What is the relationship between using the MPASM config directive and
> actually writing your software to program the PIC configuration bits?
> If config takes care of the bits, do the appropriate programming
> instructions just magically get embedded into your machine code?
> I have an example of config from Microchip:
> __config (_XMC_MODE & _EC_OSC & _WDT_OFF)
> Note: These symbols are defined in p17c43.inc
>
> Magic or not?
>
> -Brian-
Brian,
No they don't. Using the MPASM's __config will only embed the configuration
in the .HEX file. This config is then available for an EXTERNAL programmer,
they do nothing for you if you wish to reprogram the config at RUN TIME -
IF that is possible and I'm not saying it is or isn't. (If I had to guess I
would say that it isn't. Can the TABLWT instruction access the config bits?
Somehow I doubt it.)
For those of you who are totally confused, the 17Cxx parts can be program
at run time with the use of the TABLWT instructions. This feature is
similar to the 68705's that can also be reprogram at run time. In actual
fact, both the 17Cxx and 68705 are always programmed at run time via a
bootstrap held in uneraseable ROM . That is why you must supply a clock to
each during programming.
> Can the TABLWT instruction access the config bits? Somehow I doubt
> it.
Jim:
Yes, it can, but only indirectly through seven memory locations, each
of which represents one of the configuration bits. The locations
must be written in order, and ANY write (regardless of the data
that's actually written) programs the corresponding config bit to 0.
Details, such as they are, are in the PIC17CXX Programming
Specification, in section 4.0, "Configuration Word".
At 10:29 PM 12/3/96 -0800, you wrote:
>Jim Robertson <PICLISTspam_OUTMITVMA.MIT.EDU> wrote:
>
>> Can the TABLWT instruction access the config bits? Somehow I doubt
>> it.
>
>Jim:
>
>Yes, it can, but only indirectly through seven memory locations, each
>of which represents one of the configuration bits. The locations
>must be written in order, and ANY write (regardless of the data
>that's actually written) programs the corresponding config bit to 0.
>
>Details, such as they are, are in the PIC17CXX Programming
>Specification, in section 4.0, "Configuration Word".
>
>-Andy
Of course, how silly of me. How else does the bootstrap code program them.
I Wasn't thinking clearly enough about it.
PHOENIX Shareware Picstart 16B upgrade coming.
For more details, send email to KILLspamnewfoundKILLspamne.com.au with
"subscribe phoenix mail list" in the BODY of the message.
--------------------------------------------------------
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, repnz_cmpsb wrote:
Hello to all.
it's time for me to coordinate two separate SX-28's, and I guess it's about time I learned about Parallax's resonators... This first use will be a simple one - a virtual 555 chip to send a coded 38 KHz infrared beam from one unit to the other... the units are solidly mounted, twelve feet apart on my windows (they open my blinds) and I wish to make one a master and the other a slave. The resonators will also force the two stepper motors to operate at identical speeds...
I've picked 4 MHz, as my not-so-critical timing in all my current projects is based on that, and I can read a TV-remote, and operate my motors just fine with the algorithims I've already written at 4 MHz. Faster is not better for the time being... in fact, faster creates problems.
---> So I will purchase two dozen CST4.00G0H6 resonators (with the internal capacitors) - but then my sources conflict:
++ my version 1.1 (paperback) manual says I need a 100K parallel and a 470? series resistor...
++ a pdf version on my computer says I just need a 1Meg parallel resistor.
++ my SX-tech board has room for a resonator, but I see no resistors in the circutry...
which combination is correct ?
------------
...and I will have to pop them in and out during programming and de-bugging, right ? ? ? --- are little 3-hole holders made just for them, or can I just cut down some collet-style sockets ?
thanks.
tommy
---------- End of Message ----------
You can view the post on-line at: http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=189828 Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2007 (http://www.dotNetBB.com)
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, bean wrote:
In my opinion, the 1 Meg resistor is what you want (if you want to use any at all). The resistor is just insurance that the resonator will startup.
You don't need to remove the resonator for programming, but you do for debugging.
Looking at the datasheet for the Parallax 4MHz resonator, it looks like they are +/- 0.5% and +/- 0.2% over temperature. So total stability would be +/- 0.7% ( 10 minutes per day, not good enough for a clock). For a clock go with a crystal (they are probably 50 or 100 PPM, 100PPM = 0.01% or 8.6 seconds per day).
Bean.
---------- End of Message ----------
You can view the post on-line at: http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=189828#m189858 Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2007 (http://www.dotNetBB.com)
In SX Microcontrollers, SX/B Compiler and SX-Key Tool, repnz_cmpsb wrote:
originator's reply... thank you Bean... so I gather that the parallel resistor in not too critical - I will use a 1Meg as you suggest - and that no series resistor is required. It's a shame that the manuals were all different. None of my simple communications between units is highly speed-critical, but standardizing the speed between units puts another 'tool' at my disposal should the need arise for more complexity.
I already use a DS1302 as a clock so that the blinds won't open until the sun passes by, at noon-time... and the thirty bytes of free memory that come with the clock make it valuable even if I were to not keep the time...
I shall now re-draw my 'avatar' - that picture / icon on the left under our names (what a strange word - "an embodiment, a representation, coming down to Earth...") - to include the resonator.
thanks. tommy ---------- End of Message ----------
You can view the post on-line at: http://forums.parallax.com/forums/default.aspx?f=7&p=1&m=189828#m190241 Need assistance? Send an email to the Forum Administrator at forumadmin@parallax.com The Parallax Forums are powered by dotNetBB Forums, copyright 2002-2007 (http://www.dotNetBB.com)
It's ok I think it meant timer1 in relation to CCP in capture mode.
On Nov 18, 2012 6:49 PM, "nik ." <RemoveMExyzqhtcTakeThisOuTgmail.com> wrote:
> Hi, In the article it mentions TMR1 clock input - RC2. THE 16F877
> datasheet says that RC2 is a CCP1 pin. Also RC0 is TMR1 clock input.
>
> Am I missing something or is really an error in the article. From the code
> it seems the rpm input is supposed to go to CCP1 capture input on RC2
>
> Can some please verify my doubts. Thanks.
>
> Link:
> cnx.org/content/m32948/latest
uicc.com
