Post by thread:Buses, IDs.... How to

SendTo: spam_OUTpiclistTakeThisOuTmitvma.mit.edu Hi PIC gurus, Lately (a few months now), I'm working on a project/product involving many PICes 84 or eventualy 61 (up to 64 for now, but expandable to 256 (or more?) in the future) organized in groups of four (as modules) controlled by a 'master' 16C65. The code in all 'slave' PICes is identical. Each of this 4 PIC 'modules' is powered and clocked separately and can be randomly switched (powered) on or off. The problem is that I developed the code in both 84 & 65 as they were dirrectly connected (ie. PIC84 <--> PIC65) and always repeating to myself "... it will be easy to modify the communication for more devices... " what a stupid presumption! (very bad technique...) Now, when I have more devices, I'm pulling my hair off... This PICes are connected on a I2C like bus (i.e. 1 CLK + 4 DATA lines driven by OC pins). Now, the questions: 1) How many devices can be connected to this type of bus? or is this calculation correct? Is there anything else I'm missing? - Is (input leakage) is max +- 5uA per I/O pin, as 95/96 databook says - R (pull up) is one 3K3 per line - Vih (min V input high) is 3.5 V for CMOS N = Vih / (Is * R) ==> N=212 2) Is there any way/trick to assign a unique ID to each device on power up or run time, so that each device gets always the same ID (this is neccessary!)? I think the simplest solution is to program each device with different ID, but I'd like to use max 8bit ID (bacause of the overhead in communication), so I'm limited to 256 IDs. Because the system is expandable by modules containing 4 units, I'll run out of 'unique' modules after 64. This will limit the existance of only few such systems. That is why I need a run-time assignation. Another 'trouble making' situation is that modules my be turned on/off as neccessary. I have few ideas if all the modules could be active at least for the setup time. 3) Did anybody implement a Ehternet (CSMA/CD) like (coax - single wire) communication protocol? Suggestions? 4) Any idea/suggestion how to connect and distinguish all that PICes? Thank you for your time, regards, mauricio Mauricio&arne.si http://www.arne.si

> This PICes are connected on a I2C like bus (i.e. 1 CLK + 4 DATA lines > driven by OC pins). > Now, the questions: > 1) How many devices can be connected to this type of bus? or is this > calculation correct? > Is there anything else I'm missing? > > - Is (input leakage) is max +- 5uA per I/O pin, as 95/96 databook says > - R (pull up) is one 3K3 per line > - Vih (min V input high) is 3.5 V for CMOS > > N = Vih / (Is * R) ==> N=212 Your calculation might be right on -- if you allow the bus to settle for a significant fraction of a second between transitions. Probably not acceptable. I would expect you'd have to take into account the pulse nature of the signal plus the inductance/capacitance of the transmission line. Receiver will see each new voltage level only a finite period of time after the transmitter changes it's output. Also remember that the characteristics of the interconnection wiring will vary with distance. Farther apart the stations will "see" different electrical properties and different pulse shapes. > 2) Is there any way/trick to assign a unique ID to each device on power > up or run time, so that each device gets always the same ID (this is > neccessary!)? > I think the simplest solution is to program each device with > different ID, but I'd like to use max 8bit ID (bacause of the overhead > in communication), so I'm limited to 256 IDs. But this involves programming each one differently -- yuck. The 1 octet identifier does limit you to 256 discrete stations. If you need more than 256 IDs, you'll just have to use a wider field and eat the communications overhead. > Because the system is expandable by modules containing 4 units, I'll > run out of 'unique' modules after 64. Here's a suggestion. I assume each module of 4 PICs will have a singe communcations "goes in" port and a seperate "goes out" port. Number each PIC on the module from 0 to 3. This should be done so that the address value depends on the socket each PIC occupies. This way, the low 2 bits of the address octet select which PIC on that module. When a packet arrives on the module (outbound from the controller), check the upper 6 bits of the address for all zeros. If it's zero, then that module is selected. If there's at least one 1 bit, then decrement the address octet's upper 6 bits (i.e. subtract 0x04) and send the packet on to the next module. For traffic header from the module tail to the central controller, each module increments the address octet as it passes through. Using this, each PIC in each module can be programmed identically (at least for the communications subroutines). Lee Jones ------------------------------------------------------------------- Jones Computer Communications .....leeKILLspam@spam@frumble.claremont.edu 509 Black Hills Dr, Claremont, CA 91711 voice: 909-621-9008 -------------------------------------------------------------------

SendTo: piclistKILLspammitvma.mit.edu Hi PIC gurus, Lately (a few months now), I'm working on a project/product involving many PICes 84 or eventualy 61 (up to 64 for now, but expandable to 256 (or more?) in the future) organized in groups of four (as modules) controlled by a 'master' 16C65. The code in all 'slave' PICes is identical. Each of this 4 PIC 'modules' is powered and clocked separately and can be randomly switched (powered) on or off. The problem is that I developed the code in both 84 & 65 as they were dirrectly connected (ie. PIC84 <--> PIC65) and always repeating to myself "... it will be easy to modify the communication for more devices... " what a stupid presumption! (very bad technique...) Now, when I have more devices, I'm pulling my hair off... This PICes are connected on a I2C like bus (i.e. 1 CLK + 4 DATA lines driven by OC pins). Now, the questions: 1) How many devices can be connected to this type of bus? or is this calculation correct? Is there anything else I'm missing? - Is (input leakage) is max +- 5uA per I/O pin, as 95/96 databook says - R (pull up) is one 3K3 per line - Vih (min V input high) is 3.5 V for CMOS N = Vih / (Is * R) ==> N=212 2) Is there any way/trick to assign a unique ID to each device on power up or run time, so that each device gets always the same ID (this is neccessary!)? I think the simplest solution is to program each device with different ID, but I'd like to use max 8bit ID (bacause of the overhead in communication), so I'm limited to 256 IDs. Because the system is expandable by modules containing 4 units, I'll run out of 'unique' modules after 64. This will limit the existance of only few such systems. That is why I need a run-time assignation. Another 'trouble making' situation is that modules my be turned on/off as neccessary. I have few ideas if all the modules could be active at least for the setup time. 3) Did anybody implement a Ehternet (CSMA/CD) like (coax - single wire) communication protocol? Suggestions? 4) Any idea/suggestion how to connect and distinguish all that PICes? Thank you for your time, regards, mauricio Mauricio&arne.si http://www.arne.si

SendTo: .....piclistKILLspam.....mitvma.mit.edu Hi again, sorry for this long delay, but I was so busy... First, thanx to Lee, Brooke, Richard and Antti who responded to my questions, next, few comments and clarifications. Lee wrote: {Quote hidden}> > 2) Is there any way/trick to assign a unique ID to each device on power > > up or run time, so that each device gets always the same ID (this is > > neccessary!)? > > Because the system is expandable by modules containing 4 units, I'll > run out of 'unique' modules after 64. > > Here's a suggestion. I assume each module of 4 PICs will have a > single communcations "goes in" port and a seperate "goes out" port. > Number each PIC on the module from 0 to 3. This should be done so > that the address value depends on the socket each PIC occupies. > This way, the low 2 bits of the address octet select which PIC > on that module. > > When a packet arrives on the module (outbound from the controller), > check the upper 6 bits of the address for all zeros. If it's zero, > then that module is selected. If there's at least one 1 bit, then > decrement the address octet's upper 6 bits (i.e. subtract 0x04) and > send the packet on to the next module. This is a very good idea, but presuming that inactive modules in and out ports act as 'pass through' connections, turning on or off one module somewhere in the 'chain' will cause the incrment or decrement of all remaining modules in the chain (from position N to end). Brooke wrote: > > You might look into the methods that Dallas uses. > They have "branches" that are switched to account for > leackage currents on their one wire buss. > I'll take a look, thanx. Richard wrote: > > I too am looking at going something similar down the road. I would > be interested in hearing the results of your work. > Sure, I'll keep you informed on any progress > > This PICes are connected on a I2C like bus (i.e. 1 CLK + 4 DATA lines > > driven by OC pins). > > Why four data lines? My thinking has been to use one clock, and two > data lines. > 4 data lines are really NOT necessary, but I have few pins left and with 4 lines I can TX in just 2 cycles (not instruction cycles) and RX in 3. {Quote hidden}> > 2) Is there any way/trick to assign a unique ID to each device on power > > up or run time, so that each device gets always the same ID (this is > > neccessary!)? > > I haven't had any good ideas on this subject either. My fallback > plan was to use a dip switch to set the ID number. And since I don't > want to use eight pins to read the dip setting, I would also have to > use a shift register. My lastest thought is to use a two or three > wire EPROM instead to store the ID (plus any other data that I might > need to save). If you need to store additional data, the solution with the SEEPROM is the best, IMO, but if you need only to 'get' the 8 bit ID, you can use the combination of DIP SW, pull-ups to set the ID and connect this 8 bit(pin) path to the PIC through an OC bus buffer. In this way, you can read the ID by enabling the buffer OC outputs with another PIC pin. Sure, you must take care of possible interference with normal operation of used pins but another OC buffer may solve the problem. Antti wrote: {Quote hidden}> for the auto config there are procedures that allow run-time config you > must assign uniqe id to each PIC, and one collect-call ID where every > PIC would respond, the response would be given by all PIC's at the same > time, however I2C data line OC buffers would implement an 'wired-or' all > PIC should stop sending their long ID once they see some body driving a > bit low. > > Master would see lowest uniqe ID of all modules currently powered. > Next Master will assign a 8 bit ID to that module, and that module > will go to configured state > > Next collective-call will get uniqe ID of the next module and so until > all modules are identified and configured > > maybe another universal call: reset state should available to re-start > system bus scanning. > > This technic is almost 1:1 what microsoft uses in their "Plug and Play" > device enumeration. this is interesting, very interesting, but the requirement of uniqe IDs is not so nice because requires have to 'serialize' each PIC, and that's what I hoped to avoid. Again, thanks to all who responded and excuse me for this long message (I wished to kill 4 flys with 1 hit....) By the way, I have PC Keyboard Emulation, PC Keyboard Host Emulation and a Half duplex serial engine code available, if anybody is interested. Bye, mauricio