Bailey O.H.Embedded systems.Desktop integration.2005
.pdf
20 |
Chapter 1 / Design Requirements |
|
|
Figure 1-4
RS-232 Interface
The embedded device provides the desktop system with temperature logging data and control information via a serial cable. From this information the desktop system can send control commands to reprogram the device or override control commands. This control information consists of high and low temperature thresholds that start and stop fans and air-conditioning or heating equipment. When the system is being controlled from a Windows or UNIX host, the monitor replaces the display as the output device and the keyboard replaces the device buttons. The mouse can also replace the up and down buttons as well. The thermostat has limited logging capabilities due to a small amount of memory. As a result the computer will also act as an unlimited storage device for log records. These records can also be formatted and printed by the user using the time and date functions on the computer. This eliminates the need for a real-time clock and additional memory in the embedded device. A serial interface limits us to a single computer connection. It should be noted, however, that the device could manage 64 temperature sensors and 64 fans. Even with a simple serial interface a large building can be easily
Chapter 1 / Design Requirements |
21 |
|
|
monitored and controlled. The following diagram shows how the computer can be used as an alternate control device.
Chapter 1
Figure 1-5
USB Interface
While USB allows a single computer to manage many devices, the probability of doing that is actually pretty small. Normal USB cables are 6 to 8 feet in length. Why support USB when a serial cable allows for greater distances? Simple — some computers may not have an RS-232 interface. Newer systems being built are no longer offering the old serial connection.
Note:
Since USB is now included with every IBM-compatible PC there is no longer a need for serial ports. As a result, manufacturers are warning consumers that the old serial port will be removed from new systems delivered within 12 months.
22 |
Chapter 1 / Design Requirements |
|
|
The following diagram shows how the USB interface offers a many-to-one control solution.
Figure 1-6
Ethernet Interface
Ethernet provides capabilities that RS-232 and USB lack. That’s not to say RS-232 and USB interfaces should not be used; in fact, quite the contrary is true. In reality, an Ethernet interface provides the following benefits:
Peer-to-peer support for the embedded devices
A many-to-many relationship to a desktop computer system
Internet accessibility
X-10 monitoring and control
Unlimited expansion
Chapter 1 / Design Requirements |
23 |
|
|
Peer-to-Peer Device Networking
This architecture has many benefits. These devices can communicate with each other independently from the desktop systems. Using this technique we can build extremely energy-efficient systems by using surrounding zone devices as supplemental control when large temperature swings occur. We can even reroute heating and air conditioning from those zones when necessary. Following is a diagram that shows how device-to-device, device- to-host, and host-to-host communications work.
Device |
Device |
Device |
1 |
2 |
3 |
Device |
Device/Host |
Device |
|
Device Network (Ethernet) |
|
|
Device Network (Ethernet) |
|
|
|
Network |
Internet |
Ethernet LAN Backbone |
Network |
|
Area |
|
Internet |
|
Wide |
|
Ethernet LAN Backbone |
Area |
|
|
|
|
|
Wide |
|
Host Network (Ethernet) |
|
|
Host Network (Ethernet) |
|
Device |
Device/Host |
Device |
Host |
|
Host |
|
Host |
1 |
|
2 |
|
3 |
|
|
|
|
|
Figure 1-7
Chapter 1
24 |
Chapter 1 / Design Requirements |
|
|
Many-to-Many Peer Networking
Using Figure 1-7 it becomes clear how easy it is to manage multiple systems from a single host. But many hosts can monitor a device at the same time even though only one can actively manage the device. Using the above model you can see that local, regional, and long-distance monitoring and control of the heating and air-conditioning devices is easy.
Internet Accessibility
While WAN and Internet accessibility aren’t covered in this book, extending the protocol to support a wide area or international network is easy. The design requirements take this into account, as WAN and Internet control will be a part of future product specifications.
X-10 Monitoring and Control
By using Ethernet, additional devices can be monitored and controlled using the X-10 protocol. Additional fans, heaters, dehumidifiers, and other appliances that assist in controlling the environment can use this same technique by adding adapters or communicating through a host system. Future products will allow expanded intelligence through the use of this network.
Unlimited Expansion Capabilities
Providing an Ethernet interface allows for almost limitless expansion. We can expand devices by adding them directly to the Ethernet backbone or by attaching them through host systems already on the network. The following diagram shows how our devices are monitored and controlled via the Ethernet interface.
Chapter 1 / Design Requirements |
25 |
|
|
Chapter 1
Figure 1-8
26 |
Chapter 1 / Design Requirements |
|
|
Chapter Summary
In this chapter we learned about the project scope and objectives, the design team, communications requirements, and how data and control will flow and be managed. In Chapter 2 we will design the embedded device and develop the communications protocol that will be used to communicate with other types of systems.
Chapter 2
Embedded System
Design
Overview
In Chapter 1 we defined the project scope and addressed issues with each development component. In this chapter we begin the task of designing the embedded system. When we design a network of devices, there are always many design choices to be made. Each of us tends to use technologies we are comfortable with. When we most need to take time to explore technological alternatives is when we have the least amount of time to spend exploring those alternate methods. The old saying “There’s never time to do it right but always time to do it over” is very true in developing complicated embedded systems. In this chapter we break down the function of the embedded system until we have a functional task list. That task list will be used as the foundation for the functional specification and design of the embedded system.
27
28 |
Chapter 2 / Embedded System Design |
|
|
Special Skills
There is normally a clear line separating the responsibilities of software and hardware people. Some of the typical “gray areas” are protocol development and device driver development. Both of these areas are involved with how the hardware and software systems communicate. These areas of development typically overlap both hardware and software groups as shown in Figure 2-1.
Figure 2-1
Device driver development requires a thorough understanding of how the hardware works. But the device driver developer has to also be highly skilled not only at software but also at writing software at the core of the host system’s kernel. Just as important is the design and implementation of communication protocols.
Unlike the device driver developer, the protocol developer is writing software to allow systems of different architectures to communicate. Developing protocols again requires a variety of skills as shown in Figure 2-2.
Chapter 2 / Embedded System Design |
29 |
|
|
Chapter 2
Figure 2-2
As you can see, knowledge of telecommunications is very helpful when developing a communications protocol. Having knowledge of different processors and how they handle character data is very important. Byte ordering is one example of this. The Intel and Motorola processors handle byte ordering in different fashions. Understanding this and other processor-dependent items, like variable size, can mean the difference between a well-devel- oped protocol and meaningless data. When it comes to interfacing different types of devices, a good working knowledge of each device, hardware, and software is a must to properly implement a good working protocol.