University of Twente

EEMCS / Electrical Engineering

Control Engineering

Redesign of the Linux driver for

the Mesa Anything I/O cards

Jeffry Molanus

Pre-doctoral assignment

Supervisors:
prof.dr.ir. J. van Amerongen
dr.ir. J.F. Broenink
ir. M.A. Groothuis

October 2007

Report nr. 023CE2007

Control Engineering
EE-Math-CS
University of Twente
P.O.Box 217
7500 AE Enschede
The Netherlands
Redesign of the Linux driver for the Mesa Anything I/O cards.

Jeffry Molanus, 2007

Summary
The Control Engineering laboratory of the University Twente develops, among others, software
to build control systems. There are a variety of target platforms used with different sets of pe-
ripherals. One of the target platforms is the PC104/plus which optionally can be equipped with
a Mesa Electronics Anything I/O card. There are different versions of the cards available at the
control laboratory, the Anything I/O 4I65, 5I20 and the 4I68. The latter had no Linux driver
available. The other two cards, 4I65 and 5I20 are both supported by two different drivers. Each
individual driver has its advantage however, both drivers lack the support of memory mapped
I/O.

This report contains the results of the investigation to the relevant hardware differences as
well as software differences. Based up on these results, and certain requirements a new driver
is written since updating the existing drivers will cost just as much, or maybe more effort then
writing a new one. Besides the effort involved the control laboratory wishes to have just one
driver that supports all of these cards on the latest stable kernel version. Since the 4I68 card
has some relevant differences regarding resources, internal data structures of both old drivers
have to be changed, justifying the rewriting even more.

As a test, the newly developed driver replaced one of the old drivers in a working control
setup; the Paper Path. The card is tested for any abnormal behaviour. The new card, the 4I68
is also tested in conjunction with the 4I65 card to test if the new card works, and to see if having
multiple different cards works as well.

The recommendation is to remove the control logic off the driver from kernel space and to
use user space I/O. This will enable a tighter integration with for instance, the 4C tool chain
and improve performance of the Anything I/O card.

Jeffry Molanus, September 25, 2007

Samenvatting
De Control Engineering groep van de Universiteit Twente ontwikkeld, onder anderen, software
om regel systemen te bouwen. Er zijn verschillende soorten doel platformen met verschillende
periferie. Een van deze doel platformen is de PC104/plus die optioneel is uitgerust met een
Mesa Electronics Anything I/O kaart.

Er zijn verschillende versies van de kaart beschikbaar bij de control vakgroep, de Anything
I/O 4I65, 5I20 en de 4I68. Voor laatst genoemde is geen Linux driver beschikbaar. De andere 2
kaarten, de 4I65 en de 5I20 worden ondersteund door twee verschillende drivers. Elke individu-
ele driver heeft zo zijn voordelen maar beiden drivers hebben geen ondersteuning voor memory
mapped I/O.

In dit verslag staan de resultaten van het onderzoek naar de relevante hardware verschillen
als mede naar de software verschillen. Op basis van deze resultaten en bepaalde vereisten is er
een nieuwe driver geschreven omdat het updaten van de bestaande drivers net zoveel of miss-
chien wel meer in spanning vergt dan het schrijven van een nieuwe. Naast de in spanning die er
mee gepaard gaat, wenst de control groep één driver die alle kaarten ondersteund op de nieuwste
stabiele kernel versie. Omdat de 4I68 relevante verschillen heeft met betrekking tot de gebruikte
bronnen, moeten de interne data structuren van beide drivers worden aangepast die het her-
schrijven nog meer rechtvaardigen.

Als een test, wordt de nieuw ontwikkelde driver vervangen voor de oude driver in een werk-
ende opstelling; De Paper Path. De kaart is getest op vertoon van abnormaal gedrag. De nieuwe
kaart, the 4I68 is ook getest is samenwerking met de 4I65 kaart, om zo te testen of de nieuwe
kaart werkt, en om te kijken of het hebben van meerdere en verschillende kaarten in één op-
stelling ook werkt.

De aanbeveling is om de controle logica van de driver uit kernel space te verwijderen en user space
I/O te gebruiken. Dit maakt het mogelijk om betere intergratie te krijgen met, bijvoorbeeld de
4C tool chain en om prestatie verbeteringen te verkrijgen.

Control Engineering Jeffry Molanus, September 25, 2007 iii

Contents

1 Introduction 1
1.1 Approach of the project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Report outline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Mesa Electronics Anything I/O Cards 3

2.1 Card types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2 Relevant Hardware differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.3 Relevant software differences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.4 Design requirements and improvements . . . . . . . . . . . . . . . . . . . . . . . 5
2.5 Strategy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 The Linux kernel and Linux drivers 7

3.1 User and Kernel space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 The ioctl() system call . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3 Memory mapped I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

4 The new Anything I/O driver 10

4.1 Generic structure of the driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2 Anyio user space library . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

5 Testing the driver 13

5.1 Loading the driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2 Programming the Anything I/O cards . . . . . . . . . . . . . . . . . . . . . . . . 14
5.3 Using the driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

6 Conclusions 16
6.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.2 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

A Template Changes 17
A.1 Function changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
A.2 Initialising the card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
A.3 The registers structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Bibliography 19

Jeffry Molanus, September 25, 2007

1 Introduction
The Control engineering laboratory of the University Twente uses several different modeling
tools like 20-sim and gCSP to develop control software. These control applications are deployed
making use of the target connector (Posthumus, 2007) which is part of the 4C tool chain (Visser
et al. 2006). One of these target platforms is the PC/104 platform. This platform is optionally
equipped with a Mesa Electronics Anything I/O card (Groothuis, 2004). The Anything I/O
card is build around a FPGA. The FPGA can be programmed accordingly giving it a true
Anything I/O nature. There are three different versions of the card all being used at the
Control engineering laboratory namely, the Anything I/O 4I65, the 4I68 and the 5I20.
These cards are used in a variety of control setups for instance in the JIWY, the viewCorrect
plotter (Sprik and van Kuppenveld, 2006) and the paper path setup (Otto, 2005). It is used as
an output module and for sensor and signal processing. In figure 1.1 a possible setup is depicted.
A workstation is used to develop and simulate the control logic. HandelC (Van Zuijlen, 2007)
or VHDL is used to develop the desired FPGA configuration. Finally controller software with
aid of, for instance 20-sim, can be generated and executed on the PC/104.

Figure 1.1: Example of the Anything I/O card in a real setup (JIWY)

1.1 Approach of the project

In order to use the Anything I/O card with Linux (as well with Windows), a driver or more
precise a kernel module is needed to gain access to the required I/O and control registers of the
FPGA. Currently there are two Linux drivers and one Windows driver available for two versions
of the Anything I/O card, namely the 5I20 and the 4I65. This project will focus only on the
Linux drivers. One driver is developed by Marcel Groothuis called the anyio old (Groothuis,
2004) driver, and one is developed by Eric Buit which has the name anyio proc(Buit, 2005).
Both drivers provide the developer of the control system with an interface to program the FPGA,
to retrieve status information about the FPGA and to control the I/O ports defined in the FPGA
configuration. Both drivers provide the developer of the control system with an library which
implements the basic functions, while the anyio proc driver is also bundled with two different
tools to program (pany) and reset (rany) the FPGA.

Control Engineering Jeffry Molanus, September 25, 2007 1

2 Anything IO drivers

The goal of this project is to compare both drivers and determine their best features, and merge
these features in to one of the existing drivers or maybe to write a new Linux driver from scratch.
Furthermore support must be added for the 4I68 Anything I/O card.

1.2 Report outline

In Chapter 2, a comparison between the different drivers and Anything I/O cards will is made.
Chapter 3 discusses the manner how the Linux kernel communicates with the hardware, and
gives an overview on how the kernel does I/O operations on the hardware.
Chapter 4 motivates design choices that are made based upon the comparisons made in Chapter
2. In Chapter 5, usage and testing of the driver is explained, and conclusions and recommenda-
tions can be found in Chapter 6.

Jeffry Molanus, September 25, 2007 University of Twente

2 Mesa Electronics Anything I/O Cards
This chapter focuses on most relevant hard- and software differences of the Anything I/O cards.
In section 2.4, several design choices will be made based upon this comparison.

2.1 Card types

There are three different types of cards used by the control engineering laboratory. In order to
make a good comparison an overview of the relevant components the cards consist of is given.

Type 4I65 4I58 5I20

FPGA 200K Spartan2 200 or 400K Spartan3 200k Spartan2
Bus PC/104-plus bus PC/104-plus bus Normal PCI bus
PLX PLX 9030 PLX 9054 PLX 9030
I/O 72 I/0 bits 72 I/0 bits 72 I/0 bits
LEDs 8 programmable LEDs 3 programmable LEDs 8 programmable LEDs
Vout 5v 3.3v, 5v input tolerant 5v

Table 2.1: Hardware overview of the various cards

Figure 2.1: Overview of the Anything I/O 4I65 en 5I20 card (Groothuis, 2004)

When looking in table 2.1 the most relevant difference is the PLX chip used on the 4I68, in
comparison to the PLX used on the 4I65 and the 5I20 it has some power management capabilities.
Also the 4I68 has less LEDs available for programming. Since the 4I68 uses a different type of
FPGA in comparison with the two other boards the voltage level is lower. The 5I20 uses the
normal PCI bus, and has a different form factor. This however does not make any difference
for its functionality nor does it require any extra measures for the Linux driver. The pin out
of the cards differ all together. Please refer to the PIN files provided by Mesa Electronics. The
interconnect of the buses are depicted in figure 2.1.

Control Engineering Jeffry Molanus, September 25, 2007 3

4 Anything IO drivers

2.2 Relevant Hardware differences

The PLX chip used on all the boards are used to connect the PCI bus to the local bus, see
figure 2.2. On this local bus different peripherals can be connected. In this specific case, the
local bus side of the PLX chip is connected to a FPGA of the types listed in table 2.1 on page
3. A PCI device has one or more BARs (Base Address Registers), which are used to set or find
the resources the devices uses. The relevant difference for the different type of boards is how
these BARs are configured. Each PLX PCI BAR is configured to the Mesa default configuration
during power on. Since the PLX chip on the 4I68 is different, the BAR configuration is different
as well. Between these BARs one other type of classification can be found, one set of bars is
used for the configuration of the PLX itself and manipulating configuration register bits of the
FPGA, and one set of BARs is used to manipulate the input/output pins of the FPGA and the
programmable LEDs.

Figure 2.2: PLX - PCI bridge interface chip

The PLX PCI bridge local configuration registers can be accessed via I/O or memory.

Barnr. 4I65/5I20 4I68

BAR0 Memory 32 bits, 128 bytes Memory 32 bits, 128 bytes
BAR1 I/O 32 bits 128 bytes I/O 32 bits 128 bytes

Table 2.2: Default PLX settings for PLX configuration and FPGA control register manipulation

The PLX PCI bridge allows for separate memory and I/O regions to be mapped to the local
bus that connects to the FPGA.

Jeffry Molanus, September 25, 2007 University of Twente

2. Mesa Electronics Anything I/O Cards 5

Barnr. 4I65/5I20 4I68

BAR2 I/O 16 bits, 256 byte I/0 32 bits 256 byte
BAR3 I/O 32 bits, 256 byte Memory 32 bits. 64Kb
BAR4 Memory 16 bits, 64Kb none
BAR5 Memory 32 bits, 64Kb none

Table 2.3: Default PLX settings for input/output manipulation

Through these BARs the driver has provide the application developer full control over all FPGA
registers. Another relevant difference is that the 4I68 cannot be reseted by means of software.
The reason for this is that there are only 2 I/O pins available for controlling the programming
procedure of the FPGA. This leads to a requirement for resetting the FPGA by means of soft-
ware, namely that the DISABLECONF pin is set to float in the FPGA configuration. However,
a design error was made during the development of the 468I board by Mesa, the wrong resistor
values where used on the board which leads to not being able to reset the board by any means
of software regardless of the DISABLECONF state.

2.3 Relevant software differences

The anyio old driver developed by Marcel Groothuis has the advantage that it does not need
separate tools to program the FPGA. Since the Anything I/O boards are used in an embedded
environment, doing more with less is the preferred approach. Furthermore the anyio old and
anyio proc drivers are incapable of doing memory mapped I/O. Due to architectural limitations,
I/O addresses outside the 256 boundary cannot be accessed by any of the drivers.
Both drivers are developed using the Linux 2.4.x kernel version. Currently Linux 2.6.20 is
released. During the development of the 2.6 kernel several function calls to detect and register
the card to the kernel have been changed. The new driver should make use of the new functions
since the old functions calls will become deprecated, and thus in time will render the drivers
useless on newer kernel versions.

2.4 Design requirements and improvements

Based upon the previous section, several design requirements are defined.
• Support for Memory mapped I/O

Since the architecture used with the Anything I/O cards is x86 based, reaching the whole
I/O space with register based I/O is impossible. More detail about Memory Mapped I/O
will be given in chapter 3.
• Support for multiple and different cards

Some physical setups may require multiple and different Anything I/O cards on one
PC/104-plus stack.
• Support for kernel versions range

The Control engineering laboratory makes use of different kernel versions. Support has to
be added from Linux 2.6.10 till 2.6.20 (currently the latest).
Besides these requirements some changes need to be made to the card detection routines that
are part of the driver since the functions currently used in both drivers are deprecated. Since the

Control Engineering Jeffry Molanus, September 25, 2007

6 Anything IO drivers

2.6 Linux kernel, a new and more structured method was introduced to scan and detected the
hardware. The new driver should use these functions, and doing so, enable the use of different
cards with just one driver. Other changes should be made on how the card is programmed. Since
programming and actually using the I/O card can be seen as two different devices, the driver
should make this difference visible in user space by means of two separate device files. This makes
programming the FPGA in principle the same as the first driver developed by Marcel Groothuis
but with a different implementation. This is the preferred approach since programming the
FPGA wonŠt require any user space tools.

2.5 Strategy
Looking at the requirements and changes to the detection routines, the choice for starting from
scratch becomes apparent. The best arguments for this choice are the fact that the API of the
2.6 kernel has changed a lot. Furthermore the internal data structures of the anyio proc and
the anyio old driver would need a redesign in order to support the 4I68 card. Besides that, the
Control engineering laboratory wishes to have just one driver that supports all of Anything I/O
card. So a new driver will be written from scratch as opposed to updating both of the old drivers.

A new user space library will be written that will accommodate the control application de-
veloper with a predefined set of functions needed to get full functionality of the Anything I/O
cards. The library will also provide a structured fashion to use several and different cards all
together.

Jeffry Molanus, September 25, 2007 University of Twente

3 The Linux kernel and Linux drivers
This chapter describes how the basics of the Linux kernel works with the focus on accessing
peripherals on x86 CPU’s. It gives an insight in how the kernel deals with hardware access and
thus, how the kernel communicates with the Anything I/O card. Section 3.1 covers the concept
of kernel and user space and system calls. Section 3.2 explains the function of the ioctl() system
call and 3.3 covers the working of memory mapped I/O.

3.1 User and Kernel space

The inner workings of different operating systems and thus the Linux kernel all boil down to
the same fundamental approach of protecting the computer from bad user input, keeping track
of who is using, or wants to use certain system resources and to realize pseudo parallelism
regarding process management. All of this is done by means of kernel and user mode (protected
and enhanced). The kernel mode ring is there where the kernel resides in and has full access to
all the resources and peripheral that is connected to the computer. The second ring is where the
user space applications reside in, and has limited access to computer resources (the exact address
space to which the user space mode ring gives access to is CPU specific). Special gates between
rings are provided to allow an outer ring to access an inner ring’s resources in a predefined
manner, as opposed to allowing arbitrary usage. To get a message to kernel space, certain
system calls are provided by Linux. Once a system call has been made by the user application
the kernel switches to kernel space and serves the request.

Figure 3.1: System call ’bridges’

Control Engineering Jeffry Molanus, September 25, 2007 7

8 Anything IO drivers

3.2 The ioctl() system call

Once a driver resides in the kernel, and thus is part of the kernel space, there is a need to
communicate with this piece of hardware by means of the earlier explained system calls. Using
the ioctl() system call, which stands for Input Ouput ConTroL, the user space application is
able to send a structure of data in to the kernel. The driver has to implement the ioctl() call
itself. It has to make a clear distinction between the different arguments passed and has to
determine if the request made is sane. In case of the Anything I/O driver the ioctl() call, will
call yet another function which performs the actual I/O on the hardware. In this particular case
the inX() and outX() functions, where X stands for byte, word or dword, see figure 3.2.

Figure 3.2: Implementation of the ioctl system call

3.3 Memory mapped I/O

The coverage of memory mapped I/O will not go in to great detail since this involves memory
management in general and that is the hardest and most complex part of the Linux kernel.
However, when using memory mapped I/O, the CPU uses the same address bus and thus in-
structions to write into memory and I/O registers as opposed to direct I/O where the data is
passed directly in to the registers of the device. Direct I/O has a limited address space. What
basically happens is that the hardware registers that cannot be reached by the conventional
function calls inX and outX, are mapped to (virtual) memory. The reason why this is being
used at all is that the CPU needs to reserve address for I/O operations. A trade off is there for
chosen between directly addressable I/O registers and physical ram, when there is need for more
I/O addresses memory mapped I/O is the solution. Also, this makes writing device drivers in
C is a lot easier. Reason for this is that registers can be manipulated like if they were normal
variables.

Jeffry Molanus, September 25, 2007 University of Twente

3. The Linux kernel and Linux drivers 9

Figure 3.3: Data path difference between direct I/O and memory mapped I/O

In figure 3.3 two different data paths are illustrated to give insight on what the fundamental
difference is between direct I/O and memory mapped I/O. The arrow (1A) and (1B) depict the
path for memory mapped I/O, the data goes in to main system memory and is passed from
there on to the device. The second path (2) depicts the direct I/O path.

Control Engineering Jeffry Molanus, September 25, 2007

4 The new Anything I/O driver
This chapter focuses on the generic structure of the new driver anyio v3, section 4.2 discusses
the new anyio library and provides an example application. Conclusions can be found in 4.3.

4.1 Generic structure of the driver

The new kernel driver performs several tasks in order to make use of the Anything I/O card,
the most important tasks are:

• Detecting the card(s)

• Providing card status through procfs
• ioctl interface for data transactions and card information
• User space programming access through /dev/anyioX prog
• User space device access through /dev/anyioX

With the right (root) permissions, a user space program is able to directly write to the first
256 addresses omitting the driver all together, this delivers a speedup of about 66% (Groothuis,
2004) The data flow is depicted in figure 4.1. The direct flow is given by (B). However the first
addresses can also be reached utilizing the kernel driver, this path is depicted by (B), (C) and
(D). Depending on the address where the data is written the next step is either to the FPGA of
the LEDs. When using memory mapped I/O there is only one path available namely path (A)
to (D), and again depending on the address path data is send or read from the FPGA or the
LEDs.

Figure 4.1: Generic structure of the new driver

Jeffry Molanus, September 25, 2007

 4. The new Anything I/O driver 11

4.2 Anyio user space library

In order to make use of the kernel module provided ioctl interface, a library has been written
to make usage of the functions easier and to manage multiple cards in one user space program.
The usage of the library is not mandatory, the library holds these basic functions

char anyio read byte(struct registers *card, int offset) read one byte at offset
short anyio read word(struct registers *card, int offset) read two bytes at offset
int anyio read dword(struct registers *card, int offset) read four bytes at offset
void anyio write byte(struct registers *card, char byte, int offset) write byte at offset
void anyio write word(struct registers *card, short word, int offset) write two bytes at offset
void anyio write dword(struct registers *card, int dword, int offset) write four bytes at offset
int anyio status(struct registers *card) returns the status of the card
int anyio open(char *devname, struct registers *card, int directio) open the card for usage

Table 4.1: Functions provided by the Anyio library

A typical user space application has the following form:

 
1 #include <a n y i o . h> /∗ a n y i o h e a d e r c o n g a i n g s t r u c t u r e i n f o ∗/
2 #include <s t d i o . h> /∗ p r i n f t and such ∗/
3 #include < g i l a . h> /∗ c o n t a i n i n s a n y i o l i b r a r y f u n c t i o n s ∗/
4

5 void main ( void )

6 {
7

8 struct r e g i s t e r s c a r d 1 ; /∗ card 1 ∗/
9 struct r e g i s t e r s c a r d 2 ; /∗ dummy card f o r example r e a s o n s ∗/
10

11 a n y i o o p e n ( ”/ dev / a n y i o 0 ” , &card1 , 0 ) ;
12 a n y i o s t a t u s (& c a r d 1 ) ;
13 a n y i o w r i t e b y t e (&card1 , 0 x00 , 1 6 ) ; /∗ c o n f i g u r e as o u t p u t ∗/
14 a n y i o w r i t e b y t e (&card1 , 0 x f f , 1 6 ) ; /∗ c o n f i g u r e as o u t p u t ∗/
15 a n y i o r e a d b y t e (&card1 , 1 6 ) ;
16 p r i n t f ( ”r e a d %c \n ” , c a r d 1 . datab . v a l u e ) ;
17 /∗ same r e s u l t as l i n e a bo ve ∗/
18 p r i n t f ( ‘ ‘ r e a d %c \n ’ ’ , a n y i o r e a d b y t e (&card1 , 1 6 ) ;
19

20 while ( 1 )
21 {
22 a n y i o w r i t e b y t e (&card1 , 0 , 0 ) ;
23 sleep (1);
24 a n y i o w r i t e b y t e (&card1 , 0 xFF , 0 ) ;
25 sleep (1);
26 }
27 }
 
Listing 4.1: Example program that oscillates output pins

Control Engineering Jeffry Molanus, September 25, 2007

12 Anything IO drivers

To make use of the Anything I/O cards, a structure of the type register has to be declared. This
structure holds the addresses of the registers used by the Anything I/O card, for more details
about this structure please refer to Appendix A, or refer to the appropriate header file(s). To
use multiple cards of different types, another declaration of the type registers is needed, in the
example program this is illustrated by the declaration of the dummy card. This dummy card
could be used as a real card and be manipulated in the same manner as card1.

4.3 Conclusion
Based upon the requirements and the proposed improvements, a new driver is written. The
driver supports all of the Anything I/O cards used at the control engineering laboratory, the
5I20, 4I65 and the new 4I68. All of these cards can mixed together and are usable with just
one new driver. All of these cards now support memory mapped I/O enlarging the maximum
address space of the FPGA configuration.The programming method of the anyio old driver has
been used and, a new user space library has been written to provide the application developer
with a set of functions to make use of the card. Testing of the driver with a real setup is done
in Chapter 5.

Jeffry Molanus, September 25, 2007 University of Twente

 5 Testing the driver
An ideal testing environment for the new driver is to replace the current driver used on an
existing setup, with the newly developed driver. The driver is tested with the Paper Path setup.
Otto (2005) designed a simplified version of the paper path of a copier. The Paper Path setup
is controlled by an embedded control systems that is developed by Groothuis (2004). Controller
software is designed with 20-sim, and deployed with the 4C tool chain (Posthumus, 2007).

Figure 5.1: Overview of the Paper Path (Ambrosius 2007)

The Paper Path setup currently uses the anyio proc driver, which was replaced by the anyio v3
driver. The control software generated by 20-sim and the 4C tool chain is adapted to use the
newly developed anyio library. In order to achieve this, only the template used by the 4C tool
chain is changed. The changes can be found in Appendix A. Section 5.1 will cover the steps and
requirements in order to load the driver. Section 5.2 is about programming the FPGA. Finally
in section 5.3 the tests preformed are described and section 5.4 concludes this chapter.

5.1 Loading the driver

The Anything I/O driver developed in this project has to be downloaded from the Intranet.
Once downloaded, the driver must be compiled and installed. Prerequisites for compiling the
driver are kernel sources and a working C compiler. To make use of the supplied MakeFile, make
and its dependencies should also be available. Root privileges are needed to load the driver into
the kernel.
 
1 t a r −x z v f a n y i o v 3 . t a r . gz
2 cd a n y i o v 3
3 make && insmod a n y i o . ko
 
Listing 5.1: Compiling and installing the driver
If the driver finds a compatible card, output appears on the screen. Note that the driver makes
no distinction what type of card is found. Different types of cards work transparently: the driver
hides the hardware differences.
 
1 Minor : 0 i r q : 0 ( i r q count : 0 )
2 PLX 9030 I /O b a s e p o r t : 0 xbc00 −0x b c 7 f
3 PLX 9030 c o n t r o l / s t a t u s p o r t : 0 xbc54 −0xbc56
4 FPGA 16− b i t I /O b a s e : 0 xb800−0 x b 8 f f
5 FPGA 32− b i t I /O b a s e : 0 xb400−0 x b 4 f f
6 Current c o n f i g u r a t i o n : <Empty>
7 C o n f i g u r a t i o n i s not a c t i v e
 
Listing 5.2: Console output after loading the driver

Control Engineering Jeffry Molanus, September 25, 2007 13

 14 Anything IO drivers

5.2 Programming the Anything I/O cards

After the driver has been loaded, the FPGA needs to be programmed. This can be done by
’hand’ or by the 4C tool chain. In this particular case, the same FPGA configuration that was
loaded in to the old driver will be reused. To program the FPGA, without make use of the 4C
tool chain, the steps in listing 5.3 should be taken. Where configuration.bit is the desired FPGA
configuration.
 
1 cp c o n f i g u r a t i o n . b i t / dev / anyioX prog
 
Listing 5.3: Programming the Anything I/O card manually

5.3 Using the driver

When the programming sequence has been completed the prompt reappears. At this point, the
paper path 20-sim model is used to generate the control application. When using the 4C tool
chain the control application can be uploaded, started and stopped from within the tool chain.
If the tool chain is not used, the control application has to be transferred manually and started
manually. For instance if a control application is named SubModel1, the application should be
uploaded and started as shown in listing 5.4.
 
1 subModel1 &
 
Listing 5.4: Starting the control application manually

After this final step, the paper path is ready to use in combination with the new driver. Sheets
of paper are placed in the paper path input module. And the setup is monitored for any odd
behavior. The 4I68 card is also tested. There is no working setup like the paper path to test the
card in. So in order to test the new card, a simple program that toggles the output pins of the
Anything I/O card is developed. The 4I68 card is then stacked on to the paper path PC/104
and both Anything I/O cards are tested simultaneously. At the output pins an oscilloscope is
connected. The complete setup is depicted in figure 5.2 the results of the scope are shown in
5.3.

Figure 5.2: Schematic overview of the test setup

Jeffry Molanus, September 25, 2007 University of Twente

5. Testing the driver 15

Figure 5.3: Pin output of the 4I68 Anything I/O card

5.4 Conclusion
The anyio v3 driver works well on both of the Anything I/O cards. No odd behavior is seen
during the test of the Paper path. Using different cards at the same time also is a success.
Conclusion of the test, therefore, is that the new driver supports all of the boards used at the
Control engineering laboratory and is able to replace the anyio proc and the anyio old driver
without breaking the setup. Small changes are required to the 4C templates of setups that
currently make use of the old drivers.

Control Engineering Jeffry Molanus, September 25, 2007

6 Conclusions
6.1 Conclusions
The objectives of this assignment were full filled, resulting in a new kernel driver for the Anything
I/O cards used at the Control Laboratory. Furthermore support has been added for the new
version of the card, which can be used transparently by loading the new driver. It is also possible
to use memory mapped I/O. Hence it is possible to make FPGA configurations with an I/O
space larger then 256 addresses, which are accessible with the proper ioctl() calls, or using the
new anyio library, in which the user is encouraged to do so.

6.2 Recommendations
Doing I/O in user space would improve the overall performance of the Anything I/O cards.
If the driver can be controlled outside kernel space, more higher level libraries are available
to control the card and give it a tighter integration with, for instance the 4C tool chain. UIO
(User space I/O) is now part of the main kernel branch and should be used in future development.

The new driver uses the ioctl() system call interface which allows passing data structures to
the driver. Each time a system call is called, the kernel switches to kernel space and serves the
request. Each kernel switch itself costs time and performing the services costs time. Looking at
the dominant behavior of the Anything I/O driver, all it does is read and write to registers with
a fixed address. Doing I/O in user space would eliminate the need for these switches. During
development of the new Anything I/O driver kernel facilities to accommodate for this where
being developed. Currently programming the card is initiated in user space however, the actual
implementation is in kernel space, handling files in kernel space in general is discouraged. The
whole implementation of programming the card could become part of the 4C tool chain instead.

Jeffry Molanus, September 25, 2007

 A Template Changes
The 4C tool chain uses a template file for code generation. This template file also contains the
relevant parts for controlling the Anything I/O card.

A.1 Function changes

There are 2 functions used in the template that have to be changed to make use of the new
Anything I/O library. The functions read or write to a register. The value of the registers
depends on the FPGA configuration.
 
1 r t a n y r e a d (&RegVal , s i z e o f ( int ) , ADPDEnBase , SIZE32 , 0 ) ;
2 r t a n y w r i t e (&RegVal , s i z e o f ( int ) ,ADMCR, SIZE32 , 0 ) ;
 
Listing A.1: old functions

These 2 function calls have to be changed in order to work with the new driver and the new
Anyio library in to:
 
1 a n y i o r e a d d w o r d (&card1 , ADPDenBase ) ;
2 a n y i o w r i t e d w o r d (&card1 ,&RegVal ,ADMCR) ;
 
Listing A.2: new functions

A.2 Initialising the card

In order to use the card withing the templates, the initializing of the card has to be changed in
the template to the following:
 
1 struct r e g i s t e r s c a r d 1 ;
2 a n y i o o p e n ( ”/ dev / a n y i o 0 ” , &card1 , 0 ) ;
 
If the card is referred to in any other file it should be declared as extern. The last argument
determines if the card should use direct I/O (1) or not (0).However, this is purely a user space
annotation that might give some insight of the capabilities of the card during development or
debugging of the control application. The kernel driver determines if memory mapped I/O can
be preformed or not.

A.3 The registers structure

The register structure holds the addresses of the cards. Each data type has its own embed-
ded structure within that allows reading or writing. So in order to write a DWORD, the
anyio datadw structure has to be filled with the desired values. In example; register.datawd.value=0xff,
sets the value of datadw accordingly. By calling the function, anyio write dword(); the value is
written to the card.
 
1

3 struct r e g i s t e r s
4 {
5

6 struct anyio status status ; /∗ s t r u c t u r e w i t h i n f o a b o u t t h e ca rd ∗/

7 struct anyio d a t a b datab ; /∗ b y t e s t r u c t u r e ∗/
8 struct anyio dataw dataw ; /∗ word s t r u c t u r e ∗/
9 struct anyio datadw datadw ; /∗ d o u b l e word s t r u c t u r e ∗/

Control Engineering Jeffry Molanus, September 25, 2007 17

 18 Anything IO drivers

10 int f d ; /∗ f i l e d i s c r i p t o r t o w r i t e t o ∗/
11 u32 f p g a 1 6 b a s e ;
12 u32 f p g a 3 2 b a s e ;
13 char d i r e c t i o ; /∗ e n a b l e d i r e c t i /o ∗/
14 };
15

16 struct a n y i o d a t a b
17 {
18 u8 v a l u e ; // v a l u e t o w r i t e or r e t u r n
19 u32 o f f s e t ; // p o r t o f f s e t from b a s e a d d r e s s
20 u8 i o t y p e ; // s e e d e f i n e s ( p l x , f p g a 1 6 o f f p g a 3 2 i o p o r t s )
21 };
22

23 struct anyio dataw

24 {
25 u16 v a l u e ;
26 u32 o f f s e t ;
27 u8 i o t y p e ;
28 };
29

30 struct anyio datadw

31 {
32 u32 v a l u e ;
33 u32 o f f s e t ;
34 u8 i o t y p e ;
35 };
36

37 struct a n y i o s t a t u s
38 {
39 u32 f p g a 1 6 b a s e ;
40 u32 f p g a 3 2 b a s e ;
41 int is programmed ;
42 char c o n f i g n a m e [NAME LEN] ;
43 int minor ;
44

45

46 };
 
Listing A.3: Anyio data structures

Jeffry Molanus, September 25, 2007 University of Twente

Bibliography
Posthumus, R. (2007), “Data logging and monitoring for real-time systems”, MSc-Report 015CE2007,
Control Laboratory, University of Twente, May 2007

Kuppeveld, T.G.M.G.M. van, Sprik, E. (2006), “Design and Realization of the ViewCorrect
plotter”, Pre-doctoral assignment-Report 033CE2006, Control Laboratory, University of Twente,
October 2006

Otto, M. , ”Mechatronic setup for Boderc project”, MSc.-Report 038CE2005, Control Labo-
ratory, University of Twente, October 2005

Groothuis, M.A. (2004), “Distributed HIL simulation for BodeRC”, MSc.-Report 020CE2004,
Control Laboratory, University of Twente, August 2004

Buit, E. (2005), “PC104 stack mechatronic control platform”, MSc.-Report 009CE2005, Con-
trol Laboratory, University of Twente, April 2005

Visser, P. M., M. A. Groothuis, et al. (2006), ”Multi-purpose toolchain for embedded con-
trol system code on a variety of targets.”

Corbet, J., Rubini, A., Kroah-Hartman G. (2005), “Linux Device Drivers, Third Edition”,
O’Reilly Media, Inc ISBN: 0-596-00590-3

Control Engineering Jeffry Molanus, September 25, 2007 19