----- Original Message ----- From: "sergio masci" To: "Microcontroller discussion list - Public." Sent: Monday, May 24, 2010 6:23 AM Subject: Re: [PIC] Using PIC to sample 90 wires > But you can take the USB complexity away from PIC completely by simply > using an RS232 to USB converter (as someone else has already pointed out). > Communicating via RS232 is trivial on a PIC. Agreed on that one, I forgot someone mentioned this, it would be the obvious solution as regards a beginner with PICs. > You can easily achive isolation with a minimal number of optos by placing > them between the PIC and an RS232 level shifter and then connecting that > directly to a RS232 to USB converter. Agreed also, as long as the isolation is between the PIC and PC there is not much to it - certainly having an external USB transceiver or similar with basic opto islolation is easier/cheaper than USB dataline isolation. The bidirectional, hi speed nature of USB makes it akward, but there is the ADuM4160. >> As far as I was >> concerned, the "easiest" would be to keep the whole thing in one IC, but >> it >> seems that the I/O limit on PICs is 85 so that's out (although add one SR >> and you have a two IC solution :-)). >> > > On the contrary, I belive there is far less to go wrong once the wiring is > in place and shown to be working than if you have a complex piece of > software effectively running in a distributed mode across 2 processors > running in parallel. Bullet proof comms between two processors requires > careful design and implementation. Amoungst other things you need to prove > that one processor crashing isn't going to leave the other seeing false > "healthy" lines serviced by the faulty processor. Still not convinced on this one - just doing the wiring is going to be a tricky task for someone with no prior experience with electronics or PICs. The "Bullet proof comms" with this particular project is not going to be much to speak of, and the software certainly won't be too complex. > The hardware implementation of SPI really isn't the issue, it's the > software drivers in the PIC that deal with the incomming and outgoing data > (the ISR etc), the high level protocol, that's what gets people every > time. Is the slave just going to send several bytes with each bit > representing the value of one of the (subset of) 90 lines? How are you > going to synchronise this so that you know which byte refers to which > group of lines? What happens if the slave doesn't load it's SPI transmit > register quickly enough? How are the master and slave going to handshake? > Are there going to be any timeouts to prevent lockups? You could just go > on and on with this stuff. You can't just throw something together adhock > it's got to be designed and then shown to be working. With 2 PICs in the > circuit you need some way to program each seperately. Then you need some > way to debug this multiprocessor system. Ok maybe you use the USB link to > talk to the master (get the master to dump some stuff or go into a special > error mode to do some checking). How will this help debugging the slave? > Are you going to make the protocol between master and slave capable of > supporting debug commands? I understand that it's the software side of SPI that could throw someone, but as comms go, it's about the easiest to pick up. As far as handshaking, syncing, timeouts etc go they are all obviously pitfalls of pretty much any communication system, but it doesn't stop them being used efficiently, I often use SPI or I2C between PICs with no problems, and with this particular project it could be as "simple" as an interrupt driven, one directional stream of data, using the chip select line to sync it at the start of the loop. I agree that it is the main problem (for a beginner) with more than one PIC, and this could likely cause problems, which is why I was hoping there was a one PIC solution. I'm also agreed that using shift registers is a sensible choice, the only worry I have is that it could be a pain to deal with so many ICs for a *beginner*, so I (and a couple of others) was looking at an easy way to keep it simple, circuit wise, like possibly one 85 I/O PIC with one shift register instead of one PIC with 12, this would avoid the SPI/Multi PIC stuff entirely. Best Regards, Oli -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist