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

Source

Device

Figure 2-7

The Communications World of

Windows and UNIX

Because embedded processors are used in out-of-the-way places and because they usually manage some type of mechanical or electrical control or appliance, the developer must be familiar with the actual hardware. Windows and UNIX systems were designed to be used by humans. Because of this there are many more layers of software between the hardware layer and the user. Device interfaces are handled at a much lower level, keeping human interaction minimal when using the system to address external devices. To make a system intuitive and easy for a person to use, much effort must go into the design and implementation under the hood. Unlike the embedded system where a single layer acts as the handler of all data, I/O, and user interaction, Windows and UNIX have a presentation layer that communicates with the user, a file handler that reads and writes file I/O, and a device layer that moves data between devices, files, and user interfaces. Rather than looking at the actual electrical signals in a device, the device is opened and the driver acts as the interpreter between the actual hardware and desktop application. This means the programmer doesn’t have to be an electronics engineer to address the hardware. In fact most applications programmers have little or no knowledge of the hardware. They simply open, read, write, and close files or device names.

Chapter 2

computers. A message sent that doesn’t conform to protocol definitions will be ignored. Expanding the system in the future simply requires additional message types, categories, and message fields. To maintain backward compatibility the protocol will contain a protocol version. Adding new message types in the future will increment the version number. This assures a path to expansion while being able to process legacy messages without modifying the hardware in the field.

Communications Protocol History

Protocols have existed in the communications industry for many years. Datapoint developed the ARCNET protocol as the first broadband network protocol many years ago. ARCNET was the basis of what eventually became the Ethernet protocol. Today, Ethernet is the most widely used network protocol for LANs and WANs. Ward Christenson developed the X-Modem protocol in Chicago over 20 years ago as a way to transmit files from one computer to another and assure no data was lost or garbled in the process. These are two excellent examples of why protocols are developed and the functions they serve.

For our purpose a simple protocol will suffice as a simple means of establishing communications between the desktop computers and the embedded systems. We are simply establishing a format by which the two systems can talk and a priority handshake by which each party can take their turn speaking to prevent data collisions. Protocols are implemented every day for many different types of communications. In their simplest form they establish a set of commands or words each party or computer understands. In their most complex form they introduce error checking to make sure every word is spelled properly and used in proper context. Every protocol is different and is based on a specific need or requirement.

Building a good protocol is done in small steps. By illustrating each step we go from concept to working model by checking our query and response tables against our real-world requirements. It is very easy to write down the requirements and

Chapter 2

embedded processor. This allows the host to monitor temperature and temperature alarms and set the temperature alarm triggers, which in this case is setting a high and low temperature for each sensor to act upon. If the temperature range is between the high and low settings, no action is taken. If the range goes above or below those range settings, an alarm condition will cause the embedded system to start the heating or air conditioning and the associated fans for air movement. Addressing each sensor through its unique ID sets temperature ranges. The temperature can be read or a query can be generated to see if an alarm condition exists.

For the purpose of this book we will be controlling a small fan that turns on or off depending on temperature and/or alarm conditions as shown in Figure 2-11. The fans are managed completely by the embedded system through the use of an electronic switch. Since we are working on a small scale, a single byte is output to the switch to turn the fan on or off. Each bit that is turned on will turn a fan motor on. Each bit that is turned off will turn the fan motor off. The single byte used to manage the switch is stored in non-volatile memory, which allows the status

Chapter 2

Host / LAN Connection

Keyboard

Control Embedded

Status Processor

LCD

Display

also allow their display contents to read by location, line, or all character positions at once. Since LCD designs are constantly changing, our protocol will be flexible enough to handle varying device types without making code changes. We have now mapped all the functions of the embedded system. Next we will take this information and implement the protocol.

Designing the Device Protocol

We start by listing the functions of the embedded system and placing those functions in categories. The following table illustrates the functions of the embedded system and the categories we have assigned them.

Table 2-2: Embedded system functions

Next we list the functions monitored by the host systems and assign each to a category. Table 2-3 illustrates these functions and categories.

Table 2-3: Desktop system functions

Chapter 2