AVR-Chat

On Jan 3, 2008, at 11:39 AM, Steven Hodge 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
> ----------------------------------------------------------
> Steve -
>

> What you do depends on the "mission-critical" nature of the  
> application. If this  is what it seems, then too much might not be  
> too much. Generally, the ESD-protected RS485 transceivers are pretty  
> good. I've put those through rigorous transient tests needed for  
> European CE compliance, and they are fine.  Depending on what your  
> outputs do and what they might be exposed to, opto-couplers might be  
> in order. But, those only break ground loops and provide isolation,  
> they don't provide any over-voltage protection. I am a fan of diodes  
> and self-resetting fuses for low speed applications. Raychem and  
> others make the fuses; look at DiodesInc for the diodes. In that  
> kind of app with good series self-reset fuses, 600W diodes (sma  
> series, for example)  should be good and they don't cost an arm and  
> a leg.  For what its worth,
>
>

> Jim Wagner
>

> Oregon Research Electronics
>
>

>
>

> Tangent, OR, USA
>
>


[Non-text portions of this message have been removed]