I intend to have a microcontroller in my LM3886 audio amp used for general housekeeping and a digital pot volume control. To program this PIC microcontroller, there are five pins needed: 5V power, ground, 13V programming voltage, data, and clock.
Many designs that use a microcontroller have the uC programming port inside the enclosure on the PC circuit board. I want to have mine connected to the enclosure, accessible from the back. The idea is that when I want to reprogram the microcontroller, I won't have to take the case apart - I can simply plug my PIC programmer into the programming port on the back.
Being that the port will now be "exposed" to the outside world, should I put in any extra protection circuitry at the programming port to protect the microcontroller from things like static electricity?
Many designs that use a microcontroller have the uC programming port inside the enclosure on the PC circuit board. I want to have mine connected to the enclosure, accessible from the back. The idea is that when I want to reprogram the microcontroller, I won't have to take the case apart - I can simply plug my PIC programmer into the programming port on the back.
Being that the port will now be "exposed" to the outside world, should I put in any extra protection circuitry at the programming port to protect the microcontroller from things like static electricity?
pic has protection against electrostatic discharge, but if you put an RJ11 on the back, there is very little chance to touch it anyway. The only thing I would be careful, do not use RB6, RB7 (which you have the cable on, to the back) for other control like SPI, or, even better send the pic to sleep when not needed and use RB0 interrupt for IR receiver and upper RB change interrupt for buttons, rotaries.
When I still debugged my firmware I have used a piece of flat cable to get out of the box with an RJ11 at the end, where I have connected the ICD2.
Regards,
JG
When I still debugged my firmware I have used a piece of flat cable to get out of the box with an RJ11 at the end, where I have connected the ICD2.
Regards,
JG
Maybe you could put a couple of diodes off to the voltage rails,to protect the inputs a bit.. That way they could only swing within about 0.7V of the rails. (be sure to tie the diodes on the Vpp/13V pin to the 13V supply/gnd,instead of to the +5V supply!)
Might be kinda overkill,but I suppose it can't hurt.
Might be kinda overkill,but I suppose it can't hurt.
You should protect the microprocessor port pins unless you are trying to make a high volume low cost consumer electronics product where your job is on the line over a fraction of a cent in manufacturing costs. As this is a DIY project, you can afford to do it properly.
For ALL ports going to the outside world, put a 1k ohm 0.5W resistor in series (between the micro port and pin on yr external connector. Then place one diode (1N4148 will do nicely) from each micro port pin to supply rail (cathode to rail) and another from port to ground (cathode to port pin).
This is a classic protection scheme for such ports that clamps the port pins to within a diode drop of the rail or ground, limits the current and does not rely on the fragile body protection diodes.
It will cost you little and will mean that you are now very unlikely to have to rebuild after an ESD 'event'.
If the programming speed is low then you can afford to increase the value of the resistor for even better protection.
For ALL ports going to the outside world, put a 1k ohm 0.5W resistor in series (between the micro port and pin on yr external connector. Then place one diode (1N4148 will do nicely) from each micro port pin to supply rail (cathode to rail) and another from port to ground (cathode to port pin).
This is a classic protection scheme for such ports that clamps the port pins to within a diode drop of the rail or ground, limits the current and does not rely on the fragile body protection diodes.
It will cost you little and will mean that you are now very unlikely to have to rebuild after an ESD 'event'.
If the programming speed is low then you can afford to increase the value of the resistor for even better protection.
You do what you want, but put another diode parallel to the internal one (look at for example 16f870 datasheet page 33 figures) makes it just a very very little more safe. Like if you put 2+2 diodes each pin. It just makes it more complicated. In the other hand, I appreciate what VivaVee says, but I would not put series resistors at RB6, RB7 to the programming interface if I do not want programming/debug problems.
There are ports you should be careful. I rarely use RA4, and the oscillator in is not protected as far as I know. Put the suggested serial resistor at MCLR, it is important. The others not.
I did killed several 52 style MCU with unknown reason, I also killed PICes but never with ESD.
This is my current preamp control circuit, JP2 goes to the relay board slecting input, muting etc., the stepper driver turns a black alsps (what I want to change now). The transistors are needed unfortunately, because in this I use older signal relays, sinking more than what the port capable for without the LED. It works since 2002.
Regards,
JG
There are ports you should be careful. I rarely use RA4, and the oscillator in is not protected as far as I know. Put the suggested serial resistor at MCLR, it is important. The others not.
I did killed several 52 style MCU with unknown reason, I also killed PICes but never with ESD.
This is my current preamp control circuit, JP2 goes to the relay board slecting input, muting etc., the stepper driver turns a black alsps (what I want to change now). The transistors are needed unfortunately, because in this I use older signal relays, sinking more than what the port capable for without the LED. It works since 2002.
Regards,
JG
As mentioned, do as you please. I merely offer my advice from the point of view of a few 100,000 units in the field and good knowledge of what kills microprocessors and how to protect them. I prefer to spend my time designing things rather than fixing them so I consider the scheme I mentioned as cheap insurance.
I checked the data sheet for the PIC mentioned. The I/O ports are specified at a load capacitance of 50pF and the device runs at 20MHz maximum. I would not be surprised if the suggested 1k resistors worked fine on the two In Circuit Debug pins (RB6/7) following the same kind of logic used to dismiss my suggestion! But seriously, the main point is that a series resistor is really really worthwhile. The value is only point that we should be debating.
In the case of the in-circuit debug it would depend on how fast the debug system ran. IF the debug program/hardware ran at the system maximum of 20MHz (very unlikely in my experience with other processors) AND the port had the maximum allowable load capacitance of 50pF then a series 1k resistor would have a time constant of 50 ns which is the same as the clock period. The schmidt trigger TTL inputs probably wouldn't cope with this. But this assumes worst case clock speed and load capacitance. If either of these were more reasonable then it would work fine.
Designing for worst case: I would ensure the clock/data pulse is above the TTL threshold within the first 10% of the clock period. That means approximately one time constant at 10% of the 50ns clock period which is 5 ns. Allowing for the worst case load capacitance (50pF) makes the resistor value 100 ohms. ( time constant = R x C).
Or just put the micro in a socket (shudder) so you can replace/upgrade it when/if it dies ...
I checked the data sheet for the PIC mentioned. The I/O ports are specified at a load capacitance of 50pF and the device runs at 20MHz maximum. I would not be surprised if the suggested 1k resistors worked fine on the two In Circuit Debug pins (RB6/7) following the same kind of logic used to dismiss my suggestion! But seriously, the main point is that a series resistor is really really worthwhile. The value is only point that we should be debating.
In the case of the in-circuit debug it would depend on how fast the debug system ran. IF the debug program/hardware ran at the system maximum of 20MHz (very unlikely in my experience with other processors) AND the port had the maximum allowable load capacitance of 50pF then a series 1k resistor would have a time constant of 50 ns which is the same as the clock period. The schmidt trigger TTL inputs probably wouldn't cope with this. But this assumes worst case clock speed and load capacitance. If either of these were more reasonable then it would work fine.
Designing for worst case: I would ensure the clock/data pulse is above the TTL threshold within the first 10% of the clock period. That means approximately one time constant at 10% of the 50ns clock period which is 5 ns. Allowing for the worst case load capacitance (50pF) makes the resistor value 100 ohms. ( time constant = R x C).
Or just put the micro in a socket (shudder) so you can replace/upgrade it when/if it dies ...
VivaVee, I accept all what you say, but the last sentence is incorrect. I have never changed a pic to ESD issue (rather because it got 12V or overloaded). I accept your opinion, I also believe it makes it a bit more safe, but do not say if somebody does not do what you say will need socket for changing pics. This is incorrect and against practice. We have different design philisophy which is fine, I believe both works.
Regards,
JG
Regards,
JG
Apologies, I should not have put in the shudder comment. Perhaps an icon with a winking eye would have helped ''
I would solder the micro directly to the board but then I have access to good SMD rework tools and tend to use much faster micros that suffer signal integrity issues with DIP/PLCC packages - even assuming that these packages are available.
But the low clock speeds (in this application) would not make a socket an issue. You might find it valuable to have the ease of use and flexibility that putting the micro in a socket would give you. For whatever reason.
' I would solder the micro directly to the board but then I have access to good SMD rework tools and tend to use much faster micros that suffer signal integrity issues with DIP/PLCC packages - even assuming that these packages are available.
But the low clock speeds (in this application) would not make a socket an issue. You might find it valuable to have the ease of use and flexibility that putting the micro in a socket would give you. For whatever reason.
I believe an even simpler solution would be to use a standard serial setup (MAX232 and DB-9 connector) with a bootloader for firmware self-flashing. In my experience, bootloader flashing is faster and pretty reliable compared to using a simple programmer. The only disadvantage is that without a proper ICD interface, debugging isn't as flexible. You'll have to manual put in breakpoints or debug messages through the serial port.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.