4
We recommend that you make use of MTCP
BIOC ON and MTCP LED SET, in which case you must handle MTCP ACK
and MTCP BIOC EVENT. You must also handle MTCP RESET packets sent to the computer by attempting to restore the
controller state (value displayed on LEDs, button interrupt generation, etc.).
MTCP
POLL This command consists of a single MTCP POLL byte (0xC2) sent to the controller: The response is a
three-byte packet with the following format:
1
1
0 1 0 00 0 1 0
X X
X
C A
L
B
UDR
X
X X
S
7 0
1
2
0
That is, the first byte will have the value MTCP POLL OK, the second and third will contain active-low
bit masks of which buttons are pressed; that is, a bit will be ‘0’ when the corresponding button is
pressed. The C, B, A, and START (S) buttons are in the second byte, and the right (R), down (D),
left (L), and up (U) bits are in the third. Bits marked as ‘X’ in the diagram are unused.
MTCP
LED SET See mtcp.h for the definition of the LED SET bytes
Finally, a few important notes about the Tux controller:
For debugging purposes, when the controller receives an erroneous command, it locks up and displays 00P5 on the
seven-segment display. Pressing the reset button returns it to a usable state. This behavior can be disabled by sending
an MTCP
DBG OFF command; after this is sent, an erroneous command will elicit an MTCP ERROR response.
Additionally, when the controller is reset, for example by pressing the reset button, it asynchronously sends an
MTCP
RESET packet to the PC. Your code must detect this condition and re-initialize the controller to the same
state it was in before the reset. In order to accomplish this your code must internally keep track of the state of the
device.
Debugging the Tux Controller:
Debugging in kernel space is not as simple as debugging in user space. You made find it helpful to use printk()
from your driver module. printk() is like printf() for kernel mode.
When the kernel loads the tuxctl module, it may load it anywhere it pleases in its address space. This means GDB
needs to know where the module was loaded before it can start debugging it. The object file for the tuxctl also needs
to be loaded into GDB so that the proper symbols can be resolved.
Once your debug machine loads, load the tuxctl module (see above). You now need to find out where in memory the
kernel loaded the module. Issue the command cat /proc/modules to print out the location of all modules currently
loaded in the kernel. You should see a line such as
tuxctl 6792 0 - Live 0xd0813000 (P)
at the top. 0xd0813000 is the address the module was loaded at. (It will probably be different for you). Back in
your devel machine, in the module directory, launch gdb with no arguments. Once in GDB, type add-symbol-file
./tuxctl.o ADDRESS where ADDRESS is the address that was printed out in for the module in your debug machine,
0xd0813000 in my case. GDB will then ask you to confirm. Type y and hit enter. Now you will need to connect
GDB to the remote machine by typing target remote 10.0.2.2:1234. You may now define breakpoints for your
driver and continue as normal.
Again, make use of the stand-alone input program in input.c before tackling the full game.
Manymanuals.com
Manymanuals.de
Manymanuals.fr
Manymanuals.it
Manymanuals.pl
Manymanuals.cz
Manymanuals.es
Manymanuals-pt.com
Comentários a estes Manuais