On Fri, 17 Oct 1997 00:09:31 +1000 "Paul B. Webster VK2BZC" writes: >Norm Cramer wrote: > >> I know I can do it by polling the stations from the "controller". I >> would like something that allowed faster response. >... >> Polling stations that do not have data seems like a waste of time. >> BTW polling limits my devices to about 12 if I can tolerate a >500msec >> delay from input to response (this is really kinda high for this >> application). I would like to handle more devices and have better >> response time. > > Other replies so far noted. Mmm! Let me look at some basic >considerations here: > > * Assume 1200 baud for a start, that is 120 characters per second. >The >"bearer" is an open-collector mark-high serial line (notwithstanding >how >that is implemented) such that character collisions would not be >missed >although they might well be misinterpreted. The open-collector bus makes collisions behave in a predictable way. If one station sends 0 (which is low on the bus), at the same time another sends 1 (which is high on the bus), anyone listening will receive 0. If the stations always start their response synchronized to the poll character (so the bits overlap and will collide predictably), a very simple scheme could be implemented. The controller sends a special character which means "Does anyone have data". Stations that have data send their address back. The controller will receive the address of the lowest-numbered station that has data (since zeros in the address bit collision always win). Then it would send a sequence "Station n, send data". That station would have exclusive use of the bus to send data. After the end of the data, the controller would send the global poll again. If station n has no more data, it wouldn't send its address and the next higher numbered station with data would be recognized. This method also has the advantage that the controller doesn't need to know which addresses are in use. Of course all the stations need a unique address (A station could recognize that its address is not unique by detecting collisions during the sending of data. The first time it tries to send 1 and sees another is holding the line at 0, it should cease sending and do something to get it's address changed before sending again). Priority is fixed with the low-numbered addresses having more. Including a "priority" bit could allow high-numbered stations to get service even if there is continuous traffic from low numbered ones. The priority bit would be sent before the address. If a station's buffer is almost full, it would send a zero for the priority bit. Stations which have data, but not priority, would monitor the bit (send 1). If another set it to 0, they would not send their address. Then the controller would receive the address of the lowest numbered station having priority status. This could be extended to several levels of priority by adding more bits. The controller can ignore the priority bit(s). Or it could send them as zero itself to only request priority data (not sure what the advantage of that would be). Including a NAK response to the "send data" command would allow conventional round-robin polling, as well as recovery from a wrong address being received. The global poll could just be used to find out which addresses are connected (this would use messages of the form "What stations haven't been recognized", and "Station n, you are recognized" from the controller as it builds its table of valid addresses). The Dallas 1-wire devices have several variations on this. They use a 2-bit sequence to recognize addresses bit by bit. If you have an open-collector bus the Dallas protocol might be good to use, since you could then add various 1-wire devices without changing the hardware or software. The approach to a problem like this can't be generalized. It depends a lot on which stations are likely to generate a lot of traffic, which ones need to be recognized quickly, etc. >