ICSP with multiple PICs

[NiHaoMike]

When there are multiple PICs on the same board, what is the accepted way to handle the ICSP?

[Skimask]

Are they all the same type of PIC?

[nctnico]

When there are multiple PICs on the same board, what is the accepted way to handle the ICSP?

Unless there is a good reason to have multiple microcontrollers (identical but electrically isolated channels) I strongly suggest you use a bigger microcontroller or hire someone who can. I have re-designed a lot of circuits with multiple (up to 13!) PICs because the designers couldn't get them to work reliably. The problem is that each microcontroller will each run at their own speed (asynchronous). If you need communication between them then the asynchronous nature of the processes can become a big pain in the ass real quick.

Anyway, if you want to take the road towards doom: you can connect identical PICs in parallel but connect the wire that talks back to the programmer to only one. This makes it a bit of a gamble whether to others are programmed correctly but it seems they usually are.

[Skimask]

In my latest, I've got 9 PICs of various types (2x 18F27J53, 4x 12F1822, 2x 16F688, 2x 18F26K20).  Some of them are the newer types that require a specific 32 bit sequence to be shifted in to begin the programming sequence, others are the older type that only require the normal MCLR/PGC/PGD/etc.  The ones that requires the differing 32 bit sequence are all wired in parallel...don't have a problem with those.  The rest of them, I've got MCLR on an 8 position DIP switch.  Hook up the PICKIT to one 'master' 5 pin port, select the PIC I want to program with the DIP switch, and do the programming.

[JVR]

In my latest, I've got 9 PICs of various types (2x 18F27J53, 4x 12F1822, 2x 16F688, 2x 18F26K20).  Some of them are the newer types that require a specific 32 bit sequence to be shifted in to begin the programming sequence, others are the older type that only require the normal MCLR/PGC/PGD/etc.  The ones that requires the differing 32 bit sequence are all wired in parallel...don't have a problem with those.  The rest of them, I've got MCLR on an 8 position DIP switch.  Hook up the PICKIT to one 'master' 5 pin port, select the PIC I want to program with the DIP switch, and do the programming.

What the hell are you building?

[ptricks]

When there are multiple PICs on the same board, what is the accepted way to handle the ICSP?

Unless there is a good reason to have multiple microcontrollers (identical but electrically isolated channels) I strongly suggest you use a bigger microcontroller or hire someone who can. I have re-designed a lot of circuits with multiple (up to 13!) PICs because the designers couldn't get them to work reliably. The problem is that each microcontroller will each run at their own speed (asynchronous). If you need communication between them then the asynchronous nature of the processes can become a big pain in the ass real quick.

Reliability isn't an issue with multiple chips, in fact it can be more stable.  I designed a product recently where I used 3 pic chips, sure I could have used 1 processor but 3 chips was easier, cheaper and more reliable. 1st pic was used to control the display device, 2nd pic handled all the inputs and outputs from sensors, 3rd pic controlled all the power functions. The reason it was easier and more reliable is because I didn't have to use a single chip that would have to use multiple interrupts to perform all the functions complicating the code quite a bit and requiring a much faster processor. 

If you need to keep the processors in sync you use a clock line, all of the pic models in the last 10 years can sync clocks.

[Skimask]

What the hell are you building?

Utter craziness...   
Analog Signature Analyzer with a bunch of digital stuff going on at the same time.  Using all these PICs because they're what I have one hand and the requirements keep changing...or is it feature creep?...LCDs, thermal printer, sd card, USB, etc.etc.etc.
If I had a single chip that had 2 ADCs that were capable of simultaneous sampling, AND 2 individual DAC modules both capable of individual DMA transfer, and it had enough pins to handle what I need, I'd be down to one chip.....But that animal doesn't exist.

[mrflibble]

What that? 2 dac, 2 adc, dma channels galore and plenty of gpio you say? stm32f407. problem solved. And I'm sure there are many others that fit the bill, it's just that this one springs to mind. And it's cheap too ... < $15 dev board.

Step 1: *boot microchippie*
Step 2: *embrace ARM*
Step 3: Enjoy life that suddenly became a lot simpler. ;-)

[Skimask]

What that? 2 dac, 2 adc, dma channels galore and plenty of gpio you say? stm32f407. problem solved. And I'm sure there are many others that fit the bill, it's just that this one springs to mind. And it's cheap too ... < $15 dev board.

Step 1: *boot microchippie*
Step 2: *embrace ARM*
Step 3: Enjoy life that suddenly became a lot simpler. ;-)

Step 4:  Profit???   
Ya, again, I'd normally agree.  I've been stuck in the PIC world for so long, I forgot how to learn anything else.  I've been playing with the Stellaris Launchpad (LM4F120H5QR) for a few days now using T.I.'s Code Composer Studio (CCS haters...don't tell me CCS is crap or the best thing out there.  I don't know the difference.  It's free and it's working for me so far).  Steep learning curve, trying, failing, learning, wash, lather, rinse, repeat.  The Stellaris doesn't have a DAC on it, but I'm thinking if I can learn that dev board/chip, then any other ARM chip with the hardware I actually need should be cake to transition to.

[andyturk]

Reliability isn't an issue with multiple chips, in fact it can be more stable.

I can see multiple chips being cheaper, but the reliability claim seems like a stretch. If you've got multiple mcus all chugging away asynchronously, generating test cases to exercise all the possible combinations is going to be really difficult. Everything is reliable before you start testing.