Sharing ICSP lines for 2 Pics

[TimB]

Hi all

I have a project I'm just starting, 2 pics on the one board and coms with the outside world.

Pic 1 is super busy

Pic 2 gets data from Pic 1 and talks to the outside world

My first thoughts were.

Pic 1 sends data to Pic 2 It needs to send a total of 4 bytes or to be more accurate 9 bits of data x 2. My first though was to have a parallel port of 9 lines tied directly to the other pic with an extra pin that says what 9bits was on the lines. I have the pins. Pic 1 also needed once in a blue moon to get messages from  Pic 2 so added software TX and RX lines and a "I need to talk to you" line.

Pic 2 has the parallel lines, the software serial and was to act as an SPI slave. I have already written the SPI slave code and it works. However its ok for 2 pics to talk to it but rubbish for me to from the outside.

So now I am thinking scrap it all and go all usart.

Pic 1 sends 2 bytes at a time to Pic 2. That can be done almost instantaneously as there is a 2 buffer. Each packet will have half the info and a flag says which half it is.

Pic 2 can then RX that data, As the pic has 2 usarts It can also coms with the outside world via Usart 1. So far so good.

Now my question/issue. The pics I am using (18f23k20) has TX2/RX2 on the ICSP pins. So if I link them then first issue is the cross TX-RX etc so the ICSP lines will be wrong on one of them. Seconds is I think the second pic will try and run,then drive the TX line. The MCLR lines will go to one pic and that will set itself up but the second will not and probably run messing with the same ICSP lines

Only solution I can think is a switch to isolate the lines for programming 3 way so its Program P1, Program P2, run.

Can anyone think of a better solution?

[TimB]

Ok after writing that out and rethinking I made a mistake and there is no issue

Pic1 can talk to Pic2 via the same USART number eg Pic1 TX1 to Pic2 RX1

So no clash of the ICSP there.

Pic 2 can talk to the outside world Via Usart2 which is also the ICSP pins. As the board will not be connected during programming no issue there.

So basically I should think more before posting. I actually often write posts but never hit "POST" as in the process of writing it out I figure out the solution. I was a few mins to late in figuring out the solution this time.

Tim

[charliecoutas]

Have you used the PIC24/dsPIC33 jobbies yet? They are very much faster than the 18F series and the coding is just as easy. I have just done a voltage controlled oscillator for a Theremin using a 33EP512GP806 running at 140Mhz, works a treat.

Charlie

[TimB]

Since I posted I decided to drop the second pic.

What I'm doing is analysing a composite video signal. As its a Pal signal there are 25 (full) frames a second. In reality I do not need a 25hz update on the data in the video signal. 10-12 hz will do fine. Note a super high speed CPU is of no use as you have to watch the full scan line.
That then frees up a lot of CPU time.
So much time in fact I can use one pic to do all the work. I will still be hindered by the baud rate speed so will keep packet timing right and make the RX end be tolerant of the way the data is received.

Now the board has just one pic. It runs at 64mhz more than fast enough.

Making it all run on the one pic will save me a lot of effort, Only down side is the update speed. 25hz down to say 10. Not an issue as 1 hz will be the end output.

Tim

[LeonJ]

Tim,
Seems like you found the simpler solution "thru the path of complexity" which is quite normal!

But for the record: I often have 2 or more pics that need to interchange info. I connect their ICSP lines together as a "bus" with a series push button switch in each MCLR line. Just before flashing, simply hold down the target's switch for the flash-time duration. During run-time, the ICSPDAT/ICSPCLK lines double up as the TXD/RXD lines for Full Duplex UART communication. (Each TXD line must be configured as "Open Drain" with Internal PullUp enabled)

This works well for up to 5 pics (perhaps more) with a Pickit3.

Leon

[TimB]

Thanks Leon

I will remember that. It seems it will work ok.

Tim

[charliecoutas]

Tim, can you tell us what you are doing re the composite video signal? It sounds interesting, as most of your projects are!

Charlie