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

30	Chapter 2 / Embedded System Design

The Functional Design

Compared to Windows or Linux, the embedded processor is much simpler in design. Less memory, no operating system, and a finite number of peripherals and external device interfaces make the development task easier. Figure 2-3 shows how simple the embedded processor is when developing an embedded application.

Figure 2-3

As you can see, when a button is pressed it will interrupt the program to take action. Temperature readings will occur at a preset time interval and a clock in the thermostat will measure the frequency of the readings. The result will be stored and displayed on the local LCD or transmitted to the host for logging and display. This sums up the defined purpose of this device, but there are two functions that need to be placed in the diagram before we have a completed definition. The first is our power monitor, which will simply increment a counter each time the unit is initialized. The second and final task is the communications handler to the host system. The power monitor will be part of the program initialization, so it will be at the application layer. The communications handler, however, isn’t quite as simple. Data is only sent if the host is connected. In addition, host control can

Chapter 2 / Embedded System Design	31

occur at any time. Because of this, data received from the host will be considered a priority and, if possible, treated as an interrupt. Data going to the host is either the result of an inquiry or a routine temperature update. To handle this properly, inbound host communications will be handled at the I/O level and outbound communications will be handled at the application level. Figure 2-4 shows these additional functions.

Chapter 2

Figure 2-4

We’ve just developed our functional definition of the embedded system. It has to:

Process pressed buttons on the thermostat.

Process incoming data from a host system.

Read temperature sensors at periodic intervals.

Store temperature readings.

Display temperature on LCD.

Send temperature readings to host (if host is connected).

Maintain a count of reset conditions.

32	Chapter 2 / Embedded System Design

The Embedded View of the World

An embedded system sees everything as input or output. A keypress or incoming data is input, whereas data to the host system or LCD display is output. Some embedded processors handle only analog or digital data, while others handle both. This means that events can be either analog or digital, depending on which processor is used.

What makes analog and digital data differ is continuity! Analog data is a continuous voltage while digital data comes in streams. Most embedded processors made today can handle analog and digital input and output. Keyboards, mice, modems, and data displays can all be defined as simple I/O devices.

There are three methods of communications that can be used to interface an embedded system to the world: serial, parallel, and TTL. All of the devices we will use to implement this system are capable of all three types of input and output. Table 2-1 describes each type of I/O including variations on each method as it applies to this project.

Table 2-1: Communications methods

Input/Output Type	Description	Analog/Digital
TTL	Transistor-to-transistor logic. Uses	Analog
	varying voltage levels.
Parallel	Sends single bits on multiple wires at	Digital
	the same time. Uses a clock line to
	synchronize data.
Serial	Sends all data in a single wire one bit at	Digital
	a time. May use separate clock line or
	baud rate generator, which requires a
	clock at both send and receive ends.

All of the communications methods we will implement utilize one or more of these methods or a variation of these methods. How the device communicates to the outside world is very important. Many factors have to be considered when designing an embedded

Chapter 2 / Embedded System Design	33

system of this type. In contrast, when a software product for the desktop is developed, processor speed, memory, and storage requirements are simply defined and conveyed to the end user, and the end user is responsible for meeting these system requirements. Embedded systems are a much different story. If your desktop or notebook computer runs low on memory, you can go to the store and buy more. This isn’t the case with an embedded system. If an embedded system runs out of memory while it is running, the results can be disastrous. At a minimum the system will crash, but depending on the use and purpose of the system, damage to property or life can result.

In the United States, government agencies regulate the requirements of such systems when used in life support or industry. In some cases days, weeks, or even months of documented tests and results have to be done before the device can be put into everyday use. For many years I designed machine control systems for special use in machine and print shops. While these machines were software driven, they were required by OSHA (Occupational Safety and Health Administration) regulations to have hardware disconnects, and if the system crashed it still had to shut down safely. This assured that no matter how confused the software ever got, pressing the big red Stop button would physically disconnect the power, preventing the loss of limb or life, and always guarantee a quick and reliable stop.

These factors should always be considered when designing any embedded system (they actually should be considered in all software and hardware projects as good engineering practices). Power requirements play a vital role in embedded systems. Our system will run in a house or business so we will use power from an electrical outlet. Since this is a new product we will keep it simple. In future generation products we could add a backup battery for time stamping temperature changes or allowing the user to change the comfort level based on time of day or season. A backup battery could assure these settings are saved even if the main power is lost. These considerations together help us determine the type of embedded system to choose for the application. There are almost an unlimited number of devices available and

Chapter 2

34	Chapter 2 / Embedded System Design

most can handle almost any of these tasks. For our purpose our primary requirement is communications based, as the embedded controller needs to communicate with each of the following individually: the host computer, LCD display, input buttons, and temperature sensors.

For this project we will use asynchronous serial communications. This will allow the embedded system to communicate with anything that supports the RS-232 standard. The RS-232 standard was the original serial communication method of choice for desktop computers. In addition to RS-232, we will also configure an additional processor pin to support a clock for communicating with synchronous serial devices. Using a transmit, receive, and clock pin, varying analog voltage levels can be used to send synchronized data. This technique will be used to expand our communications support to USB and Ethernet interfaces.

Serial Communications

Earlier we discussed the methods of communications available to the embedded system developer. It should be noted that these methods are built in and require no additional devices for support. Of course, external components can make the job easier, but these methods can be implemented without external hardware components. Now let’s examine serial communications a little more in depth.

While the term “serial communications” is used in a generic sense, the different methods of serial communications are not. There are many different ways of communicating serially between different devices but they all fall into the categories explained earlier: synchronous and asynchronous. All serial communications techniques send data one bit at a time over the same wire. There are numerous variables associated with the stream of data. How the data is sent — LSB (least significant byte) or MSB (most significant byte) — is selectable; this is known as the byte order and was mentioned earlier. Other variables include baud

Chapter 2 / Embedded System Design	35

rate, character length, number of stop bits and start bits, flow control options, and parity variables.

Asynchronous Serial Communications

Asynchronous serial communications uses only a single data pin but requires the data be clocked at the source and target. RS-232 requires setting baud rate, stop bits, and parity alike at both the send and receive sides. If the settings are not the same, the data will not be properly deciphered or will be seen as complete garbage by the receiver. Following is a flow diagram of how asynchronous data communications work.

			Clock & Data on Same Line
		Baud Rate, Parity, & Stop Bits Define Speed
	Source									Destination
	Embedded	0	1	1	0	1	0	1	1	External
	Device									Device

Figure 2-5

Byte Ordering

Most processors in use today are at least 16-bit processors. This means that if an instruction is 1 byte long, two instructions are processed per clock cycle. When an application is executing between processor memory this is handled automatically, but when we send data between systems of different processor types, confusion can quickly arise. Some processors handle data from the low-order bit to the high-order bit. This means the byte stream is handled as executed. But some processors handle the data high order to low order and then process the data after performing a swap. If you are sending data between processors that handle byte ordering differently, be certain to swap the bytes correctly or the data could get mangled.

Chapter 2

36	Chapter 2 / Embedded System Design

Baud Rate

The baud rate is the speed at which the bits are sent over the serial line. Timing is arranged by calculating the delay between characters at a given clock rate. This time factor is then used to transmit the data. At the receiving end, the same delay is used to reassemble the data bits to form characters. Baud is represented in kilobits per second (K). You can calculate the actual number of characters sent and received by adding the start, stop, character length, and parity bits together and dividing the baud rate by the result. This will give a pretty close estimate.

Character Length

This is the number of bits in the actual character. Usually 6, 7, or 8 are the choices. In the early days only 6 bits were used, but today 8 bits is a typical character length.

Start and Stop Bits

A start bit is actually a synchronization bit that indicates the start of a character is being transmitted. The start bit is represented in a transition from a negative voltage (also known as a mark) to a positive voltage (also known as a space). Stop bits are always represented as a negative voltage (mark). Depending on the character frame size (which is determined by baud rate, data bits, and parity), the number of stop bits can be 1, 1.5, or 2.

Flow Control

There are several types of flow control that use both hardware and software. Hardware handshaking uses control lines to signal transmit and receive conditions. Data Set Ready (DSR), Data Terminal Ready (DTR), Clear To Send (CTS), and Request To Send (RTS) are the standard hardware handshake signals for RS-232. This translates to two additional control lines being used for hardware flow control. There are also software flow control signals — XON and XOFF, which stand for Transmit On and

Chapter 2 / Embedded System Design	37

Transmit Off, respectively. Both techniques are used in RS-232 communications. If you don’t want to use two additional processor pins, then use software flow control if you aren’t transmitting high volumes of data.

Parity

This is the number of 1’s at the end of each character. Even, Odd, or None are serial communication selections. These represent 1 (Odd), 2 (Even), or Don’t care (None). Just as start and stop bits are used to identify the beginning and end of a character frame, the parity value is used to provide a consistent number of bits for the actual character.

Synchronous Serial Communications

Synchronous communication requires two lines between the devices. One line carries the clock pulse while the other line carries the data. This method allows data transfer speeds that are governed by the processor speed without setting baud rates, parity, and other settings. Data transfers occur at the clock rate of the sender. Most embedded processors today support data rates as high as 150 MHz. A slower embedded processor would send the data at the clock rate. The embedded processors we will be using range in speed from 4 MHz to 50 MHz. Figure 2-6 shows a synchronous communications diagram.

Synchronous communications define a separate data and clock line. The sender always provides the clock so the receiver can synchronize data transitions. Since the clock is provided by the sender, data transitions are guaranteed to be correct and there is no need for setting baud rates, parity, or stop bits. Faster clock rates allow faster data transfers without any additional software.

Chapter 2

38	Chapter 2 / Embedded System Design

Source		01101011 = 107 Decimal		Destination

	Data			0		1		1		0		1		0		1		1		Data
Embedded																					External
Device																					Device
	Clock																			Clock

Figure 2-6

Comparing Asynchronous and Synchronous

Communications

You may be asking why asynchronous data transfers would be used since they require more effort. RS-232 is an EIA (Electronics Industry Association) standard and was one of the first asynchronous standards defined by the EIA. RS-232 baud rates are supported by almost all devices and use a separate baud rate generator rather than the system clock. While synchronous data transfers are much faster by comparison, the higher speeds are only good for short distances unless high-quality cable is used. This makes synchronous data transfers more cost effective for short distances, while asynchronous methods are more cost effective for longer distances because less expensive cable can be used. RS-232 is also a standard at the signal level so the interface will always work between different devices when it comes to data handling. RS-232 defines handshaking between devices. In each RS-232 session one device is defined as Data Communications Equipment (DCE) and the other as Data Terminal Equipment (DTE). Over time there have been some misunderstandings on how to define DTE vs. DCE, which have led to communications problems. If you use RS-232, always be certain to make one side DCE and the other DTE or you may have difficulty sending and receiving data.

Chapter 2 / Embedded System Design	39

Synchronous Transfer Types

Synchronous data transfers have been around for many years. This method of communication was originally used by IBM as a means for remote terminals to access mainframe equipment. This technique allows high-speed data transfers even in large networks with high data traffic volume. Synchronous data transfers differ in software implementation. I2C, SPI, and Dallas 1-Wire are all variations of synchronous communications. We can also define our own protocol or just shift data in and out by simply defining the clock and data lines and sending the data.

This project will use synchronous data transfers for data exchange with the RS-232, USB, and Ethernet controllers, which will be on the same board as the embedded controller. This makes internal data exchange easy and fast and requires minimal software so we won’t be using all of the embedded system resources to send and receive characters. This technique also simplifies software development because we will always be only one layer away from the actual hardware communicating with external systems.

Parallel Data Communications

Parallel communications are not used in this project but have been considered. To round out your knowledge of communications techniques a short description of how parallel communications work is presented here. Parallel communications are common for moving large amounts of data very quickly on slower processors. Printer manufacturers use parallel communications to allow the printer to keep pace with constant data delivery. Parallel communications allows printer makers to move the data to the print head pins a full character at a time. This also increases printing speed by a factor of 8 since all 8-character bits are transmitted at the same time. The following diagram illustrates how parallel data communications work.

Chapter 2