📄 readme.txt
字号:
the TXFIFO loading code will not handle the data properly. Unlike the
keyboard, which sends data reports even when no keys are down, the mouse
report requests will get NACK'ED unless there is data in the buffer.
~~~~~~~~~~~~~~~
REPORTS.ASM
~~~~~~~~~~~~~~~
This file contains three independent functions that all handle writing
data reports to the various TXFIFO's. Each of the three is described
below:
1. SEND_KBD_REPORT_EP2 -
This function is called for three main occurences:
A. A TXD2 INTERRUPT IS RECEIVED -
This occurs after the host has successfully received a data
report. The TXD2 interrupt is a signal to the code to write
the next key report to TXFIFO2 so it is ready for the next
IN-TOKEN on EP2.
B. THE CODE IS IN IDLE MODE AND A KEY EVENT OCCURS -
When in IDLE mode (described above in the "TIMER0_ISR"
section), key events control the TXFIFO2 writes and not
TXD2 interrupts. Therefore, this SEND_KBD_REPORT_EP2
function is called from the "kbdisr.asm" code whenever a
key has been added to or removed from the keyboard buffer.
If the idle mode is TIMED rather than INDEFINITE, a report
is written after the IDLE_RATE duration expires no matter
if a new key event has occured or not. This call comes from
the "TIMER0_ISR" function in "DONGMAIN.ASM".
C. UPON INITIALIZATION -
An initial keyboard report must be written to TXFIFO2 so
that when the host sends its first IN-TOKEN request, there
is data ready to be sent. This call is made from the
"DONGLE_INITIALIZATION" function within "DONGMAIN.ASM".
Once this function is called, FIFO availability is first checked
and, if a vacancy exists, the code checks for the
"ERROR_ROLLOVER_STATE" condition. This is a variable set or
cleared in "KBDISR.ASM" after an "add_key" function is called.
It is set to a value of one if the keyboard has tried to send more
than five keycodes. This number comes from the fact that the
keyboard report is eight bytes in length and three are used for non-
key code functions (Report ID, Modifier key byte, & Reserved byte).
If the ERROR_ROLLOVER_STATE variable is set to one, the key code
part of the report is filled with all 01's, as specified in section
G.3 of the version 1.0 HID Class Specification (The value of 01 is
seen in the example keyboard report sequence given in Appendix C).
If the ERROR_ROLLOVER_STATE variable equals zero, the current
contents of the keyboard buffer is written to TXFIFO2.
2. SEND_KBD_REPORT_EP0 -
This function is called only after a "GET REPORT (input)" request
has been received from the host on EP0. The host then expects to
have the TXFIFO0 filled with the current keyboard buffer data.
3. SEND_MOUSE_REPORT -
This function is entered at two different places depending on
where it is called from:
A. When called via a TXD3 interrupt, it enters at
"SEND_MOUSE_REPORT". This checks to make sure that at least
three bytes of data are in the mouse buffer. If not, it
exits immediately and the next IN-TOKEN on EP3 will be NACKED.
The reason for this is that the mouse reports come in three byte
packets from the mouse and the MOUSE_REPORT_GENERATOR code
assumes that this is the case. As can be seen in the handling
of the stored mouse buffer data, it is crucial that three bytes
are in the mouse buffer before calling the report generation
code.
B. When called from the MOUSE_ISR code, the code already knows that
there is no previous data in the buffer and that there are three
bytes ready to be written to TXFIFO3. For this reason, it enters
at "MOUSE_REPORT_GENERATOR". This is done to initiate data flow
to the host after a period of no data transmission from the mouse.
Once the "MOUSE_REPORT_GENERATOR" section is entered, FIFO
vacancy is checked and if none exists, the code exits the function.
If a vacancy exists, the first mouse report byte is read into R0.
To facilitate understanding of this part of the code, the data
format of the mouse reports will be given. This is how the mouse
data is received and how it is stored in the buffer:
BYTE 1:
bit 7 => always "1"
bit 6 => always "1" (This is the report alignment bit. )
(It is ALWAYS "1" in the first byte)
(and ALWAYS "0" in the second and )
(third bytes. )
bit 5 => Left Mouse Button ("1" = down, "0" up)
bit 4 => Right Mouse Button
bit 3 => Y7 (8th bit of the relative Y movement)
bit 2 => Y6 (7th bit of the relative Y movement)
bit 1 => X7 (8th bit of the relative X movement)
bit 0 => X6 (7th bit of the relative X movement)
NOTE - The X & Y position bytes are 8-bit, two's-
complement values.
BYTE 2:
bit 7 => always "1"
bit 6 => always "0"
bit 5 => X5 (6th bit of the relative X movement)
bit 4 => X4 (5th bit of the relative X movement)
bit 3 => X3 (4th bit of the relative X movement)
bit 2 => X2 (3rd bit of the relative X movement)
bit 1 => X1 (2nd bit of the relative X movement)
bit 0 => X0 (1st bit of the relative X movement)
BYTE 3:
bit 7 => always "1"
bit 6 => always "0"
bit 5 => Y5 (6th bit of the relative Y movement)
bit 4 => Y4 (5th bit of the relative Y movement)
bit 3 => Y3 (4th bit of the relative Y movement)
bit 2 => Y2 (3rd bit of the relative Y movement)
bit 1 => Y1 (2nd bit of the relative Y movement)
bit 0 => Y0 (1st bit of the relative Y movement)
Following the code is easy once the format is known so a detailed
explanation will not be given. Basically, the code looks for bit
6 to be set and, if it is, the read offset variable is updated
and three is subtracted from the "MOUSE_DATA_COUNT" variable.
Function "PUT_REPORT_IN_FIFO" is then called which manipulates
the mouse report bytes one by one to get the following report
format written to TXFIFO3:
BYTE 1:
Always 02 hex. This is the Report ID byte.
BYTE 2:
The button values: 00 = no buttons pressed
01 = Right button down
02 = Left button down
03 = both buttons down
BYTE 3:
8-bit, two's complement X displacement value
BYTE 4:
8-bit, two's complement Y displacement value
One final note - The HID Class BOOT PROTOCOL is not handled in this code.
The "SET PROTOCOL" and "GET PROTOCOL" host requests are handled and
they effect the value of the "USB_PROTOCOL" variable, but nothing else was
done with this. Also, the "GET IDLE" and "SET IDLE" commands are not
supported for the mouse. Due to the nature of the mouse reports (only
reporting when data is available) it is practically always in the INDEFINITE
IDLE mode. Only TIMED IDLE considerations would have to be added.
** HARDWARE NOTES **
A USBM evaluation board was used which had an 82930-A3 processor
on it. The code will need to be modified if an AA processor is used.
As stated earlier, a PLC Compass 251 IDE development tool was used
to develop all code. The following considerations need to be made for
the keyboard and mouse:
KEYBOARD -
1. The keyboard CLOCK line must be connected to pin 50 (P3.3) of
the 50-pin header.
2. The keyboard DATA line must be connected to pin 43 (P3.4) of
the 50-pin header.
NOTE - the following is the pin-out of a standard 6-pin mini-DIN
PS/2 connector described as looking into the end of the
keyboard cable:
Starting at the top left side pin and moving CCW around
the connector -
CLOCK, Ground, DATA, N/C, +5V, N/C
3. The following jumpers need to be set accordingly:
JW24 => INT0
JW22 => removed
JW5 => removed
MOUSE -
1. The mouse must use the standard serial port on the eval board.
This means that any debugger must use the external UART port.
To use this, the UARTC DIP switch will need to be turned on.
Also, the following modifications need to be made to the
standard serial port for the mouse:
A. Cut the trace going from pin 1 to the via
B. Cut the trace going from pin 7 to pin 8
C. Cut the trace going from pin 4 to pin 6
D. Connect pin 4 to pin 7 and both of these to +5V
(The easiest place to get +5V is on the two-pronged)
(power connector near the serial port. )
E. Cut the trace from pin 3 to pin 4 of U8 (the MAX233 chip)
F. Connect pin 3 (of the serial port) direct to pin 44 of
the 50-pin header (P3.0 - Data RX).
Also, a null modem cable serial cable must be used (with pins
2 & 3 swapped).
**************** NOTE ************************
If only keyboard operation is required, still use ALL of the
files in the project but simply do not make the serial port
modifications and do not connect a mouse.
***************************************************
OTHER ISSUES:
When switching the DEBUG mode (Linker = IEE695 format) to the EPROM
burning mode (Linker = Intel Hex 16 format) the following changes have
to be made:
in "LITE_FRM.ASM" -
1. Change the value of "USE_RISM" from 1 to 0
2. Comment out the "CODE_SEGMENT" Define statement that
has an ORG of 004080 and remove the comment symbol
from the lines of code that specify an ORG of FF0080
in "KBD_ISR.ASM" -
1. Comment out the "KBDISR_VECTOR" Define statement that
has an ORG of 004013 and remove the comment symbol
from the lines of code that specify an ORG of FF0013
in "MOUSEISR.ASM" -
1. Comment out the "MOUSE_ISR_VECTOR" Define statement that
has an ORG of 004023 and remove the comment symbol
from the lines of code that specify an ORG of FF0023
in "DONGMAIN.ASM" -
1. Comment out the "TIMER0_ISR_VECTOR" Define statement that
has an ORG of 00400B and remove the comment symbol
from the lines of code that specify an ORG of FF000B
Then, in "Configure - Linker" change the "Executable Format" field
from "IEE695" to "Intel Hex16 - Records".
And the "Configure Target" memory allocation values should be set as
follows:
DATA : 40-200 (same for DEBUG mode)
EDATA: 500-3FFF (same for DEBUG mode)
CODE : FF0000-FF7FFF (for 32K FLASH )
(from 004000-00FFFF for DEBUG)
Vector Address: FF0000 (from 004000 for DEBUG)
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -