|
|
Part: AN445
Category:
Description:
Company:
Datasheet: Download AN445 datasheet File size : 50 kB
Request For quote: Find where to buy AN445
Datasheet text preview:
Philips Semiconductors Microcontroller Products
Application note
ACCESS.bus mouse application code for the microcontroller
AN445
DESCRIPTION
ACCESS.bus is an open standard, defining a system for connecting a number of relatively low speed peripheral devices to a host computer, typically a desktop system. The ACCESS.bus (A.b) standard is driven by the increasing demand of workstation and PC users for more peripherals on the desktop than ever before. Devices range from keyboards, mice and trackballs to hand held scanners, card readers and `virtual reality' gloves. Some of the problems the A.b standard addresses are: difficulty of linking peripherals by non-expert users, desktop wiring clutter, limited number of I/O ports on a workstation, peripheral compatibility with different platforms and the high cost of software driver development associated with adding new peripherals to a system. At the hardware level, the A.b is based on the I2C serial bus developed by Philips. The I2C protocol is supported by standard IC components, including a range of microcontrollers of the 80C51 family. These microcontrollers provide the intelligence for executing the A.b protocol in both peripheral devices and host systems. Many desktop peripherals can be implemented with a single, low cost 8XC751 microcontroller where the firmware supports both the I/O activity and the A.b protocol implementation. This application note shows the 8XC751 firmware of Digital Equipment Corporation's A.b mouse implementation. Many A.b desktop devices could be implemented with a very similar code. After some discussion of mouse operation we shall give a short overview of the A.b protocol. Our discussion of the A.b is by no means complete--please refer to the specifications for more detailed information.
detecting the light, producing two signals which are out of phase by 90 degrees. Figure 1 shows the waveforms produced for one of the shafts when it rotates. The changes in these quadrature signals can be detected to determine the direction of the mouse movement, and its magnitude. The "positive movement" waveforms relate, for example, to a left to right movement in the X direction. Denoting channel samples as `AB', a transition from a `00' state to `10' shows a positive movement, while a transition from `00' to `01' shows a negative movement. The resolution of a mouse is determined by the number of changes to the quadrature waveforms produced in a unit length of planar movement. This is determined by the mechanics of the mouse, regardless of the speed in which the mouse is being moved. The mouse is an incremental pointing device, giving the host periodical position reports which show the displacement change relative to the last report. The microcontroller in the mouse takes the burden of keeping track of the rapid quadrature waveform changes and computing the relative displacement accumulated for each new position report. The quadrature waveforms are sampled, the changes are determined to be positive or negative, and X and Y relative displacement accumulators are being incremented or decremented accordingly. The average rate of change is determined by the speed of mouse movement. For accurate position reports the encoder waveforms should be sampled frequently enough in order not to miss changes. The DEC mouse produces 200 changes for one inch of movement. Mouse movement at 10 inches per second will yield event rate of 2000 per second, and the microcontroller attempts to sample the encoder waveforms with at least twice that rate--no more than 250 µS between samples. The MAIN routine of the example program performs this sampling in an infinite loop. It reads the position detectors at port 3, compares it to prior readings and if there was a change computes the new value of the relative displacement accumulators YCOUNT and XCOUNT . Position reports are sent to the host at a much slower rate. In this example, Timer0 interrupts the code at the reporting intervals, and its interrupt routine ("Timer0") initiates a message transmission to the host with the latest information if there was some change in the mouse position or the buttons. The Timer0 service routine samples the position of the three mouse buttons sensed on port 1. Button changes are reported to the host in the same message as the position reports.
ACCESS.BUS PROTOCOL OVERVIEW
The A.b communications protocol is layered in three levels. The lowest level is a subset of the Philips Inter-integrated Circuit (I2C) bus protocol, above it the A.b Base Protocol common to all types of A.b devices, and on top are the Application Protocols which define message semantics that are specific to particular functional types of devices. The I2C protocol defines the low level transaction over the I2C serial bus, using a single data line (SDA) and a clock line (SCL). The hardware definition for the A.b includes a four wire cable comprised of SDA, SCL and two voltage supply lines. The I2C provides for cooperative synchronization of the serial clock, bus arbitration, addressing, byte framing and byte acknowledgement by the receiver. The I2C is a multimaster protocol, and in ACCESS.bus subset the transmitter is always a master. The I2C allows 128 7 bit addresses, of which 125 may be used in A.b for peripheral microcontrollers. The I2C protocol burden is typically handled by microcontrollers both at the peripherals and at the host. The Base Protocol establishes the A.b characteristics including message envelope format, predefined control and status messages, configuration process and the special role of the host. The host acts as a manager of the bus, and all data communication is between the host and peripheral devices--there are no message transactions between peripherals. In A.b, masters are exclusively senders and slaves are exclusively receivers. The host and the attached devices assume master or slave roles at the proper time. An A.b message is an I2C bus transaction--a string of bytes sent by a master transmitter where each byte is acknowledged by the slave receiver, and the whole transaction is delimited by Start and Stop conditions. The minimum length of a message is four bytes, and the format definition includes specific locations for source address, destination address, message length and checksum. A protocol flag bit specifies whether the message is a device data stream or a control/status message. The configuration process is designed to permit auto addressing and hot-plugging of devices. This process detects what devices are present on the bus, assigns unique bus addresses to the attached devices and connects them with the appropriate bus drivers. The configuration process is supported by eight pre-defined control/status
MOUSE OPERATION
The mouse is the most popular pointing device for interactive operation with a workstation, personal computer or Windows terminal. It reports to the host two dimensional planar movement, and user's activation of two or three buttons. Many of the mice available today are opto-mechanical, using shaft encoders. As the mouse is moved over its pad, a lightweight rubber ball turns two perpendicular shafts. When the mouse is held with its cable at the top (away from the user), a left-right movement will rotate the `X' shaft and an up-down movement will rotate the `Y' shaft. Any diagonal movement will affect both. The shafts rotate slotted encoder disks which intercept light emitted by an LED. For each shaft there are two phototransistors August 1992
1
Revision date: June 1993
Philips Semiconductors Microcontroller Products
Application note
ACCESS.bus mouse application code for the microcontroller
AN445
messages. In any A.b system the host address is always the same (50H). When the system is powered up all the peripherals perform self testing, assume a default address (6EH) and send to the host an Attention message announcing their presence. The host sends to each device an identification request message, to which the devices respond with a unique 28 byte ID string. Having received the ID string, the host assigns to each device a unique address. In the case of hot-plugging, the peripheral device and the host will interact in a manner similar to the message exchange during system power up. In the last phase of the configuration process the host interrogates each device for its "capabilities string"--which describes the functional characteristics and the potential operating modes of the A.b peripheral. Capabilities information allows the software to recognize and use bus devices without additional knowledge about their specific implementation. Using the capabilities information enables writing `generic' software drivers that can support a range of similar devices, providing some level of device independence and modularity. The capabilities information is transferred to the host as a readable ASCII string with a simple syntax. A.b application protocols are specific to particular types of devices. The initial A.b specifications define Application protocols for three classes of peripherals: keyboards, locators and text devices. Each class is relatively broadly defined, leaving room for a variety of different devices. When drivers in the operating software of the host fully support a certain class, all devices conforming to the relevant Application Protocol will be supported, without any need for a special software driver. The Application protocols already defined can support many standard desktop peripherals. The Keyboards protocol supports up to 255 keys. Locator devices can have up to 15 degrees of freedom and up to 16 binary keys or buttons. This can cover devices like mouse, tablet, trackball, `virtual reality' pointing gloves, dial boxes and function key boxes. The Text Device protocol supports devices that transmit or receive messages consisting of strings of characters in some fixed character set. The simple protocol allows high level flow control, and is appropriate for devices like barcode readers, printers and magnetic card readers. Each of the Application Protocols has its own set of control/status messages in addition to the predefined messages of the Base Protocol. August 1992
I2C Protocol Handling
The I2C hardware interface on the 8XC751 operates on a bit by bit basis, and the full I2C protocol is supported by a combination of hardware and firmware. This arrangement results in a very compact hardware circuitry necessary for a low cost integrated circuit. The hardware activates and monitors the SDA and SCL lines, performs the necessary arbitration and framing errors checks, and takes care of clock stretching and synchronization. The hardware is synchronized to the software either through polled loops or interrupts. An I2C interrupt is usually requested (if enabled) when a rising edge of SCL indicates a new data on the bus (DRDY), or when a special condition occurs: a frame Start (STR), Stop (STP) or an arbitration loss (ARL). The interrupt is caused by the ATN flag, which is turned on by any of the interrupt inducing conditions. The ATN flag can be polled in a software loop as well. The example code handles the I2C protocol from an interrupt service routine (ISR). Typically, processing of a frame will be started with an interrupt (at the I2CINT label). If the bus operates at full speed, firmware processing inside a frame will be synchronized to the hardware bit by bit by a polling loop. The firmware polls the ATN flag in a loop limited to about 50 us (WaitATN) whenever it expects something to happen on the bus. If nothing happens during this period of time, the ISR is exited with the I2C interrupt re-enabled. When some bus event will occur later on, processing will resume with a new interrupt. Processing of bus events monitored by the polling loop is identical to processing events detected by an interrupt. The context from which the mouse was sending or receiving a message is maintained between events (ATN flag activations), and is not lost when exiting the interrupt service routine. The I2Ccxt byte stores the event that is expected, like waiting to send a bit or waiting for an acknowledge. Other I2C context elements are the data byte currently in the send or receive process (I2CDat), a bit counter (BitCnt) keeping track of the location within that data byte and a message byte counter (ByteCnt). In addition to the parameters that maintain the context of the very `generic' I2C communications, the code maintains some additional context elements that are relevant to the higher level A.b protocol. These are the computed checksum (Check), the type of message or command being received (RcvType), the type of message being sent or pending (SndType) and a flag indicating that a Position Report transmission is pending (SendRpt).
The Interrupt service routine proceeds in handling the low level details of the I2C protocol as a Slave receiver or a Master transmitter. The routines for Slave or Master processing are separate, and the jump to either one from DISPAT in I2CDONE routine is determined by the MST bit of the I2CON hardware register. The code examines the flags determining which event caused the ATN and then handles the low level hardware according to the context, performing actions like reading a new bit, acknowledging, sending a bit, issuing a Stop and so forth. When the low level slave receiver code completes reception of a byte, it calls the DORXB routine which deals with the contents of the byte--"application level" routine. Upon return from DORXB there is a call to the Sample subroutines. We effectively sample the quadrature waveforms in between I2C words in order to comply with the requirement for minimum sampling interval. It is interesting to note that code design does not completely separate application code from the I2C low level code--we call Sample from an I2C reception routine (and we do the same in the Master transmission routine). This is because in the 8XC751 the I2C bit processing cannot be done in parallel to other firmware activities and we have to make sure that the application's timing requirements are not being violated. The Master code will start sending a message if the processing routine was entered due to a Start condition. The routine, in fact, fulfills a request that was issued somewhere else in the code. For example, Timer 0 ISR sets the MASTRQ bit of the I2CON register, and sets the SendRpt flag. MASTRQ causes the processor to seize the bus when it is free and issue a Start. The Master processing routine examines the SendRpt flag, and if it is set the routine will start sending a Position Report. In a structure similar to the Slave code bit level details are handled in the MASTER routine. Byte transmissions are set up in the DOTXB routine.
Processing At The ACCESS.bus Protocol Level
A control/status message from the host is identified by the Protocol Flag, the most significant bit of the third message byte. The message body is a code for the command. When such messages are received, they are processed by the DORXCMD routine. Control/Status messages can be of either the Base Protocol or the Application Protocol. In the listing, base protocol codes have the prefix `I_', and application level protocol
2
Philips Semiconductors Microcontroller Products
Application note
ACCESS.bus mouse application code for the microcontroller
AN445
commands has the prefix `App_' (the definitions are in the include file `ab.inc'). The Base Protocol commands from the host are I_Reset, I_IdReq, I_ASgnAdr and I_CapReq. During the configuration process the mouse responds to the host with device to host control/status messages: I_Attn, I_IdReply, I_CApReply and I_Error. The string for the I_IdReply message is defined in GET_ID. The module revision and vendor name are padded with space characters in order to fit the fixed string length. The last four bytes of the ID string are a device number that can distinguish otherwise like devices with the same firmware. The protocol allows it to be a serial number or a pseudo random number. Our mouse uses a pseudo random number, produced by reading the 16 bit contents of Timer0 that is active since power-up (the number is extended to 32 bits by appending FFFF). The protocol includes `protection' against the rare event in which two like devices report the same pseudo random number or are mistakenly assigned to the same address. Just prior to sending the first data message to the host, each interactive device transmits a Reset message to its own assigned address (see PosMsg label in the example code). Any other device with the same address will be forced to the power-up
default address and will undergo configuration again, as it was hot-plugged onto the bus. The Capabilities String for the I_CapReply message is defined in GET_CAP. The string identifies the device as a mouse with specific characteristics: three buttons, two dimensions, relative location reports with 200 dpi resolution etc. The `prot(locator)' element tells the A.b software driver to use the Locator Device Protocol. The Locator Device Protocol is one of three application protocols already defined for the highest layer of the A.b protocol. This protocol defines a "Locator Event Report" which is used for the Position Reports of the mouse. A Locator Event Report is sent in the format of the device data stream Message defined in the base A.b protocol. The message body includes the current state of the buttons and the location difference from the last report. This data is coded as a sequence of two byte integers. For the mouse which is a two dimensional device, the message data stream length is six bytes, or three integers. The first integer contains the state of 0-15 locator key switches. For the three button mouse, only three of these sixteen bits carry
meaningful information. The remaining integers represent the position of the locator dimensions--the contents of the X and Y displacement accumulators. Three control messages specific to the Locator Protocol are processed at DORXCMD. The host initiates a self test by App_Test. App_Poll initiates one time transmission of a position report, and App_Setinterval modifies the default reporting interval controlled by the reload value of Timer0. This note highlights some of the implementation details--the commented listing covers the rest. As one can see, the A.b protocols are relatively simple to program in firmware. The low-level I2C implementation on the 8XC751 is somewhat involved, but the same low level routines can be re-used for different devices. The source code files for this program are available for download from the Philips Semiconductors computer bulletin board system. This system is open to all callers, operates 24 hours a day, and can be accessed with modems at 2400, 1200, and 300 baud. The telephone numbers for the BBS are: (800) 451-6644 (in the U.S. only) or (408) 991-2406.
A
B
01 DOWN
00
10 UP
Figure 1. Example of Quadrature Encoding Waveforms
August 1992
3
Philips Semiconductors Microcontroller Products
Application note
ACCESS.bus mouse application code for the microcontroller
AN445
MSDOS MACRO ASSEMBLER A51 V4.4 OBJECT MODULE PLACED IN MOUSE.OBJ ASSEMBLER INVOKED BY: A51 MOUSE.A51 LOC OBJ LINE SOURCE 1 ;************************************************* 2 ; Module: mouse.a51 3 ; 4 ; Firmware design and code for I2C desktop bus Mouse 5 ; Environment: 83C751 Assembler 6 ; Author: Robert Clemens 10Jul1990 7 ; (I2C I/O adapted from P.Sichel's "Keyboard" code) 8 ; Revision: 6Mar1991 9 ; 10 ; 31Jan1991 PAS Add numerous keyboard fixes. 11 ; Streamline input sample and I2C code. 12 ; Separate HW dependent constants. 13 ; Fix RxEnable after bus time out. 14 ; 15 ; 06Feb1991 PAS Rev X0.6 16 ; Fix sample timer initialization, use 14ms as default. 17 ; Fix length checking to allow commands with 18 ; more parameters than required. 19 ; Implement Set Interval command. 20 ; Handle LLLLL=0 to mean 32. 21 ; Fix ARL during selfaddressed reset message. 22 ; Fix to handle DRDY and ARL together. 23 ; Reorder mouse buttons as MRL, update Capabilities. 24 ; Do not allow other interrupts during TimerI svc. 25 ; Document sampling requirements. 26 ; Document hardware details. 27 ; Add check to skip waiting after DNRXB. 28 ; Misc cleanup in: BeMast, Assign,... 29 ; Use include files for 751 registers and ODB msgs. 30 ; 31 ; 6Mar1991 PAS Rev X0.7 32 ; Fix MN8Bit to check ARL before clearing DRDY. 33 ; Separate SendRpt flag from movement detected (Movement) 34 ; so only Timer0 will initiate motion reports. 35 ; Don't send Position report to def_addr even if polled. 36 ; Report InputError for invalid checksum, 37 ; unrecognized command code, or illegal parameter 38 ; value. Do not complain about parameters beyond 39 ; those anticipated. 40 ; Sample quadrature inputs between I2C bytes 41 ; to insure accurate tracking. 42 ; 43 ; 13Mar1991 PAS Fix DoStp4 to borrow Rx code and become IDLE rcv. 44 ; 45 ; 26Mar1991 PAS Rex X0.8 46 ; Update to use 4byte device number. 47 ; Get new device number only after Reset. 48 ; 49 ; 8Apr1991 PAS Add error checking to CapReq. 50 ; 51 ; 9Jul1991 PAS Add protocol_revision as part of module revision. 52 ; 53 ; 29Jul1991 PAS Protocol_revision in 1byte, fix ARL and MASTER bug. 54 ; Ignore unrecognized commands. Add I_MsgCheck. 55 ; 56 ; 11Sep1991 PAS Rev X1.2. Identify button positions as 1,2,3.
August 1992
4
Philips Semiconductors Microcontroller Products
Application note
ACCESS.bus mouse application code for the microcontroller
AN445
LOC
OBJ
00A8 0000 0001 0002 0003 0004 0007
0098 0007 0006 0005 0004 0003 0002
=1 =1 =1 =1 =1 =1 =1 =1 =1 =1 =1 =1 =1 =1 =1 =1 =1 =1 =1 =1 =1 =1 =1 =1 =1 =1 =1 =1 =1 =1 =1 =1 =1
LINE 57 58 59 60 61 62 63 64 65 66 67 68 69 70 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 95 96 97 98 99 100 101 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122
SOURCE ; Use new ab.inc file. Change I_MsgCheck to ; I_Error and do not overwrite pending SndType. ; Retry message after Negative Ack (NACnt). ; ; 7Oct1991 PAS Rev X1.3. Fix spurious large count problem. ; Fix STOP detected while MASTER without ARL. ; ; 25Oct1991 PAS Rev X1.4. Improve TimerI handler to avoid ; lockup when MASTRQ with SCL low. ; ; 4Nov1991 PAS V1.0 release for Boston mfg. ; 22Dec1991 PAS V1.1 align data with tx bit that lost arbitration ; ; ; ;************************************************ $ TITLE (Digital ACCESS.bus Mouse, V1.1) $ DATE (12/22/91) $ DEBUG $ NOMOD51 ;83C751 is not model 51 ;Define SFRs explicitly
; Symbolic addresses and masks $ INCLUDE( /dskbus/include/arch/reg751.inc ) ;************************************************* ; Module: /dskbus/include/arch/reg751.inc ; ; 83c751 SFR declarations ; Environment: 83C751 Assembler ; ; Date Revision Perpetrator ; ; 30Jan91 X0.1 Mark Shepard ; Created (from previous keyboard module) ; ; =1 102 $EJ ;*************** ; Interrupt Enable Register IE EQU 0A8h EX0 EQU 0 ET0 EQU 1 EX1 EQU 2 ET1 EQU 3 EI2 EQU 4 EA EQU 7 ; I2C Control Register I2CON EQU 098h ; Input (read) is bit #s for JB etc... RDAT EQU 7 ATN EQU 6 DRDY EQU 5 ARL EQU 4 STR EQU 3 STP EQU 2
;External interrupt 0 ;Timer0 interrupt ;External interrupt 1 ;TimerI interrupt ;I2C interrupt ;All interrupt enable/disable bit
;receive data ;attention ;data ready ;arbitration loss ;start ;stop
August 1992
5
Others parts begin by an
AN-1 AN-2 AN-3 AN-4 AN-5 AN-6 AN-7 AN-8
|
|
|
