Bailey O.H.Embedded systems.Desktop integration.2005
.pdf
70 |
Chapter 3 / Designing Portable Device Interfaces for Windows and UNIX |
|
|
choice. If no graphic desktop is chosen, a text mode logon prompt is displayed. If a desktop GUI mode is chosen, then a graphic version of a user ID and logon prompt are displayed. In UNIX-style operating systems, the X server is the screen I/O manager and mouse handler at the lowest level. The X server shifts the display into graphics mode and then loads the chosen graphic desktop as a program. This has several obvious and not-so- obvious advantages.
Taking this approach, the kernel, device driver, and system services layers are all text mode applications that don’t require any graphic desktop to load or use. If you’ve used both Windows and UNIX/Linux with a graphical desktop manager you will notice the UNIX/Linux versions appear to run slower. To some degree that is true. Since the graphic desktop is not integrated into the system, the desktop manager is being given processor priority just like every other application. This architecture is shown in Figure 3-4.
User Application
Kernel
Kernel Mode Features
Software Devicetext Control
Hardware Device Control
External Hardware
|
Legend |
||
|
|
|
|
Kernel |
|
|
Device Driver |
Layer |
|
|
Layer |
|
|
|
|
Figure 3-4
Chapter 3 / Designing Portable Device Interfaces for Windows and UNIX |
71 |
|
|
Unlike Windows 2000 and XP, the UNIX device driver layer is simpler in design. Since the graphic desktop is another program, access to the kernel and device layers is much closer to the application layer and easier to develop for. This doesn’t mean writing UNIX/Linux drivers is a cakewalk, but rather that fewer considerations need to be given to graphic desktop integration. This architecture by design gives higher priority to tasks that run closer to the core of the operating system, again reducing some of the considerations that an integrated graphic desktop may pose.
Device Driver Types
Though the architecture of Windows and UNIX are different, they share common ground when it comes to the device types supported. These types of devices are discussed in this section.
Character Devices
Keyboard, terminal, and serial devices are known as charac- ter-based devices. These are devices that send, receive, and process data one character at a time.
Block Devices
Block devices process data in blocks, that is, more than one character at a time. Disk files, disk drive interfaces, SCSI controllers, scanners, and cameras are all examples of block devices.
Chapter 3
72 |
Chapter 3 / Designing Portable Device Interfaces for Windows and UNIX |
|
|
Network Devices
Originally network devices were block devices, but in the last few years they have been broken out into their own device category. The most recent UNIX and Linux kernel updates (2.4 and 2.6) provide fairly extensive network card support. Windows also has extensive network card support. FreeBSD (UNIX) and Windows have thorough wireless network card support also. New Linux kernels have excellent support, while the older 2.2 kernels have limited wireless support. Both architectures support a tiered or mini-port driver layer. This allows developers to add multiple levels of driver support for different application needs while sharing the same physical device driver.
User Application - 2
User Application - 3
User Application - 4
User Application - 1
Shared Driver - 3 (Mini-Port Driver)
Shared Driver - 2 (Mini-Port Driver)
Shared Driver - 1 (Mini-Port Driver)
Network Card Device Driver
Network Card
Inherit Driver
Characteristics from
Original Device Driver
Figure 3-5
Each driver layer inherits from the original device driver, and changes are implemented to meet application specifications. These are known as “mini-port drivers,” or “tiered drivers.” These drivers allow specific functionality to be implemented without writing a complete device driver. The base device driver
Chapter 3 / Designing Portable Device Interfaces for Windows and UNIX |
73 |
|
|
may be inherited. Each driver has a unique name that differentiates itself from the other drivers in the chain.
USB Devices
USB (or universal serial bus) allows for layered device drivers to be added and removed while the system is running. Because USB is defined as a “hot-pluggable” architecture, this layered (or tiered) device driver structure is unique when compared to other device drivers. Unlike other devices, USB has a core driver manager designed to detect the attachment and removal of a device while the system is running. This means that drivers for each device are loaded and unloaded dynamically. If an application is started that addresses a USB device, it must be able to handle the device being removed and take an orderly shutdown action accordingly. This may sound complicated, but USB is well defined and well thought out to handle this type of implementation. Because of its architecture, USB has a device handler that is part of the operating system. When a new device is attached, the device announces itself to the system. The core driver then performs handshaking and interrogates the device header, which provides vendorand product-specific information. This information is used to look up the driver name and location for this specific device. That’s the abbreviated description; more detail will be covered as we implement the interface in Part II of this book. Developing a USB driver requires the developer to write the specific functions for handling device-specific I/O, startup, and shutdown. USB allows the driver developer to focus on features specific to that device and not spend as much time interfacing to the operating system
Even though a core driver is available at the system level, each device must provide a second-level driver to support specific device I/O. USB hubs and the core driver handle device detection, initialization, and shutdown while also providing a pathway for the data to travel.
Chapter 3
74 |
Chapter 3 / Designing Portable Device Interfaces for Windows and UNIX |
|
|
|
USB 3 App |
|
|
|
USB 2 App |
|
|
|
USB 1 App |
|
||||||||||||||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
USB Driver - 3 |
|
|
USB Driver - 2 |
|
|
USB Driver - 1 |
|||||||||||||||||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
USB Device Manager |
|
|
|
|
|
|
|
|
|
|
|
|
||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
USB Device |
|
|
|
|
|
|
|
|
|
|
|
|
||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|||||
|
|
USB Hub |
|
|
|
USB Hub |
|
|
|
USB Hub |
|
|||||||||||||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
USB Dev |
|
|
|
USB Dev |
|
|
USB Dev |
|
|
|
USB Dev |
|
|
USB Dev |
|
|
|
USB Dev |
|
||||||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
USB Dev |
|
|
|
|
|
|
|
USB Dev |
|
|
|
|
|
|
|
USB Dev |
|
|
|
|||||||||
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Figure 3-6
Portable Device Driver Requirements
Now that we have provided some background on the target platforms and how they handle devices we can start defining our portable device layer. The goal of having a portable device layer for our application is to simply hide the platform-specific details of the device interface, while providing the functions required to send, receive, and process data.
Since we have already defined the protocol between the user application and the embedded system, we only need to concentrate on host-specific device communications as they pertain to:
The specific device driver for a given device type (RS-232, USB, Ethernet)
A mini-port driver to handle high-level communications between the device and the application (USB initialization, shutdown, etc.)
Providing platform-independent device driver management
Chapter 3 / Designing Portable Device Interfaces for Windows and UNIX |
75 |
|
|
For the purpose of this chapter, the definition of “processing” data is simply seeing that it is properly sent and received between the embedded system and the user application. You may be asking yourself why we aren’t concerned with embedded system control at this point and potential error conditions in this layer. The answer is very simple: We want to be certain that communications control and data control are handled in their proper layers and are independent of each other. If we mix data and communications control, or worse intermix that control in multiple layers, we will defeat the purpose of portability and complicate the debugging process (debugging will be covered in Part II as we implement our system). This approach allows us the benefit of breaking the entire system down into smaller pieces
|
Embedded Device (Thermostat) |
3 |
|
Chapter |
|
|
Communications Protocol Layer (Software) |
|
|
|
|
Serial Interface |
Ethernet |
USB |
(RS-232) |
Interface |
Interface |
Communications Cable (RS-232, Ethernet, USB)
Serial Interface |
Ethernet |
USB |
(RS-232) |
Interface |
Interface |
Hardware Interface (Operating System Kernel) |
|
|
Portable Device Driver / Device Protocol Handler |
|
|
User Application |
|
|
|
Legend |
|
Embedded |
Host |
|
Device |
Computer |
|
Figure 3-7 |
|
|
76 |
Chapter 3 / Designing Portable Device Interfaces for Windows and UNIX |
|
|
and addressing only those design concerns for the piece we are currently working on. Now, you may be thinking that by taking this approach we will miss something important. There are several remaining pieces in the design of this system, and the final chapter in this section will be a complete design review. In design review we will look at each piece of the system and see how well the puzzle fits together in detail.
Our portable device driver is sandwiched between the user application and the hardware interface layer of the operating system. Since we defined the objective, now let’s outline the functions our driver is responsible for:
Providing uniform function calls to the embedded system from UNIX, Linux, and Windows
Formatting outgoing data into device protocol format before sending
Formatting incoming data into device protocol format before passing it to the user application
Verifying data buffers have been sent properly
Acknowledging data has been received properly
Formatting data to be sent and received by the proper hardware interface while maintaining transparency and platform independence to the user application
Porting the protocol handler to Windows, UNIX, and Linux for use
While this is a short list of requirements, it will take some effort both in the design and implementation stages to meet the goal of portability. Figure 3-8 illustrates the requirements of the portable device layer in more detail.
Now that we can visually see what tasks need to be implemented by our driver layer and we have a short list of requirements, the next step is to define each of the required tasks in detail to be certain we haven’t left out any features that are needed. We will do this starting with the task closest to the
Chapter 3 / Designing Portable Device Interfaces for Windows and UNIX |
77 |
|
|
hardware transport and then moving up to the user application interface.
Cable to Embedded Device
Serial Data |
Ethernet |
USB Data |
|
|
|
Handler |
Data Handler |
Handler |
|
|
|
|
Hardware Dependent I/O Functions |
|
PortableDriver |
|
|
|
Communications Protocolext Handler for Host |
|
Code |
||
Data Management and Control Functions for Embedded Device |
|||||
|
|
||||
User Application
Figure 3-8
Hardware Function Calls
This is the software that communicates directly with the hardware. There are two categories of functions: generic and device specific. Generic functions are those that are required no matter which hardware interface is used. Device specific are those required only for a specific type of hardware.
Generic Device Functions
Let’s begin by examining the generic function list. These are functions that will be used across all hardware interfaces. The first of this group would be to open and close the device for transmitting and receiving data. We will name these functions g_device_open and g_device_close. Next we need to send and receive data from all devices so we will define g_device_write and g_device_read. Finally, we need to be able to get and set the status for all the devices so we will define the g_device_get_
Chapter 3
78 |
Chapter 3 / Designing Portable Device Interfaces for Windows and UNIX |
|
|
status and g_device_set_status functions. This gives us a list of the following six functions:
g_device_open — Opens a device for reading and writing
g_device_close — Closes a device that is currently open
g_device_read — Reads data from an open device
g_device_write — Writes data to an open device
g_device_get_status — Gets current device status
g_device_set_status — Sets device status
Device-Specific Functions
Device-specific functions are a little more complicated since we have to be familiar with the features of RS-232, Ethernet, and USB. This feature list is dependent on the hardware interface and parameters that each device can accept. Let’s examine each hardware interface and build our function list for each.
RS-232-Specific Functions
The RS-232 interface is managed by the system in Windows, UNIX, and Linux environments. The interface has both software and hardware controls associated with it that control baud rate, data flow, and physical port number. Since we aren’t sending large amounts of data we will use a simple handshake that controls the hardware handshake CTS and RTS signals. To handle the RS-232-specific functionality we will add the following function calls:
serial_set_baud — Sets baud rate on current port
serial_get_baud — Gets baud rate on current port
serial_flow_off — Toggles hardware control line to stop sender
serial_flow_on — Toggles hardware control line to start sender
serial_set_port — Sets port number
Chapter 3 / Designing Portable Device Interfaces for Windows and UNIX |
79 |
|
|
serial_get_port — Gets current port number
serial_write_data — Sends data buffer
serial_read_data — Processes incoming data buffer
serial_port_open — Opens port for use
serial_port_close — Closes serial port
Ethernet-Specific Functions
Since Ethernet can be addressed in several different ways we want to keep our dependent functions generic enough to accommodate the needs specific to our application. With this in mind we will first outline the functions common to all access methods. All Ethernet transmissions require a source and destination IP address. If we use TCP/IP, the network interface will send and receive data via Sockets or WinSock. If we don’t use TCP/IP, then we will send and receive raw data directly to the network card. Since we have defined the communications protocol to the device separately, we can use either Sockets or Direct Access. Figure 3-9 shows how the Ethernet software layer handles these two different types of communications.
Cable to Embedded Device
Hardware I/O Manager
Ethernet RAW Data Handler
TCP/IP (Socket) Layer
Ethernet Device Driver Layer
RAW Data Handler |
|
TCP/IP Data Handler |
|
|
|
User Driver Layer
User Application
Chapter 3
Figure 3-9