Can a PIC PIC a PIC?

[afbecker]

My difficulties with PIC's usually involve connectivity and electrical issues rather than program development so please bear with me on my various inquiries in that regard.

In the past I have received very useful insights from two participants in particular on the MicroChip website in the name of John Powers and Richard Collett who in my esteem are "Godlike." Gentlemen like Richard and John have the applied knowledge that simple experimenters like myself need to get off square one. I am always grateful for help of this kind.

I have tried without much success to control slave PIC's from a master. I have never been able to determine why they seem to refuse to work together the way I expected. I thought putting decoupling caps across the power traces would solve the problem but it did not. I regret that I can't at this moment relate the exact symptoms since it was a while ago that I attempted breadboarding some design scheme I had.

I have a few questions however that my get me going in the right direction again:

Will more than one PIC in a circuit interfere with the other's operation either through the traces or via EMF?

If I were to use a PIC as a master to send a digital output to the pin of a slave, is it advantageous (or imperative) to have both of them running off of the same clock signal? How about a master outputting to 2 slaves?

Is there an electrical limit to how many PIC's can be clocked together, or for that matter co-exist on the same power bus? This assuming the bus is correctly sized for adequate capacity.

Is a simple crystal oscillator package capable of providing clocking for more than one PIC on a clock bus, or does a more complex clock module of some design need to be introduced?

You may wonder what I'm trying to do, but I can imagine a master with slave modules having another PIC at it's core, and then being able to add identical modules for future expansion. I have been using "PIC" to imply that individual units may not all be the same part number.

[skimask]

I think all of your questions can be answered in the...dare I say...datasheets (as far as voltage/current loads, capacitance loads, etc), just not very easily 'cause there is just too many variables.

I have tried without much success to control slave PIC's from a master. I have never been able to determine why they seem to refuse to work together the way I expected.

In this case, I would think it would be all about timing.
YOU expect a signal at time X, because the one PIC sent it out at time X(a), but your program running on the other PIC, is still over at time Y, even though you are continually checking for it at time X(b).
I suppose sometimes a bunch of 'slop' is a good thing.

I can't at this moment relate the exact symptoms since it was a while ago that I attempted breadboarding some design scheme I had.

Those solderless breadboards have bitten me in the rear (as well as others) numerous times. The contacts wear out, you get high resistance connections, stray cap's all over the place. And I go on. Jist of the story, some people only use those things once and throw them out afterwards. Others (like me) are just wary of them and can them if there's ever a question about their reliability.

Will more than one PIC in a circuit interfere with the other's operation either through the traces or via EMF?

I wouldn't think so...but that's in a perfect world. A solderless breadboard is FAR from ideal when dealing with high frequencies.

If I were to use a PIC as a master to send a digital output to the pin of a slave, is it advantageous (or imperative) to have both of them running off of the same clock signal? How about a master outputting to 2 slaves?

Again, as long as the master sent it out at time X(a), and the slave was looking for it at the exact same time, and/or the signal is there long enough for the slave to catch it, I wouldn't think 2 PICs running off the same clock would offer any advantages.

Is there an electrical limit to how many PIC's can be clocked together, or for that matter co-exist on the same power bus? This assuming the bus is correctly sized for adequate capacity.

Clocks...as long the driver can drive the clock signal along the wiring, problem being the slew rate
Power...just like you said, decoupling, filtering, capacity, source impedance. If it can handle it, shouldn't be a problem.

Is a simple crystal oscillator package capable of providing clocking for more than one PIC on a clock bus, or does a more complex clock module of some design need to be introduced?

Not really. I think one of the easiest ways I've 'fanned out' a clock signal is to run the clock signal thru into multiple inputs of a 74LS04, then use the outputs to individual PICs.

I can imagine a master with slave modules having another PIC at it's core, and then being able to add identical modules for future expansion. I have been using "PIC" to imply that individual units may not all be the same part number.

Sounds reasonable to me, just like a motherboard with slots. As long as the 'units' follow the rules, shouldn't be a problem here either.

[Charles Linquis]

Q: Will more than one PIC in a circuit interfere with the other's operation either through the traces or via EMF?


A: No. Not if you have taken any care at all in PCB layout.



Q: If I were to use a PIC as a master to send a digital output to the pin of a slave, is it advantageous (or imperative) to have both of them running off of the same clock signal? How about a master outputting to 2 slaves?


A: This is not necessary. All can be running off separate clocks.


Q: Is there an electrical limit to how many PIC's can be clocked together, or for that matter co-exist on the same power bus? This assuming the bus is correctly sized for adequate capacity.


A: None.



Q: is a simple crystal oscillator package capable of providing clocking for more than one PIC on a clock bus, or does a more complex clock module of some design need to be introduced?

A: When you say "crystal oscillator package", I'm assuming you mean the "can" oscillator types that have power and gnd pins.
One of those will clock a lot of PICs. If you are talking about a "bare" crystal, then there are some very real limitations. In that case, you can use the CLKOUT of one chip to drive the CLKIN of another. I believe MChip has an app note that deals with this.

[afbecker]

Thank you gentlemen for your insights. I will put them to good use in the near future.

[Jasonce65]

Keep in mind that I2C and serial busses have a limit as to how many characters can be buffered at one time... timing is critical and (my experience being with RS-232 commands between a PC and several PICs on the same RS232 port) it is best to keep the language between the PICs simple. Servicing data on the I2C bus may be harder, since I think there is only a 1 character buffer. RS232 is wonderful for long distances if you want to make the PICS talk to each other in different locations.

Writing a program that systemmatically "up-rights" itself when the wrong data in the wrong time-frame is helpful. In other words, if it doesn't get the right stuff from the other end, after a period of time, it should start over at the top. (and not do weird stuff in the process).

The timeout for HSERIN is awesome to design a program around in this regard.

If you want to build a project like this, start out small, try some simple stuff first. Get an couple MAX232 chips and some caps and make the PIC talk to your PC through hyperteminal first, get the communications to happen to make LED's light up and closures to generate characters or data you'd expect. Then you can make two identical systems like each other talk to each other because you know the data flowing between them is correct.
Button presses on one end turn on LED's on the other, etc. This will give you a good feel for timing before tackling I2C. You can always drive multiple RX pins with one TX pin and vice-versa. Boosting the current with an open-collector driver (2N2222, etc.) and a 1k resistor can drive 20 recieving PICS over 1000ft at 9600 baud on twisted pair. If you're concerned with noise or RFI, get some Belden 8723 shielded audio cable like the broadcast engineers use.

Getting things to work as you expect is a tough one. Unless your crystals are completely different frequencies, they shouldn't be an issue. Also make sure that your settings are correct in the editor/compiler. chances are, if you can make the chip blink an LED, the settings are fine. Only place I'd worry about this is if you choose to use an RC reference oscillator as it will affect baud rate. If you are really sure you want to use I2C or a similar technology, then I think system timing isn't an issue at all since the clock is on a separate line - however these technologies are not well suited to long distances or noisy industrial environments, at least without some really good cable. If you want one master and several slave devices, RS232 is definately the way to go. Just send the first character to identify who the following characters are for, then either hard-code each PIC or use the port E as a "ID Code" bit pattern for up to 8 different modules. Then the code will be identical for all of them, just set the dip switches and go.

I got good experience doing all of this making a phone line controller that supplies hook-switch fuctionality for 10 phone lines into an audio coupler for studio use. 10 buttons in the studio cause 10 different phone lines to be connected to the audio coupler back in the engineering room - very cool. Sounds similar to what you're wanting to do.

Now I'm working on an audio router controller that multiple modules can be piggy-backed and all take commands from a PC.

Cheers,
J.-

[afbecker]

Thank you for the great commentary.

I have recently completed a fairly complex project using many of the development techniques you mentioned like using hyperterm to send and receive ASCII as a way of verifying the program on the PIC and it's character parsing.

My design is a PC based model railroad controller programmed in a Visual C environment which serially sends ASCII characters out to the PIC which in turn controls 16 latching relays. The idea of fanning out to slave PIC's was an earlier design idea which I abandoned prompting the matter I introduced in this thread. The design generation after that was using a "MAX4821" which used 3 address lines a latch and a reset line to address each of 4 relays on a "module." This would allow me 4 modules for my 16 relays. A 16F628A would handle the output lines and I could still use the ASART for serial in. I could never get more than 2 of these 4 relay "modules" to give me consistant results.

The most recent and successful design was brute force. I just used a 16F747 which gave me 32 outputs and 1 serial input. I could drive each side of the relay coils individually via a nice inductive load driver IC to produce a high or low state.

I got reliable results with the final design but I have always wanted to get a PIC to work like a traffic routing device in service to a master controller.

I will begin doing more work and try to apply some of your suggestions.