Front Desk Bus An Alternative Proposal
Front Desk Bus An Alternative Proposal
ADB · PDF
| Filename | Front_Desk_Bus_An_Alternative_Proposal_19840820.pdf |
|---|---|
| Size | 0.28 MB |
| Subsection | fdb |
| Downloads | 1 |
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 →