> > I have to agree with Russel, this would definitely be the simplest > > solution and by far the quickest to implement software wise. > While I don't "disagree" with Russell, the only problem I have with these > statements is the fact that no solution is going to be even vaguely "simple" > for a beginner. They will all include USB, which is pretty nasty to debug > even with the right tools, then there is the possible need for isolation > that could add a bit of hassle to the mix, so some form of isolated serial > comms may end up being used in the shift register solution anyway - 8+ opto > isolators for each SR? or one isolated SPI/USB interface?. 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 :-)). I don't know if you went through my (& others' ) serial suggestion circuit description and software description. You may be amazed at how simple it is, even for a beginner. And the hardware like unto it. Leave aside the USB for now which is a common factor and can be dealt with separately. Beginner: 1. Flash an LED on a specified port pin. Change the flash rate. 2. Read another port pin and use it to turn LED in one on and off. No debounce needed. So far 1. is "hello world" / flash a LED and 2. is basic sw3itch input. So, now: CLOCK_[high|low] involves raising and lowering a pin LATCH_[high|low] involves raising and lowering a pin. GETBit involves reading a pin. SAVEBit involves storing a bit from GETBit. They have to learn how to do this sooer or later. INIT involves setting up input and output regsiters etc. ALL of these are done in 1. & 2. The beginner needs only extend them to SR use. N=90 say INIT N x (clock high, read bit, clock low,GETBit, SAVEBit ) That's the software. Per input pin provide an input divider as required. May be x R per line. May be more. Hardware. Vdd to Vdd Vss to Vss. 8 inputs to 8 inputs. SerialIn to SerialOut on preceding register. Serial_out to Serial_In on preceding register. Clock to all other clock pins. Latch to all other latch pins. That's the hardware. The 2x PIC system is going to take more explaining to your beginner. > > All > >this would be so trivial. > Again, I think we are forgetting that nothing will be trivial to someone who > has not touched a PIC before. Most people start with flashing an LED Yes. As above. > designing a 90 input, USB capable board that may have >13 ICs on it. The "13 ICs" is a conceptual bogeyman. There are two IC's. One is a PIC, The other is a SR with NO external parts that is divided into m8 bit chunks for convenience. Dasiy chain it all together and it works. NO other hardware, apart from the necessary input networks and power supply decoupling. > I think > the argument for one or the other is not quite as simple as it may seem. Not for "the other" certainly :-). > Whatever the choice, it's not like there isn't going to be plenty to go > wrong with either, I still think that the (less ICs = less wiring = less to > go wrong) argument could have some weight to it. Yes. But repetition of a design in 8 bit modules where all are identical has great merit. The 2 x hyperPIC arrangement has assymetric port use, lots of lines crossing over, and more. The SR version is simplicity galore. > As far as adding one shift register, learning a bit, and then progressing > etc, you could also apply that argument to the multi PIC scenario. There are only two stages of learning. - Use one shift register - Use 2 or more shift registers. This ensures you know how to chain them (which is not hard to understand once done but anything can be surprisingly confusing to start. If you must have more speed and use more PIC pins, use 12 x SR, each feeding a port pin = 12 bits. Add 3 pins for SIN, CLK, Latch and you still have pin spare in 16 to send async serial to the PC via a USB/RS232 converter. > As far as > communication goes between PICs, it would certainly be easier than the USB > part and SPI (if used) is pretty much just another shift register anyway. 1. SR scheme doesn't have a 2nd processor. 2. Getting two PICs talking SPI coms with data fetch from A and store in B etc will be a vast conceptual and practical jump for beginners. 3. USB/RS232 converter eases the SUB lod vastly. > I guess all I am saying is that I am not totally sold with either method for > a beginner, and I don't think there is a "clear" winner, for someone who > wants to keep it a simple as possible, with concept/code and circuit. I started off suggesting the serial system mainly because I have used it and found it useful. I was by no mans sold on it and "lots of ports" sounds easy. But having argued the point I feel the SR scheme is simpler to do, conceptually simpler and easier to code than the two processor system. Do it all in one processor and it would be different. Russell -- http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist