Raspberry Pi Computer Lab: Lesson 10 Input 01

This is the first input lesson, which will teach some theories about drivers and linking, as well as knowledge about keyboards, and will end with displaying text on the screen.

1. Start

Hope you have completed the OK series courses; this will help you complete the screen series course. Many files from the OK course will be used without explanation. If you don’t have these files or want to use a correct implementation, you can download the template from the download page[1] of this lesson. If you are using your own implementation, please delete all code after calling SetGraphicsAddress.

2. USB

As you know, the Raspberry Pi B model has two USB ports, usually used to connect a mouse and a keyboard. This is a very good design decision; USB is a very versatile interface, and many devices can use it. It is easy to design new peripherals for it, easy to write device drivers for it, and it can be easily expanded through USB hubs. Can it get any better? Of course not; in fact, for an operating system developer, this is our nightmare. The USB standard is too large. I mean, really, before you think about how to connect devices, its documentation is nearly 700 pages.

The design goal of the USB standard is to simplify hardware interaction through complex software.

I have talked to many hobbyist operating system developers about this, and they all said a few things: don’t complain. “Implementing this takes a long time,” “You can’t write a tutorial about USB,” “The return is too small.” In many ways, they are right; I cannot write a tutorial about the USB standard; that would take weeks. I also can’t teach how to write device drivers for all devices, so using self-written drivers is of no use. However, even if I can’t do it best, I can still get a normally working USB driver, take a keyboard driver, and teach how to use them in the operating system. I started looking for free drivers that could run on an operating system that doesn’t even know what a file is, but I couldn’t find any; they were all too high-level, so I tried to write one. Everyone was right; it took me weeks. However, I can happily say that the work I did did not get help outside the operating system and could communicate with the mouse and keyboard. This is by no means complete, efficient, or correct, but it works. The driver is written in C, and those interested can find all the source code on the download page.

So, this tutorial will not be a course on the USB standard (not at all). In fact, we will look at how to use other people’s code.

3. Linking

Since we are going to introduce external code into the operating system, we need to talk about linkinglinking. Linking is a process that links functions in a program or operating system. This means that when a program is generated, we do not need to write every function (almost certainly, it is not). Linking is what we do to connect our program with functions in others’ code. This has already been done in our operating system because the linker links all different files together, each compiled separately.

Linking allows us to create reusable code libraries that everyone can use in their programs.

There are two ways to link: static and dynamic. Static linking is what we do when making our own operating system. The linker finds the addresses of all functions and writes those addresses into the code before the linking ends. Dynamic linking occurs after the program is “complete.” When the program loads, the dynamic linker checks the program and finds all functions not in the program in the operating system’s library. This is something our operating system should ultimately be able to accomplish, but for now, everything will be statically linked.

Programs often call libraries that call other libraries until they eventually call the libraries of our written operating system.

The USB driver I wrote is suitable for static compilation. This means that what I give you is the compiled code for each file, and then the linker finds those unimplemented functions in your code and links them to mine. On the download page[1] of this lesson is a makefile and my USB driver, which is needed next. Download and use this makefile to replace the makefile in your code, and place the driver in the same folder as this makefile.

4. Keyboard

To pass input to our operating system, we need to understand how keyboards actually work to some extent. Keyboards have two types of keys: regular keys and modifier keys. Regular keys are letters, numbers, function keys, etc. They make up almost all keys on the keyboard. Modifier keys are special keys, up to 8. They are left shift, right shift, left ctrl, right ctrl, left alt, right alt, left GUI, and right GUI. The keyboard can detect which modifier key is pressed in all combinations, as well as up to 6 regular keys. Each time a button changes (for example, pressed or released), the keyboard reports it to the computer. Usually, the keyboard also has 3 LED lights indicating caps lock, num lock, and scroll lock, which are controlled by the computer, not the keyboard. The keyboard may also have more lights, such as power, mute, etc.

For standard USB keyboards, there is a key value table, where each keyboard key has a unique number, and each possible LED is similar. The table below lists the first 126 values.

Table 4.1 USB Keyboard Values