> ## Chapter 2. Overview

> The DeviceMate hardware and software provide a way to network-enable an embedded device. Connecting any device with RS232 to a DeviceMate unit using a serial connection (CMOS-level signals can be used if the DeviceMate unit is a Rabbit core module), gives the device a gateway to local networks and the Internet.

> With DeviceMate hardware and software, your embedded device can effectively send e-mail and serve web pages. It can also upload files to a file system that was previously set up on the DeviceMate and then update variables referenced in the files. This makes it possible to remotely monitor I/O on the device with a web browser.

> The DeviceMate can also act as an external watchdog for the embedded device (aka "target"). Rabbit-based embedded targets can be reprogrammed remotely via the DeviceMate.

> DeviceMate software includes library support for programming both the target embedded controller and the DeviceMate controller. Since there are two controllers in a DeviceMate system, there are two sets of software components: one on the DeviceMate unit and one on the target. Application programs run on both the DeviceMate unit and the target.

> Sample programs for the DeviceMate unit are in `samples\dmunit\`. Sample programs for a Rabbit-based target are in `samples\dmtarget\`; for nonRabbit targets they are in `samples\dmtarget\Arch\`. See "Sample Programs" on page 5 for more information.

> There are several sample programs provided for the DeviceMate unit. As with all sample programs, they are in source code form. They all can be used with any of the many sample programs provided for the target. For most features, you simply set some macros and, if necessary, set up the network addresses, then you compile and load the application with Dynamic C to the DeviceMate. Some features require additional programming on the DeviceMate unit.

> You program your embedded target to talk to the DeviceMate via a serial port using the DeviceMate subsystem APIs provided.

> ### 2.1 Hardware Connections

> For details on hardware connections, please refer to the DeviceMate Getting Started Manual. The following figure is a quick look at the hardware connections.

> Figure 1. DeviceMate Connected to an Embedded System

> ### 2.2 Software Components

> The DeviceMate feature set comprises:

> - E-Mail
> - File System
> - Message Logging
> - Remote Monitoring of Target I/O
> - Remote Program Download (Rabbit-based targets only)
> - Serve Web Pages
> - TCP and UDP Sockets
> - Update Variables on Web Pages
> - Watchdogs

> Several software subsystems implement the DeviceMate feature set. All of the subsystems used by the target are described in Chapter 3 starting on page 9. All of the subsystems used by the DeviceMate unit are described in Chapter 4 starting on page 29.

> #### 2.2.1 Layers of Communication

> Many of the subsystems are clients of eXtended Target Communications (XTC). XTC provides a reliable transport layer. But, as the flowchart below indicates, subsystems can call Target Communications (TC) routines directly, as can applications. If XTC is not used, then packet delivery to the peer is not guaranteed.

> #### 2.2.2 Sample Programs

> The sample programs run in pairs (except for `loader.c`).

> Table 1. Application Pairs on the DeviceMate Unit and the Target
> Application on DeviceMate | Applications on Target
> devmate.c | act_open.c, dns_look.c, log100.c, pas_open.c, smtp.c, tcp_time.c, udp_echo.c, var.c, wd.c
> devmate_2flash.c | act_open.c, all.c, dns_look.c, fs.c, fs_block.c, fs_gen.c, fs_tiny.c, log100.c, pas_open.c, smtp.c, tcp_time.c, udp_echo.c, var.c, wd.c
> devmate_fs.c | act_open.c, all.c, dns_look.c, fs.c, fs_block.c, fs_gen.c, fs_tiny.c, log100.c, pas_open.c, smtp.c, tcp_time.c, udp_echo.c, var.c, wd.c
> devmate_loader.c | act_open.c, all.c, dns_look.c, fs.c, fs_block.c, fs_gen.c, fs_tiny.c, log100.c, pas_open.c, smtp.c, tcp_time.c, udp_echo.c, var.c, wd.c
> devmate_zconsole.c | act_open.c, all.c, dns_look.c, fs.c, fs_block.c, fs_gen.c, fs_tiny.c, log100.c, pas_open.c, smtp.c, tcp_time.c, udp_echo.c, var.c, wd.c
> fs.c | fs.c, fs_block.c, fs_gen.c, fs_tiny.c
> fs_flash.c | fs.c, fs_block.c, fs_gen.c, fs_tiny.c
> loader.c | Not applicable.
> logxtc.c | log100.c
> tcp.c | act_open.c, dns_look.c, pas_open.c, smtp.c, tcp_time.c, udp_echo.c
> var.c | var.c
> wd.c | wd.c

> To run the sample programs, follow this sequence of steps:

> 1. Connect the programming cable to your PC and the DeviceMate.
> 2. Connect power to the DeviceMate unit.
> 3. While running Dynamic C v 7.10 or later, configure and compile one of the sample programs for the DeviceMate. See "Applications Running on the DeviceMate Unit" on page 29 for configuration information for these programs.

> NOTE | In the documentation for Dynamic C the term "target" is used to refer to the controller board that is connected to Dynamic C via the programming cable. When "target" is used by Dynamic C it is limited to that definition. When using Dynamic C, any menus, dialog boxes, or other messages that use the term target are (almost) NEVER referring to a device that is serially connected to a DeviceMate unit. Dynamic C is (almost) ALWAYS referring to the controller board that it is connected to it via the programming cable. The exception is when using the remote program download feature. After the Ethernet loader is running on the DeviceMate unit, Dynamic C will recognize the device serially connected to the DeviceMate as the target.

> #### 2.2.2.1 For Rabbit-based Targets:

> 1. Disconnect power to the DeviceMate.
> 2. Disconnect the programming cable.
> 3. Connect the programming cable to the target.
> 4. Connect power to the DeviceMate and target.
> 5. While running Dynamic C (version 7.10 or later), compile the application to the target and run it. For example, to check out the functionality of the watchdog subsystem, open the file `samples\dmtarget\wd.c`. Hit F9 to compile and run the watchdog application.

> #### 2.2.2.2 For nonRabbit-based Targets:

> The initial setup for all sample programs is the following:

> 1. Create a base directory on the target device (or development machine). The following steps assumes this directory is called `dm`.
> 2. Copy the target-specific `.zip` or `.tar` file to `dm`.
> For example:

>     CD dm
>     COPY e:\dc710\samples\dmtarget\arch\i386\tc_bc.zip

> or, for Unix-based systems:

>     cd dm
>     cp /cdrom/dc710/samples/dmtarget/arch/sparc_sol8/tc_solaris.tar

> 1. Unpack the archive.
> For example:

>     PKUNZIP tc_bc.zip

> or, for Unix-based systems:

>     tar xvf tc_solaris.tar

> 1. Examine the README files for detailed instructions.
> 2. Configure the library. This means editing `dm/tc_conf.h` to accurately reflect the target machine architecture. It is recommended that the debugging flags be defined, at least initially.
> 3. If the target is not one that is supported "out of the box," you will possibly need to write some adapter code. See "Porting Guidelines for NonRabbit-Based Targets" on page 101 for directions on how to do this.
> 4. Compile the library and samples using the "make" command.
> 5. Connect the serial port of the target processor to that of the DeviceMate.

> To run a particular sample:

> 1. Ensure that DeviceMate and target configurations match, especially serial port speed.
> 2. Run the appropriate DeviceMate sample program (e.g., `devmate.c`), with or without Dynamic C debugging (stdio window etc.). We recommended running with the Dynamic C programming cable connected and the debugging flags turned on in `tc_conf.lib`.
> 3. Execute the appropriate sample program on the target.

> ### 2.3 Further Programming

> The sample programs can be used as templates for further code development. Depending on the application running on the embedded system, this could be very little or quite a bit of design and coding work.

> Users can also develop customized subsystems. Information needed for doing that can be found under Guidelines for Writing Custom Subsystems.

> #### 2.3.1 Faster Debug/Development

> With a Rabbit-based target, using two programming cables and Dynamic C project files allows for a faster debug/development cycle. The default project file, `default.dcp`, uses COM1 for serial communication. Use the File | Project | Save As . . . menu option to create a project file with a descriptive name, such as `dmUnit.dcp`. Then go to Options | Communications and choose COM2. Again, use the File | Project | Save As . . . menu option to create a new project file with a descriptive name, this time something like `dmTarget.dcp`. Now you can run two copies of Dynamic C side by side, each using a different project file with the correct comm port for the controller it is talking to.

Z-World http://www.zworld.com Voice: (530) 757-3737 FAX: (530) 757-3792 sales@zworld.com