In article <971016173601_1134222344@emout04.mail.aol.com>, Bob Buege writes OK, OK. I'll tell you more. Im working on a hardware neural network. >In a message dated 97-10-16 12:07:38 EDT, you write: > >> Im working on a network using PICS. >> >> All nodes on the network are identical, all joining onto a single bus - >> ie each pic doesnt receive and the re-transmit the data. >> >> (each pic is also programmed identicaly - including ID bits) >> >> Can anyone think of a way to get each PIC to allocate itself a unique >> number - node ID. ... but if there are 50 PIC modules then I want the >> numbers 1 to 50 or 0 to 49 for the numbers no more no less. > >Several responses to this thread have mentioned use of random numbers with >repeated attempts whenever a collision occurs with a previously allocated ID. >This will cause very long delays for the last allocations. Unless I am >missing something in the specs, the introduction of random numbers seems to >be a needless complication. I make the assumption that the nodes are being >allocated and deallocated at random times instead of all turning on at once. >Is this assumption true? Each node may be active or not at any time. There is no guarantee that a particular node will be on. > >If this assumption is true, each node can request ID allocation when it signs >on. Node 0 can assume the responsibility of sending the next available ID >number. If the request for an ID number times out, the node is the 1st one >and should be allocated as node 0. Perhaps that is a good idea. One PIC dedicated to managing the network addresses wont be too much of an overhead! > >The 7 byte bitmap suggested by Sean Breheny is a good way to keep track of >allocated IDs. If nodes can disconnect without notifying node 0 it may be >neccessary for node 0 to sequentially poll the nodes occasionally (one node >per second would verify the next every minute) to verify that each node is >still active. > >Things could get complicated if node 0 disconnects without changing the ID of >the next node to 0 and passing on its responsibilities but this may be a rare >enough occurance to ignore. Node 0 will always be on then, and could act as a bridge between more than one network. > >> I think I have a way of doing this but Im not saying anything right now. >> >> Comms between modules are 1) TX/RX line 2) CLOCK 3) CTS >> >> sort of a cut down serial com protocol >> > >Is the TX/RX line one line that is shared for both sending and receiving or >are there separate lines? TX/RX is one line. -- Jonathan Baker