Per the data sheet, the absolute maximum amount of current an i/o port pin should ever sink or source (to prevent damage, not for normal operation) is 40mA. That said, I'm reading this as one needs to short-circuit protect all i/o port pins.

I'm now seeing this as (assuming 5v drive),

5v --- R --- short-to-GND

(only considering 5v-linked pins)

Therefore,

35mA < 5/R (incl. safety margin)

R > 5v/35mA

R > 143 ohms

in series with every pin.

Also, we're looking at

P = 5^2/143 = 25/143 = 174mW, so they'll have to be 1/4W resistors also, lest they become fuses.

The assumption is reasonable if you expect to short all pins! If you were making a commercial product you would usually ensure that such short circuits should not occur in normal use or protect the pins that might be subject to such abuse. Normally short circuits are the least of your worries - ESD and EMI are usually the issues to cause the most grief.

In most cases, the port pins will sustain a short circuit for a short time without damage, so I wouldn't be too paranoid about putting series resistors on each pin.

40mA is quite alot of current. Most devices that you'll drive will require much less, typically in the range of nA or uA. The internal pull-up resistors are usually around 50kOhm which much more in the neighbourhood that you'll need. If you want to use external pull-ups or pull-downs then stay around the 50kOhm range. If you really need to drive something harder then maybe go down to 1kOhm but that's probably the limit and only do that on pins that absolutely require it.

a tansorb (tranzorb) is a protection device that shunts excess current and protects against overvoltage conditions. I wasn't aware that they themselves needed some sort of protection. That being said, it can't hurt to have a series resistor as well. What's your take?

What happens to the excess current? It goes up in heat. If the fault exists long enough, the transzorb goes up in smoke or if there's enough current the pcb track fuses. So, if there is the potential for a fault to cause this, you need to add something like a polyfuse or a fuse to protect the transzorb and/or the circuit board. I've found this out through experience!

Due to my application, I'll rarely know exactly what is connected to an i/o pin on the AVR. So I'm looking for trying to protect the AVR to some extent.

Another thing I'm considering and about which I'd appreciate input from you all is monitoring the AVR's current draw. My thought is this. As all the i/o pins are supplied current via the AVR's supply pins, it'd be reasonable to conclude that monitoring the AVR's current draw during i/o would be another means for providing protection for the AVR to some extent. Yes?

An AVR heart is of less value when its i/o pins keep going bad and you're having to replace it continuously. I say it's better to install protection in the AVR design, spend a little more money up front, to save a lot of money later. Quite frankly, I'd want a moat (sp?) around the AVR. ;-)

Sure, there are alot of different things you could do to protect your uC. It's hard to know what type of protection you need without knowing your application.

Ed II wrote:

Due to my application, I'll rarely know exactly what is connected to an i/o pin on the AVR. So I'm looking for trying to protect the AVR to some extent.

Do you know then that putting a resistor on the pin won't affect what could possibly be connected to it then? It's a bit unusual making a board and not knowing what might be connected, sounds almost like a dev board.

An IO pin has some kind of internal resistance, so approximating that it is directly connected to 5V is a bit overrated.

But do you know that even a 100 ohm resistor can prevent you from doing things fast enough, like driving a fast SPI bus or PWM signal somewhere or detecting fast pulses because of capacitance. I would not drive a PWM signal to a FET via a 100 ohm resistor, more like a 10 ohm resistor.

And a 100 ohm resistor by itself would not protect you from ESD most likely. Usually only the pins that are connected to the big bad outside world like a connector are shielded or buffered to prevent damage to microcontroller, not all of them.

So basically you could use a buffer chip to isolate the real AVR pins, but there might not be a suitable buffer chip in which you can configure pins individually.

The port pins will limit the amount of current drawn due to their design - but the chip will start to warm up. Do it on too many pins and the chip will get real hot. So you could measure the AVR current - but that only protects port pins that source current. What about the port pins sinking current? Have a look at commercial products that are similar to what you're describing. What measures do they take? I think you'll find there is no simple solution to the problem - you then put it back onto the user to not exceed certain parameters. In reality, I think you'll find overcurrent is the least of the problems - overvoltage will kill the part almost immediately so putting some ESD/voltage protection is more likely to give the most protection for the least effort. If you wanted to create a 'moat' around the AVR, then most likely you'd be losing the flexibility of the ports.

Now that I have a little more time to say things, my application is to use the AVR for a board tester design. My profession is designing, building, and maintaining testing equipment in manufacturing engineering (a ME EE, but not like Quincy,) to support the manufacturing of unique electronic equipment. That said, it has come to me that the AVR could be the heart of custom board testers and, later, system testers quite possibly. This board tester design is a Guinea pig of sorts, just to prove the concept. The bean counters liked the initial AVR production cost, while manufacturing likes the versatility. I really think I can make this fly, but it must fly right, as my company is very paradigmatically (word/sp?)-oriented around the tried and true, but cumbersome!, 68HC11-series for equipment and all-in-one (aka putting all your eggs in one basket) $100k + service contract fees testing apparati (plural of apparatus?), and I'm the only AVR pilot. Likewise, they're also looking at redundancy of that $100k to boot! I say a few hundred bucks for a 90% (I'm actually going for 99%, but don't tell them that)-working Guinea pig AVR board tester, just to show what the AVR can do, is a wise investment. To stir the pot just a bit more, the current paradigm is also that all firmware requires the software engineering department for development, that developing custom firmware is just too complex a task. (Well of course it is, now, in this day of you can't do anything without the right library or .dll, and software really does just crash mysteriously, like gremlins really do exist after all, such that only gurus can possibly deal with anything that requires custom software.) Yes, that's a long paragraph, but now maybe you get the gist of what's happening here, what I'm dealing with, why I'm so thankful the AVRFreaks exist.

Now, returning to your comments thus far, you can see why I'm saying what I'm saying about not knowing what the AVR is looking at, hopefully. Yes, the schematic says it's looking at an input to a inverting op amp circuit, but in reality it's actually looking at a solder bridge to GND or Vcc or, worse, B+. That supply line's potential current should be limited by a 10k pullup, but with just-in-time "lean" manufacturing (aka the smiley-faced Chinese made it in a sweat shop) as it is (I can't believe we Americans have elected such leadership and still believe we have a snowball's chance in...anyway), that SM 10k pullup is actually a bridge, for it didn't quite make it on the pads and happens to be electrically connected to a neighboring pad. Or there's the beauty one. We don't need no stinking leads, so there's an artwork error under a PLCC mux that happens to make A3 and D6 one and the same, so the microcontroller heart is stuck in some infinite loop, setting a watchdog fail which continuously pumps out the same reset pattern saying (in layman's terms) 'I'm sittin' in la la waitin' for my ya ya uh huh, uh huh.' (You gotta have a sense of humor or you'll go nuts in this profession. Then again going nuts is an integral (not derivative!) part of an engineer's life. ;-)

So, heading back to the ranch now, I'm looking at how to protect the AVR. Yes, 100 ohms will effect waveshape, rise and fall times. True, current does flow both ways: either into the AVR (source from supply) or out (sink to return). But am I on the right track at least?

Just because I have 100 ohms to drive or pull from, it does not mean I can't have a fast enough rise or fall. Rather, I just have to plan accordingly. Also, just because the usual current sense is at the high side (source), it doesn't mean another can't be at the low (sink) and then both be simultaneously monitored to produce a known-good line to the AVR's firmware to hi-z an unusually high-current i/o pin, in a few usecs.

When I say build a moat, that's the ideal scenario. I do realize the reality that somewhere along the best-planned line some guy is going to disobey his commander's orders, leave camp on the blackest night, fend off the aquatic creatures, cross and gain access to the castle, but if it's only on the rare occasion, we still got our money's worth.

(Then again, maybe it's not so good when I have time to completely explain where I'm coming from with my questions.)

Speaking of over-voltage protection, isn't that what the clamp diodes are about (on every i/o pin, right?). Or are you saying don't trust them to catch over-voltages most of the time? Remember I'm not looking to nail that nocturnal guy, just the ones between dawn and dusk. I'd think 150 ohms and a built in clamp diode would go a long way. Yes or no?

I did a lot of assembly language programming on my old Apple IIe many years ago, and the AVR's instruction set is quite workable, so I don't see much problem in the firmware aspect of this design. Rather, where I see the issues is in the interface to the unknown. For example, I don't intend to even attach the AVR (hi-z i/o's with reset, right?) until I know the power supplies of the UUT aren't flawed. Remember, the goal here is to, with 90% probability, determine friend from foe, first, and then, later, identify the foes' flaws. In other words, if the UUT is supposed to have +5, +15, and -15 sources but the -15 line is drawing way too much current right out of the gate, and I can detect it, then mission accomplished, as we don't even run the custom testing yet. Let a tech troubleshoot the known power supply fault, first, and then re-run the UUT under safer conditions. (An unusually high supply current draw isn't generally a safe state for functional testing.)