Is it safe to parallel PIC chip outputs

[[email protected]]

For more output current drive, can I parallel the outputs of a PIC
chip port? Assume the pins are all on the same port (e.g., RC0-RC7)
and that my firmware will never accidentally drive individual pins to
unequal values.

 

[Chris]

For more output current drive, can I parallel the outputs of a PIC
chip port? Assume the pins are all on the same port (e.g., RC0-RC7)
and that my firmware will never accidentally drive individual pins to
unequal values.

Yes. It's a good idea. Remember not to exceed port and total IC
output current limits (in the data sheets).

Cheers
Chris

 

[[email protected]]

Yes. It's a good idea. Remember not to exceed port and total IC
output current limits (in the data sheets).

Cheers
Chris

Thanks, Chris. It seemed like it should work, but a second opinion is
reassuring.

 

[Jamie]

Thanks, Chris. It seemed like it should work, but a second opinion is
reassuring.

I think you would be better off using a unity gain amp or depending on
what you need for example, a sink output ? just pass the output via a
resistor to the base of a npn common emitter style config. Use the
collector as your sink driver.. Of course, you'll need to invert the
logic of your output in the code.

 

[[email protected]]

I think you would be better off using a unity gain amp or depending on
what you need for example, a sink output ? just pass the output via a
resistor to the base of a npn common emitter style config. Use the
collector as your sink driver.. Of course, you'll need to invert the
logic of your output in the code.

I need a source output. Basically I want to power an op amp and some
sensors, so I can shut them down when the PIC is in sleep mode. Is
there a drawback to running the output pins in parallel, that
justifies the additional components for an external transistor?

 

[Randy Day]

[email protected] wrote:

[snip]

I need a source output. Basically I want to power an op amp and some
sensors, so I can shut them down when the PIC is in sleep mode. Is
there a drawback to running the output pins in parallel, that
justifies the additional components for an external transistor?

Unless you're limiting yourself to SETF
and CLRF statements, if you happen to
leave one output 0 when all others are 1.
say goodbye to your micro.

How many chips are you prepared to lose
during the debugging process?

"Oops, that was supposed to be MOVF PORTB, W
not MOVWF PORTB", as a wisp of smoke rises
from your circuit...

 

[Chris]

[email protected] wrote:

[snip]

I need a source output. Basically I want to power an op amp and some
sensors, so I can shut them down when the PIC is in sleep mode. Is
there a drawback to running the output pins in parallel, that
justifies the additional components for an external transistor?

Unless you're limiting yourself to SETF
and CLRF statements, if you happen to
leave one output 0 when all others are 1.
say goodbye to your micro.

How many chips are you prepared to lose
during the debugging process?

"Oops, that was supposed to be MOVF PORTB, W
not MOVWF PORTB", as a wisp of smoke rises
from your circuit...

Hi, Randy. Assuming the OP is paralleling outputs to drive a
resistive load, he could use current limiting resistors at each output
to help during the debugging process, like this (view in fixed font or
M$ Notepad):

|
| .------. .-------.
| | | | | ___
| | o--. | o-|___|---.
| | | | | | | 270 | |
| | | | ___ |/ | | ___ | |/
| | o--o-|___|--| = | o-|___|---o-|
| | PIC | | 100 |> | PIC | 270 | |>
| | | | | | | ___ | |
| | o--' === | o-|___|---' ===
| | | GND | | 270 GND
| | | | |
| '------' '-------'
|
|
(created by AACircuit v1.28.6 beta 04/19/05 www.tech-chat.de)

You have a very good point -- the OP should do everything he can to
protect his development system from himself. ;-)

Cheers
Chris

 

[Randy Day]

Chris wrote:

[snip]

Hi, Randy. Assuming the OP is paralleling outputs to drive a
resistive load, he could use current limiting resistors at each output
to help during the debugging process, like this (view in fixed font or
M$ Notepad):

|
| .------. .-------.
| | | | | ___
| | o--. | o-|___|---.
| | | | | | | 270 | |
| | | | ___ |/ | | ___ | |/
| | o--o-|___|--| = | o-|___|---o-|
| | PIC | | 100 |> | PIC | 270 | |>
| | | | | | | ___ | |
| | o--' === | o-|___|---' ===
| | | GND | | 270 GND
| | | | |
| '------' '-------'
|
|
(created by AACircuit v1.28.6 beta 04/19/05 www.tech-chat.de)

You have a very good point -- the OP should do everything he can to
protect his development system from himself. ;-)

Very true; for a one-off hobby project, that might
work. With a bit of experimentation, he'd even be
introducing himself to digital/analog conversion.

But for the cost of the extra resistors, he could
upgrade to a Darlington transistor, and only need
one output pin.

 

[[email protected]]

Chris wrote:

[snip]

Hi, Randy. Assuming the OP is paralleling outputs to drive a
resistive load, he could use current limiting resistors at each output
to help during the debugging process, like this (view in fixed font or
M$ Notepad):

|
| .------. .-------.
| | | | | ___
| | o--. | o-|___|---.
| | | | | | | 270 | |
| | | | ___ |/ | | ___ | |/
| | o--o-|___|--| = | o-|___|---o-|
| | PIC | | 100 |> | PIC | 270 | |>
| | | | | | | ___ | |
| | o--' === | o-|___|---' ===
| | | GND | | 270 GND
| | | | |
| '------' '-------'
|
|
(created by AACircuit v1.28.6 beta 04/19/05www.tech-chat.de)

You have a very good point -- the OP should do everything he can to
protect his development system from himself. ;-)

Very true; for a one-off hobby project, that might
work. With a bit of experimentation, he'd even be
introducing himself to digital/analog conversion.

But for the cost of the extra resistors, he could
upgrade to a Darlington transistor, and only need
one output pin.

Thanks for the helpful tips! I think that for this application, I
should do my initial debugging with the series resistors. My program
will be using the SETF and CLRF statements, but still, protecting
myself from my stupid mistakes sounds prudent.

 

[Randy Day]

[email protected] wrote:

[

Thanks for the helpful tips! I think that for this application, I
should do my initial debugging with the series resistors. My program

Your INITIAL debugging? Once you add the resistors,
you're pretty much stuck with 'em. Think about it;
how can you be sure that, in some dark corner of
your otherwise working code, some instruction was
only prevented from zapping the micro *because*
the resistors were there.

Once you take them out...

Build with, or build without, there is no ...
okay, enough with the Yoda impersonation.

will be using the SETF and CLRF statements, but still, protecting
myself from my stupid mistakes sounds prudent.

One other point to consider; do you think you
might expand the project at a later time? Add
some new functionality? Maybe you need more
i/o pins that, (drat!) are used up now.

I still don't think joining outputs is an
optimal solution. Just my opinion.

 

[[email protected]]

[email protected] wrote:

[

Thanks for the helpful tips! I think that for this application, I
should do my initial debugging with the series resistors. My program

Your INITIAL debugging? Once you add the resistors,
you're pretty much stuck with 'em. Think about it;
how can you be sure that, in some dark corner of
your otherwise working code, some instruction was
only prevented from zapping the micro *because*
the resistors were there.

Once you take them out...

Build with, or build without, there is no ...
okay, enough with the Yoda impersonation.

will be using the SETF and CLRF statements, but still, protecting
myself from my stupid mistakes sounds prudent.

One other point to consider; do you think you
might expand the project at a later time? Add
some new functionality? Maybe you need more
i/o pins that, (drat!) are used up now.

I still don't think joining outputs is an
optimal solution. Just my opinion.

Points well taken.