Chieroth
Device Driver Development
Contents hide
Motivation
Project Vision
Chieroth is a project for a course named Device Drivers Development on Linux. The purpose is to implement a device driver for an embedded Linux development board (the Atmel ATNGW100 Linux Board), according to the requirements given by the teacher. The team members and the responsibilities for this project are shown in table 1.
| Member | Responsibility |
|---|---|
| Todor Vlaev | Project Manager, Hardware Specialist |
| Claudio M. Camacho | System Administrator, Software Architect |
| Michal Paszta | Hardware Assistant, Developer, Documenter |
Requirements Specification
Initially, the project was set by a group of basic requirements given by the teacher. These requirements would condition the project in its development, and certain features of the Linux kernel should be used. The main features to be used in the development of this project had to include:
- use of a timer: pulse counter
- use of interrupts: capturing internal and/or external interrupts
- parallel I/O: monitoring buttons and controlling LEDs seamlessly
In order to achieve a development status in which all requirements would be accomplished, the team decided to specify a self-made device, which would contain those features. The self-made device is a simple printed circuits board (PCB) with various LEDs, some buttons, and other expansion features (such as a temperature and pressure sensor, for future additions). Figure 1 shows an overview of the chieroth device, a simple printed board for educational purposes.
Figure 1 depicts the basic functionalities of the chieroth device, which include, among others:
- binary clock
- frequency meter
- on/off button
- mode switch button
Accordingly, the binary clock mode shows the current time in binary format on the LEDs, where the first row represents the hours and the bottom bar represents the minutes. Moreover, the frequency meter mode measures the amount of frequency on a certain input. This is used in combination with a signal generator. When the signal generator is connected to the right pin on the Atmel ATNGW100 Linux Board, the device driver measures the input frequency and the chieroth device can represent such information as a progress bar in the LEDs' bars.
The buttons provide further functionality, as the user may want to change the mode (e.g. from binary clock representation to frequency meter). The on/off button switches the whole device ON or OFF. When the device is ON, all data structures are loaded in memory (by the driver), including a /proc file entry, registered interrupts, timers enabled, etcetera. On the other hand, when the device is switched OFF, the data structures are cleaned up from the kernel memory and all the interrupts (including the timer) are disabled, in order to consume less resources.
Environment
For the development process, the environment was chosen to be the Atmel ATNGW100 Linux Board, which introduced certain limitations when creating the device driver, but certainly covered the team's ultimate goal: to learn more about embedded Linux environments and driver development on them. In figure 2 there is a representation of the overall view of the Atmel ATNGW100 Linux Board.
Following this project's scope, the most important characteristics to depict out of figure 2 are:
- AVR32 processor
- 32MB SDRAM
- 8MB flash
- SD expansion card
- general expansion ports (J5, J6 and J7)
- RS232 (serial port), used for serial communication
- Ethernet port, used for network communication
The Atmel ATNGW100 Linux Board ships with an embedded Linux distribution which runs a 2.6 kernel and offers many connectivity possibilities, such as NFS, Samba, SSH, etcetera. The Linux support is wide, since different file systems are supported, and many technologies are enabled by default: such as ALSA, a generic LED API, a generic GPIO API, etcetera. Moreover, the most interesting point is that this Linux distribution that ships with the Atmel ATNGW100 Linux Board can be "easily" upgraded, thus allowing developers and users to place their own distributions or any newer version of the kernel.
The Atmel ATNGW100 Linux Board was used as the host computer where the chieroth device was attached. However, the development was carried out on another computer, using cross-compiling tools and a more sophisticated infrastructure.
Device Driver Development
Development Environment
The development environment chosen for this project was a Debian GNU/Linux distribution running on a workstation, where all the coding was carried out. Furthermore, the Atmel ATNGW100 Linux Board was doubly connected to the development workstation, both through RS232 (serial connection using minicom) and through the Ethernet port (for uploading files to the board). In consequence to the development on the workstation, the official AVR cross-compiling toolchain was used, in order to generate AVR32 objects that could be loaded and run on the Atmel ATNGW100 Linux Board. The serial connection was used in combination with the program minicom, used as another terminal for issuing commands and visualizing the status of the system on the Atmel ATNGW100 Linux Board.
For the team communication, the project members used, mainly, Google Groups, as it was familiar to every member in the team. Moreover, regular meetings were held on weekly basis, and the pace of development was agreed by every member before the end of each meeting. As about the control version of the driver source code, the team decided to use a simplified model (using a shell script), since there was only one file in which the whole driver was included.
Driver Design
The design of the driver meets three basic requirements, which were set in the requirements specification of the project, at the beginning of the development cycle. The driver implements the binary clock functionality and the frequency meter functionality, and both are coordinated with a global driver architecture made of signal handlers that are asynchronously called when an event takes place and the kernel notices it. Please consider figure 3 in order to see the organization of the driver, at a glance.
From figure 3, it is noticeable that the chieroth device driver is divided in two main streams or sources of interrupts. In fact, the whole driver is fully driven by interrupt handlers. At first, the driver is loaded and the interrupt handlers are installed, then the driver stops doing anything. Within its lifetime, interrupts may arrive (and, in fact, they do) and hence the interrupts handlers treat those interrupts as the kernel notifies them.
First, there are two timers providing interrupts. One is a constant counter that provides an interrupt every 500ms. This is an interrupt used for updating the status of the LEDs on the chieroth device, both for the binary clock and the frequency meter monitor. The other interrupt source, registered at CH0, is the signal associated with a pin, where a signal generator is supposed to be attached. If no signal generator is attached to that pin, then there will be no interrupts coming from that source.
Second, there are the GPIO interrupts, which are provided through the push buttons installed on the chieroth device. These interrupts are generated on the rising-edge, when a button is being pushed (or unpressed). Admittedly, when the switch button is pushed, the driver changes the mode from one to another and updates certain data in the driver information. Similarly, when the on/off button is pressed, the device is fully switched ON of OFF, thus enabling or disabling all the necessary resources. For further details, please download the source code of the driver from the link below:
Discussion
Future Ideas
TBD
Issues and Experience
TBD
Conclusions
References
Chieroth [online]. Todor Vlaev, Michal Paszta and Claudio M. Camacho; Google
Groups.
URL: http://groups.google.com/group/Chieroth
Accessed 7th June 2009