Can a PIC PIC a PIC?

[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.