Dual PIC anyone?
Moderators: David Barker, Jerry Messina
Dual PIC anyone?
Dear all,
I am considering whether is it technically possible to put two PICs of the same make on a single board. The aim being:
1. doubling the processing power
2. synchronizing the tow PICs --> sort of like dual core processor
I am wondering if anyone has done this before or is it wishful thinking. Some may say why not use dsPIC or PIC24 or PIC32. Well, I have not tried these PICs yet. It seems too daunting a job for me to get adapt to the new platform. And most of all, I love SF! Can't live without it!
Regards,
Liak
I am considering whether is it technically possible to put two PICs of the same make on a single board. The aim being:
1. doubling the processing power
2. synchronizing the tow PICs --> sort of like dual core processor
I am wondering if anyone has done this before or is it wishful thinking. Some may say why not use dsPIC or PIC24 or PIC32. Well, I have not tried these PICs yet. It seems too daunting a job for me to get adapt to the new platform. And most of all, I love SF! Can't live without it!
Regards,
Liak
liak,
It is perfectly possible to put as many PICs on one PCB to perform jobs and swap information between them.
To try and use them a parallel processors working on the same problem would however be beyond our favourite microprocessor I would think!.
Several years ago I developed a car alarm for a customer which had 18F6585 as the main processor for GSM/GPS, CAN and overall system management, 16F946 for all vehicle I/O and external serial interface modules, and 12F683 for accelerometer management.
All the data was transfered to the main processor by serial ports both hardware and software based.
A single PIC would never have been able to cope with all the information that was need to be dealt with at a single moment and this approach still works fine to this day in this particular product.
It is perfectly possible to put as many PICs on one PCB to perform jobs and swap information between them.
To try and use them a parallel processors working on the same problem would however be beyond our favourite microprocessor I would think!.
Several years ago I developed a car alarm for a customer which had 18F6585 as the main processor for GSM/GPS, CAN and overall system management, 16F946 for all vehicle I/O and external serial interface modules, and 12F683 for accelerometer management.
All the data was transfered to the main processor by serial ports both hardware and software based.
A single PIC would never have been able to cope with all the information that was need to be dealt with at a single moment and this approach still works fine to this day in this particular product.
Dear Doj,
I guess your setup must be using different crystals to drive each PIC separately. I intend to use a single crystal to drive the two PICs in order to:
1. save cost and space
2. ease of synchronizing the operation of the two PICs.
I have read somewhere in Microchip forum that this is possible. Have you tried this before?
Regards,
Liak
I guess your setup must be using different crystals to drive each PIC separately. I intend to use a single crystal to drive the two PICs in order to:
1. save cost and space
2. ease of synchronizing the operation of the two PICs.
I have read somewhere in Microchip forum that this is possible. Have you tried this before?
Regards,
Liak
I have made a few systems that run on multiple PICs. In my latest creation, I actually did run 2 PICs from the same crystal. I've had the best results by doing the following....
1. Put a crystal on OSC1 and OSC2 pins of PIC "A"
2. Set PIC "A" for OSC = HS
3. Connect the OSC1 line of PIC "A" to the OSC1 line of PIC "B"
4. Leave the OSC2 pin of PIC "B" unconnected
5. Set PIC "B" for OSC = HS
As for communication between PICs, I use a custom version of the Shift library. In my version, the PIC receiving the data is one controlling the clocking pin. I use a "DataReady" pin to signal when there is data to be read from on PIC to the other. I'm sure there are much better ways to do this with all the built in SPI and I2C functions. However, I'm usually dealing with randomly firing interrupt routines on both PICs. So I like to do my intra-PIC communication synchronously with software.
1. Put a crystal on OSC1 and OSC2 pins of PIC "A"
2. Set PIC "A" for OSC = HS
3. Connect the OSC1 line of PIC "A" to the OSC1 line of PIC "B"
4. Leave the OSC2 pin of PIC "B" unconnected
5. Set PIC "B" for OSC = HS
As for communication between PICs, I use a custom version of the Shift library. In my version, the PIC receiving the data is one controlling the clocking pin. I use a "DataReady" pin to signal when there is data to be read from on PIC to the other. I'm sure there are much better ways to do this with all the built in SPI and I2C functions. However, I'm usually dealing with randomly firing interrupt routines on both PICs. So I like to do my intra-PIC communication synchronously with software.
Dear JWinters,
Thank you very much for the feed back and suggestion on setting up the PICs. Very glad to hear from some one who has successfully run it.
I will see if I can make use of your suggestions. I am trying to figure out if it is possible to have the two PICs to share a single SD card, reading from it without re-init everytime.
Regards,
Liak
Thank you very much for the feed back and suggestion on setting up the PICs. Very glad to hear from some one who has successfully run it.
I will see if I can make use of your suggestions. I am trying to figure out if it is possible to have the two PICs to share a single SD card, reading from it without re-init everytime.
Regards,
Liak