Rob, I have used 98 PIC slaves and a PIC master on a voting machine that I built a few years ago. PIC 16c84 based. Each slave has an 8 bit ID code it uses to identify itself. In my version the Master initiates all communications. I use a common ground, a common power supply line that is locally regulated by each Slave PIC, and two lines, an open collector data line and a strobe that is generated by the Master. Having a strobe greatly reduces the task of programming. (By strobe I mean a data and command clock). Each PIC has its own RC clock. (el cheapo) The strobe line is driven by an NPN transistor whose collector 'load' is a 10 ma constant current source. The data line is driven by a constant current source of 10 ma also. On all Slaves and the Master the RA4 pin is used as an OUTPUT (it is open collector, so if you set it to a '1' it will be pulled high by the constant current source). Note that if ALL RA4 outputs are tied to the common data line and set to a '1', then the data line will be a '1'. ANY unit pulling this line LOW will cause the data line to go LOW. Note: the Constant Current Source consisted of two 1N914 diodes, a PNP transistor (2N3904 I believe) and an emitter resistor of 68 ohms 1/4 watt. Each PIC (Slave or Master) has RA4 tied to RA3. RA3 is programmed on each PIC to be an INPUT. That means that each PIC can read the data line continuously, and when necessary, pull the data line LOW. Whenever the data line is held low for more than a certain time, the Slaves do a software (warm) reset and go into a mode where they are awaiting a command. Looking for a data strobe signal is done via a routine that waits for a low. When it gets it, it reads the data line into an 8 bit register. Then it counts the number of times it waits in a loop looking at the strobe until the strobe goes high. If this number exceeds a certain pre-determined value of 32, then it uses a goto await_command routine to get ready to receive a new command. Commands include things like 'turn led on' and 'turn led off' which are useful for diagnosing problems. Some commands are two part commands like '# turn led on' which is then immediately followed by an ID. Only the matching Slave will respond. Typical commands are: turn led on turn led off # turn led on ;just the ID that matches # turn led off ;just the ID that matches ## led on ;Starting with ID 00 on each succeeding pulse the ; currently addressed slave turns led on ## led off ;Starting with ID 00 on each succeeding pulse the ; currently addressed slave turns led of f warm reset # respond with LOW ;Master requests Slave #xx to reply with one LOW pulse. # respond with VOTE ;Slave generates 1 LOW pulse for YES, 2 for NO, 3 for ABSTAIN ## respond with YES ;Starting with ID 00, with each additional strob e pulse ; currently addressed slave returns LOW on data line ; if its vote is YES. Keeps it there til strobe goes high. ## respond with NO ;Same for NO ## respond with ABSTAIN ;Same for ABSTAIN clear all votes ;Slaves clear vote register set all YES ;Slaves set vote to YES (for testing) set all NO ;Slaves set vote to NO (for testing) set all ABSTAIN ;Slaves set vote to ABSTAIN (for testing) allow voting at slave ;Slaves can read pushbuttons memorize current vote ;Slaves lock current vote in and ignore user inp ut Since each SLAVE and the Master may be running at slightly different clock speeds, the strobe line is used to initiate data transfers. Note that some commands will cause the Slave to go into a wait loop waiting for the LONG LOW that signals a warm reset. This LONG LOW on the strobe line allows the Master to unconditionally put all Slaves in a warm reset condition and therefore awaiting the next command. Strobes must be long enough to ensure that in the WORST case they will be detected by any Slave. Data is transferred by the SLAVE following the detection of the falling edge of the strobe. Following that the program causes the Slave to see if the current strobe is a LONG STROBE. If so, it does a warm reset. Depending on the command received, the program may loop waiting for a LONG STROBE to cause it to do a warm reset. A warm reset does NOT clear the local slave vote registers. That means that a ## respond NO can be followed by a LONG STROBE and then a ## respond YES, etc. I found the pullup method I used quite adequate. I made no attempt to run at blazing speeds, where the stray capacitance of the cabling would have created problems. If I recall I was able to execute a command like <## respond with YES> and get all 98 responses back and tabulated within .003 seconds. Then it was displayed on the LCD display in the form: YES = 80 NOT VOTING = 1 NO = 15 MAJORITY = YES ABSTAIN = 2 Hope this helps. Fr. Tom McGahee ---------- > From: Rob Lawes > To: PICLIST@MITVMA.MIT.EDU > Subject: 16c73 and I2C question > Date: Thursday, June 25, 1998 5:15 AM > > Hi all, > This is my first posting to the group I've been sitting on the > side for a month or so now. > Anyway I'm looking at using 100 pics linked to make up a control > of 1 or 2 things + voting > system. with 1 master controller and 99 slaves with unique > id's.. > Heres the general idea I think\hope. > Mode 1 the slaves request to turn something on to the master. The master > sends back > a yes or no. Slave does what it has to do depending on the response. > Mode 2 the master polls the 99 slaves to find out a yes/no state for > voting. The master > then displays results on an lcd. > Heres the questions. > 1. Has anybody had or is it possible to link upto 100 pics together using > I2C. with 2M > of cable between each pic? > > 2. If so did you buffer/add line drivers etc for the long cable run \ load > of the devices ? > > 3. Any better ways of doing this kind of thing using 73's with minimal > interconnections > between pics? > > Thanks in advance Rob > ICQ 14195085