Bailey O.H.Embedded systems.Desktop integration.2005
.pdfThis page intentionally left blank.
Part I
Design
Chapter 1: Design Requirements
Chapter 2: Embedded System Design
Chapter 3: Designing Portable Device Interfaces for Windows and UNIX
Chapter 4: Designing Cross-Platform User Applications
Chapter 5: Developing the Desktop User Application
Chapter 6: Final Design
1
Chapter 1
Design
Requirements
Overview
Our programmers and hardware engineers have been given the task of implementing a new intelligent heating and air-condition- ing control system. The marketing group has determined that a niche market exists for a product that can work either standalone or integrated into a single PC or PC-LAN. To take full advantage of this market opportunity, the marketing department has defined three separate products.
The first is a stand-alone intelligent thermostat that has an LCD display output, three control buttons, four direction buttons, power LED, alarm LED, and internal temperature management and monitoring capabilities. This is a stand-alone device with full environmental management capabilities. External heating and cooling can be controlled through the use of two relay-controlled outputs.
To program the device and monitor it from a desktop computer, an RS-232 port has been built in. This is the least expensive device and can only be connected to a single computer. The device is powered by a 5-volt supply with an internal battery backup.
3
4 |
Chapter 1 / Design Requirements |
|
|
Following is an artist’s drawing of the unit.
2 Line x 20 Character LCD
Alarm, Power LEDs
Temperature & Function Buttons
Functions, Set, & Clear Buttons
^
< |
> |
F |
S |
C |
Alarm On
V
Bottom View
3-Pin Connector 0.1” spacing
Figure 1-1: RS-232 port thermostat
Product number two replaces the RS-232 port with a Universal Serial Bus (USB). This allows a single host system to control multiple units and also allows the device to function as a data-acquisition system to be used for the monitoring and control of multiple rooms or floors within a building from a single PC. As it ended up, the prototype was powered from an external source with USB power being an option.
Chapter 1 / Design Requirements |
5 |
|
|
Chapter 1
^
< |
> |
F |
S |
C |
Alarm On
V
Bottom View
Female USB Connector
Figure 1-2: USB interface thermostat
The third product has an Ethernet interface that replaces the RS-232 or USB interfaces. Ethernet allows this device to be connected to a local area network (LAN). This product serves the smallto mid-sized business owner who needs flexibility in expansion and may require greater distances between units.
^
< |
> |
F |
S |
C |
Alarm On
V
Bottom View
Female RJ-45 Connector (Ethernet)
Figure 1-3: Ethernet interface thermostat
6 |
Chapter 1 / Design Requirements |
|
|
This provides a one-to-many relationship, and the number of devices that can be controlled is almost limitless. Building the Ethernet interface into the device will allow the use of existing computer equipment and network resources. This will make the installation less costly in those buildings that already have a LAN wired in, allowing for a quicker return on the investment and reducing overall cost of ownership. Since each device also works independently of the network, the customer is assured that environmental control will continue to work properly in the event the network stops functioning.
One final requirement from the marketing department is multiplatform support. This will make the product unique in two ways. First, no other competitor has offered a unit that can be integrated into a network this inexpensively. Second, to attract the widest audience the units must be accessible from Windows, UNIX, and Linux. This requirement will make the device compatible with IBM mainframes, Microsoft Windows, Linux, and the Macintosh. After researching the various versions of UNIX, a decision has been made to support FreeBSD. As over 70 percent of all commercial web servers use BSD, this will assure compatibility with the Mac OS X system. This will also allow the Macintosh, UNIX, and Linux markets to be addressed with a single development effort while eliminating some of the licensing concerns associated specifically with Linux.
Chapter 1 / Design Requirements |
7 |
|
|
The Development Teams
Management realizes that a project of this scope has never been undertaken within the organization before. While it is believed that a cost savings can be realized by initial multiplatform support, they also are aware that the project can go over budget and be improperly implemented without solid design and management from the start. They have chosen to select a management team that provides a dedicated design architect and project manager. These two individuals will manage the design, implementation, and deployment from start to finish. They have also chosen to have three team leaders, one each for the hardware, device interface, and user application groups. Each team leader will report directly to the project manager and architect. Each team will be responsible for a very focused part of the project.
Hardware Group (Embedded Device
Design/Implementation)
The hardware group has been developing stand-alone electronic controls of this type for many years. But this will be the first time that an external interface has been added for the purpose of monitoring and controlling via a personal computer. This will require some change in thinking from prior products in how to handle control logic. In the past, all control has been internal to the device. Now the hardware group will have to consider what changes need to be made to allow the device to be monitored and controlled from an outside source or from the keypad of the device.
Chapter 1
8 |
Chapter 1 / Design Requirements |
|
|
Device Interface Group (Device Interface and
Device Drivers)
There is a systems department within the main IT group that routinely writes applications that extend or interface to the operating system core. But their experience is limited to the systems on which they run their business applications. Taking this into account, management has decided to use existing device drivers wherever possible. This will reduce the amount of custom work needed but will still require support for multiple platforms. So, through a collaborative effort with the hardware engineers, the focus will be to develop device interface software that provides a consistent application interface across all platforms.
User Application Group (User Applications for UNIX and Windows)
The applications group of the IT department feels very comfortable with this task. But they have never before supported multiple operating systems for the same application. They are concerned about making the best use of cross-platform tools to maximize their development efforts while minimizing the amount of redundant work needed. They also have never been involved in developing a device protocol or hardware device interface. They are concerned about the learning curve needed to make this happen.
Concerns and Issues
Since the hardware group has never built a product with RS-232, USB, or Ethernet interfaces, there will be a definite learning curve in implementing these interfaces in both hardware and software. There are also concerns about understanding what changes in logic and components will need to be made to get a working system. To aid in the prototyping stage it has been decided that off-the-shelf solutions should be used to design the
Chapter 1 / Design Requirements |
9 |
|
|
products and gain an understanding of the logic and component changes that will be required for the finished products.
The software group will need to research the cross-platform solutions that are available to make a single-source solution a reality. Since the tools they have been using are exclusive to Windows, they will also have to learn UNIX and Linux development. Most important of all, however, they will need to learn how UNIX and Windows differ. The systems group has been given the job of defining the device drivers to make the thermostat and PC talk. They must gain the knowledge needed to properly define working protocols that can bridge not only Windows, UNIX, and Linux, but the embedded system side as well. All three groups will work together to define a standard message protocol so the device can communicate through software with the systems group taking the lead in protocol development.
Platform-Independent Software
Requirements
Making a user application platform independent is not only a high priority but also of great concern. To gain the best experience and choose the best implementation strategy, two development approaches will be pursued. The first approach develops a cross-platform solution by using commercial products for the development efforts exclusively. To expedite the development effort, the selected commercial products must work identically on each platform. Each separately hosted tool must compile the source code identically with a resulting program that looks and behaves identically on every platform supported.
Management is aware the device drivers will have to be supported separately for Windows and UNIX/Linux. Even so, the preferred approach is to use existing drivers if possible that are already supported by each system. This would limit the development effort to writing a shared library that would give each driver
Chapter 1