AVR-Chat

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, "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
>
>
>
>