View Full Version : Reusing PGC & PGD pins
Demon
- 16th June 2024, 03:07
Do I have special considerations to take when I reuse ICSP pins?
Do I need a jumper during programming if I have a device connected, like a resistor/LED?
(I couldn't find any REUSE PGC/PGD/ICSP posts)
EDIT: I have found this post elsewhere that says we can do it (I'm using it as a heartbeat LED to diagnose any timing issues).
https://forum.microchip.com/s/topic/a5C3l000000MNnAEAW/t321516
tumbleweed
- 16th June 2024, 13:29
Yes you can reuse them but you need to be careful as to what circuitry you hang off the pins.
Most ICSP programmers have 4.7K pull-down resistors on the PGC/PGD pins and assume the pins will idle low.
You shouldn't put too much additional load on the pins, add pullups or capacitors, or use the pins as inputs if they'll be actively driven high/low by the connected circuitry.
Jerson
- 17th June 2024, 02:54
I connect the ICSP port on the PCB to the ICSP pins of the controller directly. The Pins in turn go to the rest of your circuitry via resistors so that you do not need programming jumpers to perform ICSP. The resistors help resolving contention. Hope this helps.
richard
- 17th June 2024, 06:05
i like to connect some critical or dangerous hardware to one of those pins, like the enable pin for the high power laser or the step input for the Z axis.
that way you really know when reprograming is happening:eek:
Demon
- 18th June 2024, 04:16
To be clear, I will NOT have the circuit powered when I'm programming. The PCB must be removed from the main board in order to be programmed (I use the same connector for operation and for programming).
Specifically, now I'd like to connect the output of a 74HC14 on PGC or PGD (running out of pins).
Demon
- 18th June 2024, 04:18
i like to connect some critical or dangerous hardware to one of those pins, like the enable pin for the high power laser or the step input for the Z axis.
that way you really know when reprograming is happening:eek:
Pics or it didn't happen.
:wink:
richard
- 18th June 2024, 09:33
its very easy to do.
on a pic curiosity board the pins are just there begging you to use them. you can kinda forget the programmer is on board
when there is no need to plug and unplug it at all.
9684
tumbleweed
- 18th June 2024, 13:12
To be clear, I will NOT have the circuit powered when I'm programming. The PCB must be removed from the main board in order to be programmed (I use the same connector for operation and for programming).
Specifically, now I'd like to connect the output of a 74HC14 on PGC or PGD
I wouldn't do that. Your safest bet would be to have a jumper you can remove to isolate the output of the HC14 from the PGC/PGD pin while you're programming.
pedja089
- 18th June 2024, 13:19
I conect ICSP directly to pins. And from konektor, other part of circuit connect via 2K resistor. If you use pin as inputs, then other hardver driving state of pin. So not to have colision with programmer, put some resistors.
For MCLR use 10K resistor. As it can reach 13V. I generaly avoid using MCLR.
But this makes it hard to use debuger....
tumbleweed
- 18th June 2024, 14:44
And from konektor, other part of circuit connect via 2K resistor.
You have to be careful when using the pin as an input.
While a series R can help isolate the pin from the ICSP programmer, if the external circuit is driving the pin high then this can change the idle state of the pin that the PIC sees during programming from low to high depending on the R value. The ICSP typically has 4.7K pulldowns on the PGC/PGD pins, so the series R creates a voltage divider which you may need to take into account too.
Demon
- 27th August 2024, 07:12
Does this look "safe" to use an opto-coupler to be able to reuse ICSP Clock & Data pins?
9739
I'm using my old MeLabs USB programmer with stock header; circuit is powered by wall adapter/7805.
EDIT:
1. Should I be better to use an opto with a CurrentTranferRatio of 0%?
2. Is anything stopping me from doing the same thing to MCLR with quad opto?
Ioannis
- 27th August 2024, 09:39
If you think that through the opto you can transfer the High and also the Low state of the 74HC14 then be sure it won't happen. When opto is ON, it will transfer the High state only. The Low state of the HC14 output cannot pass because collector of opto is reverse biased. You need then a pull down on the emmitter of the opto, which will have loading effect on the ICSP programmer.
Best and simpler is to use a simple and cheap resistor to isolate the 74HC14.
Ioannis
Demon
- 31st August 2024, 03:24
What would you recommend?
(it's a MeLabs USB programmer)
9744
EDIT: 10K seems to work, but I don't want to shoot myself in the foot down the line. I'd hate to invest a lot of time using pins B6 and B7 as input, only to find out I can't do this later on (I'll be using this exact switch configuration - 10K pulled low followed by 10K/0.01uF).
richard
- 31st August 2024, 08:27
are those switches meant to be active high ?
if so then applying somewhat less than vcc to the pic input pins and all those extra components seems a recipe for non success.
for my money i would use the weak pu and have switches active low [don't press buttons when programming is not to much of a constraint]
Ioannis
- 31st August 2024, 11:57
My practice is what Richard noted. Always have either external pull ups or use the port b with the internal pu enabled and active low switch. No other circuit needed and have the Icsp programmer there just fine.
Ioannis
Demon
- 31st August 2024, 18:56
are those switches meant to be active high ?...
They can be whatever they have to be so that it works perfectly. It's my circuit, and I answer to nobody (except those here that know more than me :) ).
...applying somewhat less than vcc to the pic input pins and all those extra components seems a recipe for non success....
Oddly, it's working as-is.
...i would use the weak pu and have switches active low....
I just checked, 16F18877 has WPUx register for all ports except pins E0, E1 and E2, so that's a plus.
I'm still doing research on all the processes I need, so the switches can easily become active low.
...don't press buttons when programming is not to much of a constraint...
Definitely agree, I never touch the circuit while it's being programmed.
That being said, is 10K a reasonable isolation resistor in this case?
:)
Ioannis
- 31st August 2024, 21:43
Do not risk reliability and toss the resistor.
Use the internal pull-up with low going switch and you will be just fine.
Ioannis
Demon
- 31st August 2024, 22:31
Do not risk reliability and toss the resistor.
Use the internal pull-up with low going switch and you will be just fine.
Ioannis
I'm using the internal pull-ups.
The signal from the encoders reaches the PIC pins with the 10K series and 0.01uF to ground (as per Bourns design), but not if I add that 2nd 10K isolation resistor towards pins B6 and B7.
The original Bourns design has the pull-up/down resistors BEFORE the 10K/0.01uF combo.
(gonna do some experiments)
richard
- 31st August 2024, 22:51
if your re has the possibility that it can be stationary with either A B contact closed [ground] then it will always be possible to stuff up programming and no isolation other than disconnection will work
the isolation objective is
1 don't impose a logic level on the pgm pins that will damage the programmer
2 don't impose a load on the pgm pins that will corrupt the programming signals
3 allow your signal to reach the pins without signal corruption
Demon
- 31st August 2024, 23:16
if your re has the possibility that it can be stationary with either A B contact closed [ground] then it will always be possible to stuff up programming and no isolation other than disconnection will work...
Yup. I've reached the same conclusion.
I have to use a jumper.
It would have been nice to figure out a "built-in" solution, but that's not happening.
Ioannis
- 1st September 2024, 11:42
Most encoders of good quality should have the contacts open. At least I have not encountered any that was not.
But in case a contact on RB7,RB6 is closed I would definitely use a jumper. Not resistors.
Ioannis
Powered by vBulletin® Version 4.1.7 Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.