Bailey O.H.Embedded systems.Desktop integration.2005
.pdf
80 |
Chapter 3 / Designing Portable Device Interfaces for Windows and UNIX |
|
|
While it appears we could use both methods simultaneously, only one layer can be open at a time. This prevents two applications from writing at once and turning the data into garbage. To keep application access simple we will define which method to use when the device is opened. This will be a parameter passed with the open command that is a value of RAW or TCP. Now we have a manageable set of Ethernet-specific related methods. They are:
ethernet_open — Opens the device for communications
ethernet_close — Closes an existing Ethernet session
ethernet_set_src_ip — Sets source IP address
ethernet_set_dest_ip — Sets destination IP address
ethernet_write_data — Writes data to output buffer
ethernet_read_data — Moves received data to buffer for processing
To complete the open process at least one parameter will need to be passed to tell which method of communications will be used. Since we have documented the parameter we will leave final definitions until the implementation phase.
USB-Specific Functions
As discussed earlier, USB differs from any other communications method in several ways. Since USB allows devices to be added and removed while the system is running, a unique scenario is created. In simple terms, USB allows devices to be booted and shut down anytime while the host system remains running. To handle this situation, Windows, UNIX, and Linux have a USB core driver that detects the addition and removal of USB devices. When a device is connected, it forces the USB core driver to run through an enumeration process for the newly attached device. This process will eventually determine the USB device class and the vendor, product, and optional revision codes contained in the device. The class type determines which part of the USB core driver will handle the device I/O. This information is then used to
Chapter 3 / Designing Portable Device Interfaces for Windows and UNIX |
81 |
|
|
load device-specific drivers that handle the device, vendor, and version-specific data.
Device Address
Vendor ID
Product ID |
USB Device |
USB Class
USB Plug and Play Manager
USB Device Manager
Vendor Supplied Device Driver
User Application
Figure 3-10
When a new device is attached, it starts as device 0. Device 0 is reserved for newly attached devices. The host interrogates the device to get the vendor ID, product ID, USB class ID, and optional product revision ID. This information is used to find the best match of a vendor-supplied device driver. Some types of USB classes are supported by the operating system if a vendor driver is not available. Keyboards and mice are two examples of devices that have internal support for certain USB classes. Keyboards and mice are known as human interface devices (HID) and can have built-in support at the system level if no device-specific driver can be found. Until the device is identified, the USB initialization driver (device ID 0) is used to communicate with the USB device. When a USB device is removed, the event triggers a query of connected devices. A comparison is done against the current device list and the device not responding to the inquiry is removed. Given all this information we can determine that the following functions are needed:
Chapter 3
82Chapter 3 / Designing Portable Device Interfaces for Windows and UNIX
usb_get_vendor — Returns vendor ID
usb_get_product — Returns product ID
usb_get_class — Returns class ID
usb_get_rev — Gets product revision info
usb_get_address — Gets USB address
usb_get_driver — Returns vendor device driver info
usb_open — Opens USB device
usb_close — Closes USB device
usb_write — Writes data to device
usb_read — Reads data from device
usb_control — Sets/retrieves device control
These functions provide the ability to get USB device information; open, close, and manage USB devices; and send/receive USB data. Even if we don’t implement all the code for each function, the function stubs will remain available for future releases as needed.
Note:
USB has many other parameters that can be accessed from the host system. These parameters will be covered in detail in Part II, the implementation section. The information provided here is to facilitate the high-level design.
Chapter 3 / Designing Portable Device Interfaces for Windows and UNIX |
83 |
|
|
Putting It All Together
Since we have covered all three methods of communications between the host and the embedded system, let’s examine our specific functions to see how everything fits together. Figure 3-11 shows how our generic function calls have been translated to device-specific calls.
Chapter 3
Figure 3-11
84 |
Chapter 3 / Designing Portable Device Interfaces for Windows and UNIX |
|
|
Now that we have all the functions defined for our design, we can break them down into four categories. They are:
State — On, off, open, close
Setup — Port number, source IP address, driver control
Data — Read data, write data
Parameter — Flow control, data bits, baud rate
Device State Category
Functions in the State category make a change in the state of the device. Open and close are two examples of functions that cause a change in the device state.
Device Setup Category
These functions or parameters are required before device state can change. One example of this type is the RS-232 port number. The device cannot be opened unless a valid port number is defined first, whereas flow control can be changed without affecting the current device state of opened or closed.
Device I/O Control Category
Data Category
These functions control features associated with sending and receiving data to the device. Baud rate, flow, control, and IP address are just some examples of I/O control functions. These parameters differ from setup parameters because they aren’t required for opening the device or in some cases are simple inquiries to get information from the device such as vendor ID, product ID, and product revision. In some cases, these settings are required for setup while changing their values would be considered I/O control. One example of this scenario is set_src_ip and set_dest_ip. In Figure 3-11 set_src_ip is a setup
Chapter 3 / Designing Portable Device Interfaces for Windows and UNIX |
85 |
|
|
function and set_dest_ip is considered I/O control. Setting the source IP address is required before a valid socket can be opened. Under certain conditions, however, a socket may have multiple sessions going at the same time. The IP address of the destination may not always be required to open a socket but is always required before sending data. These functions manage sending and receiving data to and from the device. Sending data requires having the device open to send/receive data and having a data buffer available to pass data to and receive data from the device.
Function Parameters
Any experienced software or hardware engineer is likely asking why we haven’t filled in the function parameters and return parameters list. The reason is because we are defining what type of control and data functions are required. While we could define the parameter lists and return parameters, they would more than likely change if an experienced engineer were to develop the project. If the engineer working on this project is inexperienced, he or she may not realize the written definitions are simply suggestions or to be used as a starting point. By providing the high-level design and omitting the details, we are merely setting boundaries or guidelines for the implementation engineers to use. During the implementation phase these values will be provided as implementation and testing progress.
This philosophy differs from traditional software design methods. There are a couple of reasons for this difference. First, the system we are implementing is not just an IT system. IT consists of both hardware and software. Setting too many rules before the prototype has been built can lead to infinite hardware and software changes. The electronics need to be well defined before any software is written. But the firmware that brings the electronics to life will actually be subject to changes as the software for the host systems is developed. This is unique to the hardware/software design process, as traditional engineering disciplines allow for mechanical and electrical definitions to all be set before the prototype is built. Blueprint changes are generally
Chapter 3
86 |
Chapter 3 / Designing Portable Device Interfaces for Windows and UNIX |
|
|
made during the prototype phase. Hardware/software systems are more fluid during the prototype stage, unlike their mechanical counterparts. For this reason we need to leave a little more flexibility in how the hardware/software systems integrate than we would with mechanical systems.
Designing for True Portability
True portability between all systems exists only in an ideal world. In our case achieving this is accomplished by designing portable functions during the high-level design. During implementation the developer will make several decisions that will affect how much and how easily portability will be achieved. From the designer’s perspective, using devices that have some built-in support in all the systems that are targets will be a good start to true portability. The more built-in support that exists at the OS level, the less work the developers will have and the higher the degree of true portability. In our design RS-232 and Ethernet are portable across all the platforms we are targeting. USB is supported but there will be some code required that is specific to our product(s).
Because of this we most likely have two separate pieces to our driver layer. The first piece will take our generic function calls and wrap them into system-level calls for RS-232 and Ethernet. We will provide wrappers for USB calls as well, but we need to develop the data handler for our USB device and use it to handle the actual device I/O. At this stage of the design process we’ve defined the functional interface to the device.
The wrapper layer will be portable across all platforms and any platform-specific code that handles device I/O will reside at the driver layer. We are dealing with USB, so even though some code will be needed at the driver level it will be minimal on all the supported platforms. Windows calls this a mini-driver and it has several uses, such as for USB and developing printer drivers.
Chapter 3 / Designing Portable Device Interfaces for Windows and UNIX |
87 |
|
|
Similar to USB, the printer port has generic functions that handle data. Formatting commands for positioning characters, changing fonts, and other data that is printer specific is handled by developing a mini-driver.
Chapter Summary
While developing 100 percent portable device drivers isn’t possible, a large degree of portability can be attained. Careful planning and design, and using devices that have some degree of built-in operating system support can go a long way toward creating portable device drivers. When developing software that will control external hardware devices, there are always control, state, and data management categories. Device parameters may fall into any or all of the mentioned categories. Keep design simple. By focusing on the requirements and leaving development issues to the developers, a solid design compiled with a maximum driver life cycle will be the benefit. A complete review of our design will be given at the end of Part I. In the next chapter we examine the issues that need to be considered when developing cross-plat- form user applications.
Chapter 3
This page intentionally left blank.
Chapter 4
Designing
Cross-Platform User
Applications
Overview
Designing user applications that run on multiple platforms can be both rewarding and challenging. Each operating system has its own set of rules for application development, hardware interfacing, and task scheduling. There are an abundance of program editors, programming languages, third-party developer libraries, and desktop managers (GUIs) that all play key roles in the design and implementation process. There are no national or international standards defining how user interfaces are built or components work, so finding the best method of cross-platform development takes research. Nonetheless, once these challenges have been overcome, developing single-source user applications can become a fun and rewarding experience and can be done with a minimum of additional time. In this chapter we explore the options available to the developer and the impact on development time and project cost.
89