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

Time – Set Time of Day

When the T menu option is selected the time display will appear as follows:

Figure 6-4

To change the time, the user selects the hours, minutes, seconds, AM/PM, or 12/24 hour indicator and uses the up and down arrow keys to make changes. Once the changes are ready to be stored, the user simply presses the Set key to store them permanently.

Date – Set Current Date

The following menu should be displayed after selecting the Date menu item from the main menu:

Figure 6-5

The D in the first column indicates the Date function is being displayed. By moving the left and right cursor keys, the user can select month, day, year, and short or long date display. A short date display shows only two digits for the year while the long date display shows a four-digit year. The date display is numeric only so marketing outside North America will require few text changes.

Chapter 6

Host Interface Type

Once selected, this menu should look as shown below:

Figure 6-6

The interface menu is identified by the capital letter I in the left cursor column. The user can change the active interface by selecting the letter associated with that interface type. The choices are RS-232, USB, and Ethernet. A two-character debug status mode indicator allows debug mode to be chosen during the development cycle. Debug mode is only available if USB or Ethernet have been selected as the host interface type. When debug mode is on, the serial port shows all packet data going between the host and embedded system. The purpose is to do protocol debugging if necessary. This feature will allow the protocol to be quickly and efficiently implemented.

RS-232 parameters are fixed at 19,200 baud, 8 data bits, no parity, and 1 stop bit. Both the USB and Ethernet interfaces contain parameters that can be changed from either a remote terminal or a remote host system. In either case special administrative software must be used. In short, the end user application does not contain the ability to change these parameters.

High Temperature Alarm Trigger

It should be noted that supporting multiple temperature sensors and fan control is not implemented in the prototype. These features are not a part of the initial product offering. The only required support is for the temperature sensor onboard the circuit and the ability to control two fans, one for heat and one for air conditioning.

When selected, the menu should look as follows:

alarm condition will be triggered. The logic line for the air conditioning will be set to a logic level 1 to turn on air conditioning. Fan control will also be set to a logic level 1.

Low Temperature Alarm Trigger

The low temperature alarm trigger shares much in common with the high temperature trigger. When this menu item is selected, the following will be displayed:

Figure 6-8

Functionally, both the high and low temperature sensors are identical in how they are handled.

Note:

There are several temperature sensor devices in the 1-Wire product line. The DS1822 is the lowest in cost at the time of publication. The accuracy of these devices varies depending on which part is used. The maximum high or low setting is determined by the sensor range. When using these sensors it always a good idea to be familiar with temperature range and accuracy to be certain the sensor matches the solution.

uses a standard eight-wire RJ-45 female connector attached to the circuit board. The communications format of the data uses a custom protocol defined later in this chapter.

RS-232

The RS-232 interface will support a common signal ground, as well as one transmit and one receive line. Electrical handshake for the Request-To-Send (RTS) and Clear-To-Send (CTS) lines will also be supported. To facilitate proper voltage levels, a Max232 or equivalent component will be used. The RS-232 requires a total of four processor lines.

USB

Three different approaches are being tested during the prototype phase. The first is a serial to USB converter. This approach allows minimal code changes from RS-232 to USB, theoretically reducing development costs. The second approach combines the USB controller with the microcontroller, reducing code and components. The third approach is unique in that the USB device code is downloaded when the device is booted. This allows soft updates to the USB device by simply rebooting it. This approach also presents some other very interesting possibilities, one of which is building an onboard in-circuit serial programmer for making the microcontroller field-upgradeable.

Ethernet

The Ethernet approach is slightly different. This approach makes the Ethernet portion of the prototype an intelligent module. We have chosen a standalone Ethernet controller from NetBurner. This eliminates the microcontroller for the embedded system having to be involved directly with the TCP/IP functions or IP addressing. This approach allows the microcontroller to send and receive data serially from the Ethernet circuit without being

concerned about IP address assignment or providing a TCP/IP stack. This approach allows the embedded system to immediately be put on a LAN or WAN. Using this approach will make the Ethernet controller a sub-assembly that is totally outsourced. While this may appear to increase the cost of the end product, that may not be the case. The reduced labor in board development, procuring and testing TCP/IP software, and support code in the microcontroller may make this a very cost-effective solution. The other approaches use a single chip Ethernet transceiver to convert the packet data to Ethernet packets but not using the TCP/IP protocol. For the prototype a separate Ethernet card will be installed in the host. This will allow direct communications with the Ethernet controller using the TCP/IP protocol. To make this approach work on a standard LAN or WAN, a TCP/IP protocol implementation will need to be provided. It is yet undetermined if there is available memory in the selected processors to implement this option.

Host Side Design

Device Layer

On the host side of this system the design calls for a singlesource driver and user application. This is accomplished by developing a shared library or DLL that provides standard calls to the application layer and platform-dependent calls to the system layer. Essentially this middle layer code will handle all platformspecific driver issues. We can do this because no low-level device drivers are being created from scratch. We have chosen components that either include device drivers for the necessary platforms or can be addressed using standard OS drivers.

Chapter 6

Application Layer

The end user application is required to use the same source code base across all chosen platforms. Several approaches are being tested to accomplish this requirement. The first approach is to use development tools that produce the same look and feel from the same source base on all chosen platforms. The first selected tool is the Borland compiler suite. This is a commercial product that provides a Windows and Linux development environment in the same box. The user interface and supporting logic will be developed using these tools and including the proper shared library for device access. The second approach will use a development framework or library to create the user interface component. By using a cross-platform compiler the accompanying business logic will be compiled for the specific target using a single code base. Using this approach two different types of development will be attempted. This first will use the GNU compiler tools for single-source business logic and wxWindows for the cross-platform user interface. The second approach will use the Borland C++BuilderX product, which provides a cross-plat- form compiler, editor, and debugging environment. The Borland product provides a tighter integration of these tools for the developer while the GNU approach has no dollar cost associated with it. Using the GNU approach the editor, debugger, and compiler will be obtained from several different sources and integrated on the development workstation.

Differences between Windows and UNIX

There are several differences between the Windows and UNIX (Linux) platforms. These systems are very different in design. In the Windows environment the graphical user interface (GUI) is an integral part of the operating system. It would appear this is done to provide tighter security and less chance of accidental system compromise. In both UNIX and Linux environments the

GUI is treated and executed as any other desktop application. This approach provides a wider array of available GUIs and tighter control over the task scheduler. This results in much finer control over how frequently the task scheduler can service a task. Several of the GUIs available for UNIX and Linux are also available on Windows. This is accomplished by providing a layer that goes between the Windows API and the desktop manager GUI calls. It should be noted that all of the prototypes use this middle tier of code for platform-specific code translation.

The Communication Protocol

To facilitate a platformand interface-independent means of sending and receiving data, a custom protocol has been defined. The protocol definition puts each message into a wrapper that includes the following:

Message Category — 1 byte

Message Type — 1 byte

Sensor ID — 1 byte

Alarm Type — 1 byte

Temperature — 2 bytes

Message ID — 1 byte

Message Size — 2 bytes

This allows for future expansion and variable length messaging without altering the original protocol.

Chapter 6