3
control completely as a stand alone program should you try it with the full game. To interface with the game you will
need to create a new thread to take input from the Tux controller (you must support keyboard input simultaneously.
Opening the Tux controller is fairly simple. You may use the following code as an example to open the serial port and
set the Tux controller line discipline:
fd = open("/dev/ttyS0", O RDWR | O NOCTTY);
int ldsic num = N MOUSE;
ioctl(fd, TIOCSETD, &ldisc num);
This code simply opens the tty port and sets the line discipline. You will want to add some error checking and whatever
else you see fit to make this work with your code.
What Your Driver Has To Do:
Your device driver transforms the protocol supported by the Tux controller into a simpler abstraction for use by user-
level programs such as the game. You must implement the following ioctls for your device abstraction:
TUX
INIT Takes no arguments. Initializes any variables associated with the driver and returns 0. Assume that
any user-level code that interacts with your device will call this ioctl before any others.
TUX
SET LED The argument is a 32-bit integer of the following form: The low 16-bits specify a number whose
hexadecimal value is to be displayed on the 7-segment displays. The low 4 bits of the third byte
specifies which LED’s should be turned on. The low 4 bits of the highest byte (bits 27:24) specify
whether the corresponding decimal points should be turned on. This ioctl should return 0.
TUX
BUTTONS Takes a pointer to a 32-bit integer. Returns -EINVAL error if this pointer is not valid. Otherwise,
sets the bits of the low byte corresponding to the currently pressed buttons, as shown:
startright left up a
07
bcdown
For full credit, use an interrupt-driven approach rather than polling.
Your changes to the device driver should be limited to the files tuxctl-ioctl.h and tuxctl-ioctl.c. The func-
tion tuxctl
handle packet handles all packets received by the computer from the Tux controller. The function
tuxctl ioctl handles calls from user code (the game) to ioctl. You may add more ioctl calls, however the
required ioctls above must work as intended.
Tux Controller communication protocol:
The Tux controller protocol for interacting with the PC is described in mtcp.h, as you saw in PS2. Messages sent to
the Tux controller are of variable length, while messages sent to the computer are always three bytes in length of the
following general form:
Responses from the controller to the PC are always sent as three-byte packets of the following general form:
1
1
0 1 0R4 R3 R2 R1 R0
7 data bits
7 data bits
07
1
2
0
The 5-bit vector R[4:0] in byte 0 represents an opcode. All possible opcodes are defined in mtcp.h The other three
bits in byte zero are fixed as indicated. Notice that bit 7 of each byte is fixed and used to frame the packets. This is a
feature of the packet format because the COM port emulation in the old Microsoft Virtual PC software that we used to
use was unreliable and occasionally lost bytes sent through it. The provided kernel patch includes code to detect this
behavior and avoids providing you with broken packets. See the code in tuxctl-ld.c for details.
The Tux controller supports many different commands, each of which is defined in mtcp.h. You are only required to
use a couple of them for this MP.
Manymanuals.com
Manymanuals.de
Manymanuals.fr
Manymanuals.it
Manymanuals.pl
Manymanuals.cz
Manymanuals.es
Manymanuals-pt.com
Comentários a estes Manuais