Skip to main content
Home Documents ADB Front Desk Bus An Alternative Proposal
Front Desk Bus An Alternative Proposal

Front Desk Bus An Alternative Proposal

ADB · PDF
FilenameFront_Desk_Bus_An_Alternative_Proposal_19840820.pdf
Size0.28 MB
Subsection fdb
Downloads1
Contents
I ~' - --~-" To: Bob-Bailey Gary Butts - APG Dave Christensen - APG Mike Clark - - APG Burrell Smith From: Peter Ashkin Subj: Front Desk Bus - An Alternative Proposal Date: August 20, 1984 To make the "Front Desk Bus" a more fleiible and powerful interface, I believe that it should have the following properties: The bus shall be bidirectional. [An input only bus is too 1. restrictive.) 2. Each device on the bus has a unique address. For practical purposed the address range should be 0 - 15. Some of these addresses may be reserved for broadcasting universal messages. (This seems like a sane number of devices, particularly since there eiists today only three devices; keyboard, keypad and mouse.) 3. . All messages on the bus shall be filed length. (This facilitates the decoding of commands by devices of limited intelligence.) 4. Only one rdevice at a time can be "bus master". This ability can be relinquished, and another device can assume bus mastership. (Usually the host will be the bus master, but the interface should not preclude a future device which may master the bus. Also, by having an undisputed bus master, there are no bus contention problems.) 5. There shall be a limited number of commands. Commands should be broken into two groups, basic commands (T AL~ and LISTBN) which all devices on the bus shall understand; and advanced commands which only intelligent devices (as appropriate) should understand. (This makes the command interpreter, be it hardware or software, simple. It also allows more comple1 devices to used some of the "fancier" teatures of the bus.) There shall be only one active talker on the bus at any time, this may be the host or a remote device. (When a new device is commanded to T ALl, an old device that was addressed to T ALl is "untalked".) 6. FrontJ&s_k_B_u_s__ ~,-- __ _ Auaus.t 24. J 984 7. Bus must accept devices that talk at different speeds. The host, -at-a· minimum, must be able to listen at various speeds. (This implies that the data on the bus must be se1f-clocked... By not rigidly filing the speed of transmission, the bus does not need to be crystal (etc.) controlled.] 11 8. There can be multiple active listeners on the bus. (Listen commands are additive, as needed, multiple devices can be addressed to listen. To remove a selected listener, a special Unlisten" command is sent to globally deselect all listeners.) 11 9. An interrupt mechanism must be available which circumvents the needs to poll devices that need service. (Since the bus is relatively slow, the interrupt latency time in a polled environment is long. The ability to interrupt the master for service is important.) 10. There shall eiist a mechanism that sends a unique message that puts all devices on the bus into the command (reset) mode. (This is important if for some reason the bus gets hung".) 11 11. There should be a minimum number of "time-outs" needed on the bus. The only needed time out should be to time out a non-responsi…

Showing first 3,000 characters of 9,168 total. Open the full document →