sanity check, pic12f675 first project

[Jason-69]

All,

I'm crashing headlong into programming pics.  I pulled gpasm and gpsim
for ubuntu, and am about to make a purchase.  My end goal is to
prototype a LED driver (button input (toggle blinking on/off), LED
blinking at programmed rates on a breadboard (DIP), then switch to
SOIP-8 narrow for a pcb).

I've wrecklessly chosen the pic12f675 for the task. ;-)

It appears to be supported by the linux toolchains, I've found example
code in google's codesearch, and the Epic plus programmer supports it.

My only trainwreck that I can see is the support for the Epic [1]
programmer in linux.  It looks like Odyssey [2] supports the family, but
it hasn't been maintained for a few years.  Also, the new home doesn't
load...

Am I on the right path?  I'd like to get this project moving, but don't
want to waste money on the wrong programmer...

tia,

Jason.

[1] - http://www.melabs.com/products/epic.htm
[2] - http://www.desert.cx/odyssey/

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Peter Stuge-4]

Hi Jason,

Jason wrote:
> I'm crashing headlong into programming pics.

Welcome. Good fun!


> My end goal is to prototype a LED driver (button input (toggle
> blinking on/off), LED blinking at programmed rates on a breadboard
> (DIP), then switch to SOIP-8 narrow for a pcb).
>
> I've wrecklessly chosen the pic12f675 for the task. ;-)

Should be ok. You have 6 io pins, out of which 5 have internal
pull-ups which can be enabled per pin. The last one (GP3) is input
only, and does not have an internal pull-up.


> It appears to be supported by the linux toolchains,

Yep.


> Am I on the right path?  I'd like to get this project moving, but
> don't want to waste money on the wrong programmer...

You are on the right path. Google "pic12f675 gpasm" to get loads of
nice pages, including:

[PIC Microcontroller Hacking with Linux] LED blinking
http://pramode.net/pic/12f675.html

[PIC12F675 8-PIN PONG] composite output video game
http://hyvatti.iki.fi/~jaakko/pic/pong/

However, I would recommend buying a PICkit 2 programmer. It works in
Linux with the pk2cmd utility, it supports almost every (if not
every) current PIC out there (and many old ones) and it is quite
affordable at USD 34.99.

http://www.microchip.com/PicKit2/
http://www.microchipdirect.com/productsearch.aspx?Keywords=DV164120
http://www.microchipdirect.com/productsearch.aspx?Keywords=PG164120

(The last link is only the programmer itself. The DV-kit includes a
small demo board with a PIC16F690.)


//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Bill Sack-2]

i have an epic+ programmer, and i use pikdev to program chips with it.

http://pikdev.free.fr

look at the 'hardware' page on his site to read an important
configuration note about the epic, though. aside from that, i've had
no problems burning pics in the 16fxxx family..

best,
b

On Tue, Jul 21, 2009 at 11:12 AM, Peter Stuge<peter@...> wrote:

> Hi Jason,
>
> Jason wrote:
>> I'm crashing headlong into programming pics.
>
> Welcome. Good fun!
>
>
>> My end goal is to prototype a LED driver (button input (toggle
>> blinking on/off), LED blinking at programmed rates on a breadboard
>> (DIP), then switch to SOIP-8 narrow for a pcb).
>>
>> I've wrecklessly chosen the pic12f675 for the task. ;-)
>
> Should be ok. You have 6 io pins, out of which 5 have internal
> pull-ups which can be enabled per pin. The last one (GP3) is input
> only, and does not have an internal pull-up.
>
>
>> It appears to be supported by the linux toolchains,
>
> Yep.
>
>
>> Am I on the right path?  I'd like to get this project moving, but
>> don't want to waste money on the wrong programmer...
>
> You are on the right path. Google "pic12f675 gpasm" to get loads of
> nice pages, including:
>
> [PIC Microcontroller Hacking with Linux] LED blinking
> http://pramode.net/pic/12f675.html
>
> [PIC12F675 8-PIN PONG] composite output video game
> http://hyvatti.iki.fi/~jaakko/pic/pong/
>
> However, I would recommend buying a PICkit 2 programmer. It works in
> Linux with the pk2cmd utility, it supports almost every (if not
> every) current PIC out there (and many old ones) and it is quite
> affordable at USD 34.99.
>
> http://www.microchip.com/PicKit2/
> http://www.microchipdirect.com/productsearch.aspx?Keywords=DV164120
> http://www.microchipdirect.com/productsearch.aspx?Keywords=PG164120
>
> (The last link is only the programmer itself. The DV-kit includes a
> small demo board with a PIC16F690.)
>
>
> //Peter
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: gnupic-unsubscribe@...
> For additional commands, e-mail: gnupic-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Mark Rages]

On Tue, Jul 21, 2009 at 9:48 AM, Jason<gnupic@...> wrote:

> All,
>
> I'm crashing headlong into programming pics.  I pulled gpasm and gpsim
> for ubuntu, and am about to make a purchase.  My end goal is to
> prototype a LED driver (button input (toggle blinking on/off), LED
> blinking at programmed rates on a breadboard (DIP), then switch to
> SOIP-8 narrow for a pcb).
>
> I've wrecklessly chosen the pic12f675 for the task. ;-)
>
> It appears to be supported by the linux toolchains, I've found example
> code in google's codesearch, and the Epic plus programmer supports it.
>
> My only trainwreck that I can see is the support for the Epic [1]
> programmer in linux.  It looks like Odyssey [2] supports the family, but
> it hasn't been maintained for a few years.  Also, the new home doesn't
> load...
>
> Am I on the right path?  I'd like to get this project moving, but don't
> want to waste money on the wrong programmer...
>
> tia,
>
> Jason.
>

You're on the right path.  Consider a PICkit 2 programmer, open-source and USB.

Set up your circuit for ICSP as soon as possible.  No reason to be
plugging chips into ZIF sockets for programming anymore.

Regards,
Mark
markrages@gmail
--
Mark Rages, Engineer
Midwest Telecine LLC
markrages@...

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Jason-69]

Peter,

Peter Stuge wrote:
> Jason wrote:
[snip]

>> Am I on the right path?  I'd like to get this project moving, but
>> don't want to waste money on the wrong programmer...
>
> You are on the right path. Google "pic12f675 gpasm" to get loads of
> nice pages, including:
>
> [PIC Microcontroller Hacking with Linux] LED blinking
> http://pramode.net/pic/12f675.html
>
> [PIC12F675 8-PIN PONG] composite output video game
> http://hyvatti.iki.fi/~jaakko/pic/pong/
>

Nice.  I found a circuit a while back [1] for increasing the LED
brightness by pulsing it.  I thought I'd replace the 555 timer with a
more flexible pic...

> However, I would recommend buying a PICkit 2 programmer. It works in
> Linux with the pk2cmd utility, it supports almost every (if not
> every) current PIC out there (and many old ones) and it is quite
> affordable at USD 34.99.
>
> http://www.microchip.com/PicKit2/
> http://www.microchipdirect.com/productsearch.aspx?Keywords=DV164120
> http://www.microchipdirect.com/productsearch.aspx?Keywords=PG164120

Ah... bingo.  That's two votes for the PicKit2.  I'll go with that,
then.  Thanks!

Jason.

[1] - http://www.satcure-focus.com/tutor/page10.htm

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Jason-69]

Mark Rages wrote:

> On Tue, Jul 21, 2009 at 9:48 AM, Jason<gnupic@...> wrote:
>> All,
>>
>> I'm crashing headlong into programming pics.  I pulled gpasm and gpsim
>> for ubuntu, and am about to make a purchase.  My end goal is to
>> prototype a LED driver (button input (toggle blinking on/off), LED
>> blinking at programmed rates on a breadboard (DIP), then switch to
>> SOIP-8 narrow for a pcb).
>>
>> I've wrecklessly chosen the pic12f675 for the task. ;-)
>>
>> It appears to be supported by the linux toolchains, I've found example
>> code in google's codesearch, and the Epic plus programmer supports it.
>>
>> My only trainwreck that I can see is the support for the Epic [1]
>> programmer in linux.  It looks like Odyssey [2] supports the family, but
>> it hasn't been maintained for a few years.  Also, the new home doesn't
>> load...
>>
>> Am I on the right path?  I'd like to get this project moving, but don't
>> want to waste money on the wrong programmer...
>
> You're on the right path.  Consider a PICkit 2 programmer, open-source and USB.
>

Sold.  I'm picking one up shortly.

> Set up your circuit for ICSP as soon as possible.  No reason to be
> plugging chips into ZIF sockets for programming anymore.

Very true.  I'll program it that way on my breadboard, then make sure to
add traces when I move to PCB.  The crux of it seems to be connecting
the trace to the pin before any components (typically resistors).

thx,

Jason.

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Peter Stuge-4]

Jason wrote:
> Nice.  I found a circuit a while back [1] for increasing the LED
> brightness by pulsing it.  I thought I'd replace the 555 timer with
> a more flexible pic...

Aha. Watch out with the voltage though - that circuit will make those
R2-R3 resistors sweat a bit, and the Q1 transistor will also be a bit
stressed.

Better match the supply voltage to the forward voltage of your LEDs,
then there's no extra voltage that needs to be dropped by other
components.


Jason wrote:
> > Set up your circuit for ICSP as soon as possible.  No reason to
> > be plugging chips into ZIF sockets for programming anymore.
>
> Very true.  I'll program it that way on my breadboard, then make
> sure to add traces when I move to PCB.  The crux of it seems to be
> connecting the trace to the pin before any components (typically
> resistors).

Problem is that the application circuit can easily interfere with
ICSP. If I can, I make sure to leave the ICSP pins unconnected.

If I can't, I tend to program the PIC out of circuit.


//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Peter Keller]

On Tue, Jul 21, 2009 at 08:07:23PM -0400, Jason wrote:
> Mark Rages wrote:
> > You're on the right path.  Consider a PICkit 2 programmer, open-source and USB.
>
> Sold.  I'm picking one up shortly.

Yeah, I use one of these as well. I got pk2cmd, the pic kit 2, linux, and
gputils to program that very PIC chip in a hilariously short amount of time.

It took longer to figure out the incantations to pk2cmd (being a windows
program ported to unix) then anything.

Later,
-pete

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Mark Rages]

On Tue, Jul 21, 2009 at 9:04 PM, Peter Stuge<peter@...> wrote:
> Jason wrote:
>> Nice.  I found a circuit a while back [1] for increasing the LED
>> brightness by pulsing it.  I thought I'd replace the 555 timer with
>> a more flexible pic...

I don't think you'll find a significant brightness increase with modern LEDs:

http://members.misty.com/don/ledp.html

>
> Aha. Watch out with the voltage though - that circuit will make those
> R2-R3 resistors sweat a bit, and the Q1 transistor will also be a bit
> stressed.

R2 and R3 have the same low duty cycle as the LEDs.

If the LED current is really 500 mA each, that exceeds the design
rating of the BC547B by about 10X (Abs max Ic is 100 mA for that
part).  Better to use a logic-level FET for this application I think.

>
> Better match the supply voltage to the forward voltage of your LEDs,
> then there's no extra voltage that needs to be dropped by other
> components.

The resistor is doing more than dropping voltage.  It is acting as a
crude current source, to maintain the LED current as the forward
voltage shifts over temperature, age, manufacturing tolerances etc.
So no matter how carefully you select the supply voltage, you can't
remove the resistor without some other means of regulating current.

Regards,
Mark
markrages@gmail
--
Mark Rages, Engineer
Midwest Telecine LLC
markrages@...

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Jason-69]

Mark,

Mark Rages wrote:

> On Tue, Jul 21, 2009 at 9:04 PM, Peter Stuge<peter@...> wrote:
>> Jason wrote:
>>> Nice.  I found a circuit a while back [1] for increasing the LED
>>> brightness by pulsing it.  I thought I'd replace the 555 timer with
>>> a more flexible pic...
>
> I don't think you'll find a significant brightness increase with modern LEDs:
>
> http://members.misty.com/don/ledp.html
>

Good read.  Thanks for the pointer.

>> Aha. Watch out with the voltage though - that circuit will make those
>> R2-R3 resistors sweat a bit, and the Q1 transistor will also be a bit
>> stressed.
>
> R2 and R3 have the same low duty cycle as the LEDs.
>
> If the LED current is really 500 mA each, that exceeds the design
> rating of the BC547B by about 10X (Abs max Ic is 100 mA for that
> part).  Better to use a logic-level FET for this application I think.
>

Is there a "typical" FET I could try?  Regardless, your link, above,
spells out the pointlessness of the circuit in this case.

I may still use the transistor if the recommended current can't be
sourced/sinked by the 12F675...  I'll just adjust the R values to get a
steady current at the recommended amperage for the LED.

>> Better match the supply voltage to the forward voltage of your LEDs,
>> then there's no extra voltage that needs to be dropped by other
>> components.
>
> The resistor is doing more than dropping voltage.  It is acting as a
> crude current source, to maintain the LED current as the forward
> voltage shifts over temperature, age, manufacturing tolerances etc.
> So no matter how carefully you select the supply voltage, you can't
> remove the resistor without some other means of regulating current.

Ok, my EE degree is getting old, maybe I'm missing something.  If I have
a LED (say, 2V fwd voltage) and a resistor in series with a 3V battery,
the voltage drop across the resistor is going to be 1V, which would give
it a value of 50ohm for 20mA.

Assuming that's all correct, if the forward voltage falters over time,
say to 1.5V, the drop across the resistor changes also, to 1.5V.  This
would change the current to 30mA...

Also, as temperature changes, I don't think the resistor would
compensate in any way for changes in the forward voltage across the LED.

If memory serves, an LED drops voltage, but has no (or little) internal
resistance.  So when hooked directly to a battery, the current surges
until the LED blows or the battery is drained.  I think it would be more
accurate to say the resistors are "current limiting resistors", but they
don't help with temperature fluctuations, or aging (except premature
aging ;-) ).

So, if a PIC can sink 20mA on it's own, then an LED and a resistor
should be all I need.  The transistor is only needed if I'm sinking
multiple LEDs controlled by one pin.  Neat.

Now on to the programming bit. :-)


thx,

Jason.

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Jason-69]

Peter Keller wrote:
[snip]
> It took longer to figure out the incantations to pk2cmd (being a windows
> program ported to unix) then anything.

Care to share?

thx,

Jason.

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Peter Stuge-4]

Jason wrote:
> > It took longer to figure out the incantations to pk2cmd (being a
> > windows program ported to unix) then anything.
>
> Care to share?

I got a bit confused. I haven't used my PICkit 2 in a while, but I
think I was using pk2 when I tried it out.

http://home.pacbell.net/theposts/picmicro/

E.g.:

pk2 -device=12f675 -blank
pk2 -device=12f675 -erase
pk2 -device=12f675 -write cool.hex


//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Mark Rages]

On Wed, Jul 22, 2009 at 10:13 AM, Jason<gnupic@...> wrote:

> Mark,
>
> Mark Rages wrote:
>> On Tue, Jul 21, 2009 at 9:04 PM, Peter Stuge<peter@...> wrote:
>>> Jason wrote:
>>>> Nice.  I found a circuit a while back [1] for increasing the LED
>>>> brightness by pulsing it.  I thought I'd replace the 555 timer with
>>>> a more flexible pic...
>>
>> I don't think you'll find a significant brightness increase with modern LEDs:
>>
>> http://members.misty.com/don/ledp.html
>>
>
> Good read.  Thanks for the pointer.
>
>>> Aha. Watch out with the voltage though - that circuit will make those
>>> R2-R3 resistors sweat a bit, and the Q1 transistor will also be a bit
>>> stressed.
>>
>> R2 and R3 have the same low duty cycle as the LEDs.
>>
>> If the LED current is really 500 mA each, that exceeds the design
>> rating of the BC547B by about 10X (Abs max Ic is 100 mA for that
>> part).  Better to use a logic-level FET for this application I think.
>>
>
> Is there a "typical" FET I could try?  Regardless, your link, above,
> spells out the pointlessness of the circuit in this case.
>
> I may still use the transistor if the recommended current can't be
> sourced/sinked by the 12F675...  I'll just adjust the R values to get a
> steady current at the recommended amperage for the LED.

Well, that circuit expects currents of 1A, but averages of 40mA (?).
So the duty cycle will be 4%.

So the part needs to be rated at a pulsed current of 1A.   Then
dissipation can be checked separately.

So, looking on digi-key, how about a Diodes Inc DMN2004?   Looks like
0.45 ohm "on" resistance when driven from 5V.  0.45ohm * 1amp * 1amp =
0.45 watts.  0.45 watts * 4% is 18 mW average dissipation.   On a PCB,
thermal resistance is 625C/W.  So the temperature will rise to 11C
over ambient.  No problem, unless you're using it in an oven or
something.

Of course, when you're writing the software to control it, you need to
limit the current with bigger LED resistors, or your first software
bug is going to leave it turned on and let the smoke out...

>
>>> Better match the supply voltage to the forward voltage of your LEDs,
>>> then there's no extra voltage that needs to be dropped by other
>>> components.
>>
>> The resistor is doing more than dropping voltage.  It is acting as a
>> crude current source, to maintain the LED current as the forward
>> voltage shifts over temperature, age, manufacturing tolerances etc.
>> So no matter how carefully you select the supply voltage, you can't
>> remove the resistor without some other means of regulating current.
>
> Ok, my EE degree is getting old, maybe I'm missing something.  If I have
> a LED (say, 2V fwd voltage) and a resistor in series with a 3V battery,
> the voltage drop across the resistor is going to be 1V, which would give
> it a value of 50ohm for 20mA.
>
> Assuming that's all correct, if the forward voltage falters over time,
> say to 1.5V, the drop across the resistor changes also, to 1.5V.  This
> would change the current to 30mA...
>
> Also, as temperature changes, I don't think the resistor would
> compensate in any way for changes in the forward voltage across the LED.
>
> If memory serves, an LED drops voltage, but has no (or little) internal
> resistance.  So when hooked directly to a battery, the current surges
> until the LED blows or the battery is drained.  I think it would be more
> accurate to say the resistors are "current limiting resistors", but they
> don't help with temperature fluctuations, or aging (except premature
> aging ;-) ).
>

OK, consider an LED (2V forward voltage) in series with a 30V battery.
 The voltage drop across a resistor is 28V, which would give the
resistor a value of 1400 ohms.  So if the LED's forward voltage
changes because of temperature or age to 1.5V, the new current is
28.5/1400 or 20.3 mA.

Remember, a good current source has a high impedance.  So a 50 ohm
resistor makes a pretty crude current source, but the principle is the
same.  (You can have both low dissipation and accurate current setting
with an active current source.)

> So, if a PIC can sink 20mA on it's own, then an LED and a resistor
> should be all I need.  The transistor is only needed if I'm sinking
> multiple LEDs controlled by one pin.  Neat.

Yes, the PIC can supply plenty for an LED.   But read my post here:
http://tinyurl.com/lgzb4j

>
> Now on to the programming bit. :-)
>
>
> thx,
>
> Jason.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: gnupic-unsubscribe@...
> For additional commands, e-mail: gnupic-help@...
>
>

--
Mark Rages, Engineer
Midwest Telecine LLC
markrages@...

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Peter Stuge-4]

Mark Rages wrote:
> I don't think you'll find a significant brightness increase with
> modern LEDs:
>
> http://members.misty.com/don/ledp.html

This page says "UPDATED .. 2001" and there has certainly been a lot
of development in LED products over the last decade.

I think it is safe to say that high current PWM is the easiest way
to get the most performance out of any LED.

The improved efficiency (as mentioned back in 01) can of course also
be a deciding factor, not only brightness.

But in particular the high-power white LEDs really must be driven
with PWM.


> > Better match the supply voltage to the forward voltage of your LEDs,
> > then there's no extra voltage that needs to be dropped by other
> > components.
>
> The resistor is doing more than dropping voltage.  It is acting as a
> crude current source, to maintain the LED current as the forward
> voltage shifts over temperature, age, manufacturing tolerances etc.
> So no matter how carefully you select the supply voltage, you can't
> remove the resistor without some other means of regulating current.

Yes, sure, a resistor should still be there to limit current. I find
dropping some 10V over it to be excessive, however.


//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Peter Stuge-4]

Jason wrote:
> > Better to use a logic-level FET for this application I think.
>
> Is there a "typical" FET I could try?

Here in Europe 2N7000 is easy to get. 200mA max, 500mA pulsed, but
there are some surface mount siblins which can go higher.

Or BSS295 which does 1.4A continuous.

They're all TO-92 so easy to work with for quick hacks.


//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Mark Rages]

On Wed, Jul 22, 2009 at 12:59 PM, Peter Stuge<peter@...> wrote:

> Mark Rages wrote:
>> I don't think you'll find a significant brightness increase with
>> modern LEDs:
>>
>> http://members.misty.com/don/ledp.html
>
> This page says "UPDATED .. 2001" and there has certainly been a lot
> of development in LED products over the last decade.
>
> I think it is safe to say that high current PWM is the easiest way
> to get the most performance out of any LED.
>
> The improved efficiency (as mentioned back in 01) can of course also
> be a deciding factor, not only brightness.
>
> But in particular the high-power white LEDs really must be driven
> with PWM.
>

Please cite a reference for your assertion that PWM delivers higher
performance than a current source for a modern LED.

Of course PWM has better power efficiency.  It's the performance and
the "must be" of your statement that interests me.

Regards,
Mark
markrages@gmail
--
Mark Rages, Engineer
Midwest Telecine LLC
markrages@...

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Peter Stuge-4]

Mark Rages wrote:
> > But in particular the high-power white LEDs really must be driven
> > with PWM.
>
> Please cite a reference for your assertion that PWM delivers higher
> performance than a current source for a modern LED.
>
> Of course PWM has better power efficiency.  It's the performance
> and the "must be" of your statement that interests me.

Thanks for pushing me to look up the data sheets I was thinking of! :)
You're right.


I'm looking at two products, a 5cd@20mA yellow 5mm LED and a
480lm@700mA white 18W "LED light source type system".

Attached images show relative luminous intensity vs. forward current
for both, they're also at http://stuge.se/lumcur_5cd_yel.png and
http://stuge.se/lumcur_18W_whi.png in case the list filters them.

I could be misunderstanding the human vision but looking at the
diagram for the yellow LED it seems that the best way to drive it
would be 40-50mA (where the curve starts to fall off) which needs PWM
as it's rated at max 20mA constant current. Is your point that the
eye smoothes that out anyway, so it is perceived the same as half
intensity at double duty cycle?

The data sheet for that product also covers white LEDs, for which it
explicitly states "Recommend to drive with constant current." - so I
remembered all wrong.

The white LED module data sheet is a bit brief and just mentions max
1000mA pulse current, characteristics at 700mA and a few diagrams.

I suppose the maximum allowed duty cycle at 1000mA will not be such
that it can perform much better with PWM, so constant current would
be best also for that guy.


Thanks again!

//Peter



---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Jason-69]

Mark,

Mark Rages wrote:
> On Wed, Jul 22, 2009 at 10:13 AM, Jason<gnupic@...> wrote:
[snip]

>> I may still use the transistor if the recommended current can't be
>> sourced/sinked by the 12F675...  I'll just adjust the R values to get a
>> steady current at the recommended amperage for the LED.
>
> Well, that circuit expects currents of 1A, but averages of 40mA (?).
> So the duty cycle will be 4%.
>
> So the part needs to be rated at a pulsed current of 1A.   Then
> dissipation can be checked separately.
>
> So, looking on digi-key, how about a Diodes Inc DMN2004?   Looks like
> 0.45 ohm "on" resistance when driven from 5V.  0.45ohm * 1amp * 1amp =
> 0.45 watts.  0.45 watts * 4% is 18 mW average dissipation.   On a PCB,
> thermal resistance is 625C/W.  So the temperature will rise to 11C
> over ambient.  No problem, unless you're using it in an oven or
> something.
>

And there's a practical gem you won't find in a textbook.  :-)  Thanks
for suggestion.

> Of course, when you're writing the software to control it, you need to
> limit the current with bigger LED resistors, or your first software
> bug is going to leave it turned on and let the smoke out...
>

I've been told it's really hard to put that back in...

>>>> Better match the supply voltage to the forward voltage of your LEDs,
>>>> then there's no extra voltage that needs to be dropped by other
>>>> components.
>>> The resistor is doing more than dropping voltage.  It is acting as a
>>> crude current source, to maintain the LED current as the forward
>>> voltage shifts over temperature, age, manufacturing tolerances etc.
>>> So no matter how carefully you select the supply voltage, you can't
>>> remove the resistor without some other means of regulating current.
>>
>> Ok, my EE degree is getting old, maybe I'm missing something.  If I have
>> a LED (say, 2V fwd voltage) and a resistor in series with a 3V battery,
>> the voltage drop across the resistor is going to be 1V, which would give
>> it a value of 50ohm for 20mA.
>>
>> Assuming that's all correct, if the forward voltage falters over time,
>> say to 1.5V, the drop across the resistor changes also, to 1.5V.  This
>> would change the current to 30mA...
>>
>> Also, as temperature changes, I don't think the resistor would
>> compensate in any way for changes in the forward voltage across the LED.
>>
>> If memory serves, an LED drops voltage, but has no (or little) internal
>> resistance.  So when hooked directly to a battery, the current surges
>> until the LED blows or the battery is drained.  I think it would be more
>> accurate to say the resistors are "current limiting resistors", but they
>> don't help with temperature fluctuations, or aging (except premature
>> aging ;-) ).
>>
>
> OK, consider an LED (2V forward voltage) in series with a 30V battery.
>  The voltage drop across a resistor is 28V, which would give the
> resistor a value of 1400 ohms.  So if the LED's forward voltage
> changes because of temperature or age to 1.5V, the new current is
> 28.5/1400 or 20.3 mA.
>

Ahh... good point, unfortunately in my case, the end project is going to
run off of a 3V coin battery.

> Remember, a good current source has a high impedance.  So a 50 ohm
> resistor makes a pretty crude current source, but the principle is the
> same.  (You can have both low dissipation and accurate current setting
> with an active current source.)
>
>> So, if a PIC can sink 20mA on it's own, then an LED and a resistor
>> should be all I need.  The transistor is only needed if I'm sinking
>> multiple LEDs controlled by one pin.  Neat.
>
> Yes, the PIC can supply plenty for an LED.   But read my post here:
> http://tinyurl.com/lgzb4j
>

Interesting.  For the first cut, I'll probably just tie the LED/resistor
to a pin, but after that, I'll look at the mosfet you mentioned above.

thx,

Jason.

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Jason-69]

Peter Stuge wrote:
> Jason wrote:
>>> Better to use a logic-level FET for this application I think.
>> Is there a "typical" FET I could try?
>
> Here in Europe 2N7000 is easy to get. 200mA max, 500mA pulsed, but
> there are some surface mount siblins which can go higher.
>
> Or BSS295 which does 1.4A continuous.
>

A quick search didn't find this on digikey or mouser, however the 2N7000
is available from digikey (Fairchild and ON).

> They're all TO-92 so easy to work with for quick hacks.
>

That's pretty much the stage I'm trying to get to right now...

thx,

Jason.

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Peter Keller]

On Wed, Jul 22, 2009 at 11:14:37AM -0400, Jason wrote:
> Peter Keller wrote:
> [snip]
> > It took longer to figure out the incantations to pk2cmd (being a windows
> > program ported to unix) then anything.
>
> Care to share?

In looking at the command again, the emphasis shouldn't have been that it is a
windows program ported to unix, but instead that it just has a lot of command
line parameters whose interactions are sometime not obvious.

A burn line for me looks like:

pk2cmd -PPIC18F4550 -F./test.hex -M -JN

The one windows thing which stuck in my mind were arguments like -?E and
whatnot. ? means match any character in most shells so you get stuff like
this:

Linux black > pk2cmd -?E
pk2cmd: No match.

Obviously, the solution is to \ escape the ?. But that was an example...

All in all it really is a good tool.

-pete



---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...