Checkpoint LAB USB-RS232 Bedienungsanleitung PDF herunterladen (Seite 2)

5. When you ﬁrst start your debug machine, a dialog will appear asking you for COM# Properties. The default

values (Bits per second should be = 9600, Data bits = 8, Parity = None, Stop bits = 1, Flow control = None) will

be correct. Click OK to continue booting your debug machine.

6. If there is no activity for approximately 2 hours, the Tux controllers will enter a low-power state and turn off the

LEDs. This is intended to prolong the life of the LEDs. Pressing the RESET button will return it to a responsive

state. Be aware of this if you sit down at a new machine or do not use the controller for more than two hours.

7. There is a bug in QEMU that may cause the test machine to freeze occasionally while using the Tux controllers.

When it is frozen, you will be unable to connect to or interact with it from GDB. If that happens, go to the

QEMU console (ctrl+alt+2), type i 0x3f8 (this will pull bytes from UART like in), press the up arrow to get

the command again and repeatedly enter it several times. Go back to the virtual terminal you were in (ctrl+alt+1).

If it is still locked, repeat the steps above until it becomes responsive.

Building the Driver:

The mp2/module directory contains a framework for the driver you will be implementing for the Tux controller. A

module is similar to a dynamically-loaded user-level library but instead of being used by an application it is used by

the kernel to extend functionality. Modules allow for drivers to be loaded without having to recompile (or even reboot)

the whole kernel. This simpliﬁes the process of debugging as well. Modules can also be unloaded and a new version

loaded into the kernel assuming that nothing catastrophic happened that would crash the kernel. Your driver code, of

course, is running in the kernel, and bugs that are severe enough to crash the kernel are not impossible to produce.

The module directory uses a separate Makeﬁle to compile a device driver module for use with Tux controller, thus

building a module is similar to building a user level program: Change directories into the module directory and type

make.

To load the module into the kernel, type sudo /sbin/insmod ./tuxctl.ko while in the module directory. A line

should print out saying the tuxctl line discipline has been registered. You can safely ignore the “module license

‘unspecified’ taints the kernel” message.

If you want to remove the module, issue the sudo /sbin/rmmod tuxctl command. This removes the module

from kernel space and should print a line stating the tuxctl line discipline was removed. You can use these commands

to install and remove the kernel module repeatedly during your development. If your module corrupts the kernel,

however, you may eventually crash the system and have to reboot. If all else fails, try rebooting the test machine and

then loading your module to see if it is really your latest code that is failing.

The module we have given you implements a tty line discipline. A line discipline is a driver that receives commands

from the tty or serial port driver. In other words, it acts as a middle man between the serial port and the code you

will implement to actually interpret the Tux controller commands. The code you will be implementing is in the

tuxctl-ioctl.c ﬁle. You may add anything you deem necessary to the header ﬁles to make your implementation

work. We also recommend you look at the mtcp.h ﬁle for a description of how the Tux controller works and some

predeﬁned constants, and at the appendix at the end of this document.

Writing Your Driver:

You will write portions of both the device driver which communicates with the Tux controller and the user-level

application code to make use of the driver. On the driver side, you will need to add constants and deﬁnitions for

the abstracted bit format to the header ﬁle. These constants (located in tuxctl-ioctl.h) will shared by the kernel and

user-level code, ensuring that no inconsistencies arise. There is no user-level test harness for MP2. We advise you to

write a simple test program to test your driver outside the game. We suggest that you write a test program to test the

basic functionality (open, close, ioctls) before trying to make the game use the driver. We have provided input.c as

a starting point for your user-level testing. To compile input.c type make input. We will test your driver with our

own testing code, so be sure to test your driver’s functionality thoroughly and adhering strictly to the spec. For the

checkpoint, you must add the Tux controller functions (open, ioctls, close) to the input control in input.c and test it

by compiling the ﬁle by itself. You will need to include tuxctl-ioctl.h. Only once you have debugged your input

This simply indicates that the module you have loaded has not been designated as GPL and therefore taints the kernel so don’t try to submit

any bug reports to Linus.

1 2 3 4

Kommentare zu diesen Handbüchern

Keine Kommentare

Checkpoint LAB USB-RS232 Bedienungsanleitung Seite 2

Kommentare zu diesen Handbüchern