AVR-Chat

Are you referring to using the optos as input buffers or output
drivers?  Not all optos are created equally.

I use MCT9001 type optos - a simple diode input and an open collector
output.  The power consumption is a function of input and output
impedences, with the MCT9001 (or similar footprint devices) ranging in
transfer ration from 50% to 200%.  Thus, if I have a 100K input
resistor with a 12V input, I will consume 0.12 mA on the 12V side,
this will transfer over to (at least) 0.06 mA on the uC side. I can
use the uC input's pull-ups (around 100K,) thus on the uC side, the
opto uses 0.05 mA.

I don't consider this to be excessive current draw.

Unless you need high speed outputs, use a relay to isolate the output.
 Higher speed outputs can utilize the opto to drive an open collector
transistor/fet.  The opto part of the circuit in this instance will
still consume little current (enough to turn on the transistor/fet.)

John


--- In AVR-Chat@yahoogroups.com, "Steven Hodge" <stevehodge@...> wrote:
>
> Thanks for the various thoughts.  I'm pursuing various leads people have
> given me.  One lead I'm not pursuing, however, is optocouplers simply
> because of the power needed to run them (one optocoupler can easily
be the
> same or more than the uC).    
> 
>  
> 
> I have the Circuit Cellar article on order (unfortunately I subscribed a
> month too late to get it free).
> 
>  
> 
> I don't have any "standards" I'm trying to meet.  I just want things
to work
> as reliably as I can reasonably make them.
> 
>  
> 
> Steve
> 
>  
> 
> From: AVR-Chat@yahoogroups.com [mailto:AVR-Chat@yahoogroups.com] On
Behalf
> Of Philippe Habib
> Sent: Friday, January 04, 2008 9:24 AM
> To: AVR-Chat@yahoogroups.com
> Subject: Re: [AVR-Chat] Re: I/O line protection
> 
>  
> 
> You want to think in layers of protection. Diodes or surge 
> protectors, then gas discharge tubes for the really big zaps. One 
> issue I've run into is that as the isolation provided by optocouplers 
> increases, they get way slower. I've had to bit bang some SPI 
> interfaces down at the kilohertz because the optocouplers were so slow.
> 
> Do you have standard that you have to meet in terms of voltage and 
> duration? That makes it a lot easier to figure out just how much you 
> need to do.
> 
> On Jan 4, 2008, at 2:41 AM, Bruno wrote:
> 
> > Hi Steven.
> >
> > About the I/O lines, i've never heard about the littlefuse. Didn't
> > you think to use optocouplers? Like the TIL111.
> >
> > About the RS-485, you could put some passives components plus the
> > LTC1480 transceivers. On the magazine, Circuit Cellar, the october
> > issue an article cames talking about the subject of protection RS-
> > 485. If you want i could provide more information for you.
> >
> > Bruno
> >
> > --- In AVR-Chat@yahoogroups.com <mailto:AVR-Chat%40yahoogroups.com> ,
> "Steven Hodge" <stevehodge@>
> > wrote:
> >>
> >> My apologies ahead of time for the length of this post, but I
> > realize it
> >> would be hard to answer without adequately describing the operating
> >> environment.
> >>
> >>
> >>
> >> I'd like to get feedback on ideas I have to provide protection for
> > I/O lines
> >> for uC-based PCB's. These will be scattered throughout a boat, so
> > 12 V DC
> >> (up to 14.6 V when the main "house" batteries are on charge) is
> > the nominal
> >> supply voltage -- call it VB -- for all boards. There is lots of
> > this
> >> running around everywhere, not just to PCB's but to motors, pumps,
> > diesel
> >> engine, solenoid coils, radios, radar, instruments, stereo,
> > computer, etc.
> >> All grounds come back to a single common ground bus near the house
> > battery
> >> bank.
> >>
> >>
> >>
> >> Protection concerns are (1) overvoltage on an I/O pin by
> > accidentally
> >> connecting it to VB, (2) the usual ESD, (3) protection of the uC
> > and digital
> >> stuff from RF-induced voltages from the radar and VHF & HF radios
> > (and who
> >> knows what else, eg, computer), and (4) protection in the opposite
> >> direction, of the radar/radios from RF noise from digital
> > switching.
> >> Usually an inverter is also in use, to supply "household" 120 VAC
> > from the
> >> 12 V house bank, so that probably adds to the noise.
> >>
> >>
> >>
> >> All the uC-based boards will be linked with an RS485 bus, using
> > shielded
> >> CAT-5 Ethernet cable and LTC1480 transceivers at each end. These
> >> transceivers include ESD protection.
> >>
> >>
> >>
> >> The uC will be an ATmega644P running at 3.0 - 3.3 V (still
> > undecided) and
> >> 1.8432 MHz (for ideal RS485 and lower power consumption). The
> > power supply
> >> will be an LP2951. The Atmel App Note AVR042 gives a pretty good
> >> description of how to protect the uC power pins, so I'm following
> > the
> >> recommendations there (although I did have to clarify the units in
> > Fig 6-1
> >> with Atmel tech support). I'll also put the usual bypass
> > capacitor at the
> >> pins of all other IC's. At this point, I don't have any questions
> > about
> >> power protection, and this post is just directed at I/O pins.
> >>
> >>
> >>
> >> There is no high-frequency I/O requirement. Almost all digital
> > signals
> >> change state once in a blue moon on uC time scales. At most I
> > might have
> >> one at 50 Hz max, and 1 or 2 at a few Hz. All analog signals are
> > very
> >> slowly varying, time scales of tens of seconds at the fastest.
> >>
> >>
> >>
> >> PCB real-estate is a bit of an issue but not a serious one. At
> > any rate,
> >> I'd like to start with what is functionally the best and only then
> > adjust if
> >> the result makes the boards unacceptably too big.
> >>
> >>
> >>
> >> All I/O signal wires will be shielded, with the shield grounded
> > only at one
> >> end.
> >>
> >>
> >>
> >> I always attempt to have input signals active-low, floating when
> > not
> >> asserted (and pulled high at the PCB end), but there are still
> > many cases
> >> where active-high is unavoidable. Signal levels are either CMOS
> > or VB level
> >> in most cases. There are a few at 5 V level.
> >>
> >>
> >>
> >> As much as possible I'll try to use a ground plane on the uC-based
> > PCB's,
> >> but probably not a power (Vcc) plane.
> >>
> >>
> >>
> >> For digital input lines, I'm proposing:
> >>
> >>
> >>
> >> (a) front end protection using a MAX681x for mechanical switch
> > input (which
> >> the majority of input signals are) or a Littelfuse SP72x for non-
> > switch
> >> inputs. Both have ESD & overvoltage protection. The MAX681x has
> > the
> >> additional advantage of providing automatic high-to-low level
> > shifting to
> >> get VB-level signals down to CMOS levels, and thus, since the 50
> > ms time
> >> delay of this IC is not an issue in most cases, I could just use it
> >> everywhere except for those cases where it would be an issue (eg,
> > the 50 Hz
> >> signal). The trade-off is that if I used the SP72x there would be
> > a
> >> significant number of situations where I would have to add a high-
> > to-low
> >> buffer/shifter IC.
> >>
> >>
> >>
> >> (b) an additional RC low-pass filter between the above and the uC
> > pin, where
> >> the value of R is chosen so it also acts to limit the current into
> > the uC
> >> pin to its max of 40 mA. C would then be selected so the -3dB
> > breakpoint of
> >> the filter is well above 50 Hz, say 1-2 KHz. Values I've
> > computed, for
> >> CMOS-level voltages, are about 100 ohms for R and about 1 uF for C
> > for such
> >> a breakpoint.
> >>
> >>
> >>
> >> For analog input lines, level-shifting cannot be done so I'd just
> > use the
> >> SP72x and RC filter. The filter values would be adjusted to
> > accommodate
> >> their typically higher voltages (such as VB or 5 V).
> >>
> >>
> >>
> >> When it comes to output lines, things are murkier in my brain.
> > For signal
> >> and non-inductive load outputs, I'm thinking of using the same
> > SP72x's, or
> >> nothing at all. Inductive loads will definitely require a flyback
> >> suppression diode, but it's not clear to me if I should also add
> > the SP72x,
> >> or a DO-15 package TVS, to them as well. I often also install a
> > diode
> >> across the actual load (ie, actual motor or solenoid coil
> > terminals).
> >>
> >>
> >>
> >> Any comments on any of the above will be very appreciated. One
> > specific
> >> question I have is should I add anything else to the RS485 lines,
> > beyond
> >> what the LTC1480 transceivers provide?
> >>
> >>
> >>
> >> Thanks, Steve
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> [Non-text portions of this message have been removed]
> >>
> >
> >
> >
> >
> >
> > Yahoo! Groups Links
> >
> >
> >
> >
> 
>  
> 
> __________ NOD32 2765 (20080104) Information __________
> 
> This message was checked by NOD32 antivirus system.
> http://www.eset.com
> 
> 
> 
> [Non-text portions of this message have been removed]
>