Bailey O.H.Embedded systems.Desktop integration.2005

We have now completed the function and category tables for both the embedded system and desktop systems. Using the categories we have just created we will build our message tables. Since we have accounted for both the embedded system and host system functions, we can now consolidate the rest of the protocol definitions into a single table. In Table 2-4 we have taken each function in the previous two tables and assigned each to a message type. Once our categories and message types are defined, we can determine the parameters that will be associated with each function. Here I have assigned a message type and parameter type to the function categories.

Table 2-4: Message definitions

Get

Send

LCD Msg

Message Monitor or NoMsg

Set

Set Message

LCD Msg

& Control

Acknowledge

text

Figure 2-14

Chapter Summary

The embedded system now has a formal language that allows it to talk to the world. While this is a simple example, it covers handling device input, device output, display output, user input, and the remote monitoring and control of the environment. In the process of establishing a protocol we have narrowed the differences between desktop systems and the embedded system to the interface or device driver layer on the host systems. Our device input and output seamlessly interface to a protocol that the device driver layer uses to send and receive messages to a remote system. On the host side this protocol interfaces to the device driver, which will in turn interface to the desktop application layer. In the next chapter we will design the device interface layer to handle the differences in the hardware layer and the differences between UNIX and Windows. This approach will lead us to design a user application that will interface to the device driver layer the same way across platforms.

58Chapter 3 / Designing Portable Device Interfaces for Windows and UNIX

Device type — Whether past versions of the OS supported this device type

Driver structure — Whether a complete driver needs to be written or a mini-driver or “wrapper layer” will suffice

Designing a portable device driver isn’t a decision that will be made at a given point in the development cycle. It is a decision that will be made from the project start and will influence decisions throughout the development cycle. This single decision can have the largest impact on the overall cost of a project. In an ideal world the implementation phase of this project would be the easiest since it would merely be implementing the work already defined. But as we all know, this is not an ideal world. Technology industries are constantly forging ahead with new ideas, products, and enhancements to existing products. It is not uncommon for one or more operating system updates to be released between the design of a product and its implementation. For that reason, any experienced software architect knows a certain amount of flexibility needs to be incorporated into the design. If this isn’t done, you can expect what I call the infinite design cycle implementation. Each time the implementation team gets the design, some changes need to be made to support the latest OS changes, so the design is sent back. Well, guess what happens by the time the design changes are made, reviewed, approved, and sent back. You guessed it — the whole cycle starts again.

Let’s examine each of the above considerations and the effect they have on the portability of the device layer. Unlike the hardware implementation, this side of the development is dependent on many outside forces. OS vendors and third-party suppliers to those vendors have a major influence, as do security updates due to virus threats and other market conditions. So how does one design a device driver under these conditions? Following a few simple rules not only allows your design to be current, but also develops the highest quality driver with the longest life cycle.