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

termination point is known as an endpoint; a client may have multiple endpoints. A collection of endpoints is known as an interface, and a collection of interfaces is known as a connection. A good example would be a multi-function printer. The cable receptacle on the printer would be the “connection,” and each of the following would be controlled by separate software functions: printer, fax, and scanner. Each of these would be a separate endpoint, and as a group would be the printer interface. So the printer would be endpoint 0, the scanner endpoint 1, and the fax endpoint 2. When connected to a PC host the device driver would be broken into three separate functional areas. The complete driver would encapsulate the printer connection, with a device interface that would support separate functions for printing, scanning, and faxing. In short, USB is a layered protocol.

Implementing the USB Circuits

We are going to implement two different versions of the FTDI 232BM chip interface. The first one we will implement is from DLP Designs, a company that builds some real neat USB devices around the FTDI chip. The second interface we will implement is from Parallax and is a little different in the way it was implemented.

The FTDI USB Chips

FTDI is one of the more popular USB chips with companies that want to move from RS-232 to USB with minimal investment in time and resources. The FTDI chips have been around for several years and are easy to use and interface to, and inexpensive. They provide the ability to convert TTL RS-232 data to USB without much effort. Not only do they act as a direct replacement for RS-232, but they offer complete RS-232 handshaking as well and in fact look just like a COM port to Windows, all the way down to using the Windows serial communications drivers.

From a developer’s view, FTDI provides what is termed “virtual COM port drivers” for Windows, Linux/UNIX, and Mac OS X (and higher) based systems. This approach means that these

RS-232 interface, complete with CTS/RTS handshaking. I’ve chosen to cover two different product versions to illustrate how there can be some differences in how vendors implement the FTDI interface.

The DLP-232BM Product

DLP Designs makes several different products that use the FTDI chips. These products range from a simple no-frills RS-232 USB converter to microcontroller based products. For our purposes we will be using the DLP-232BM product, which is inexpensive and provides all the features needed to simply replace the 4-Wire TTL RS-232 interface we just used for Ethernet. The advantage here is obvious — we can reuse all of the software we developed for the Ethernet interface with no change in the BS2 code. That’s right — we will use the code on the BS2 developed for communicating to the SB72 unchanged.

Note:

You may be asking yourself how this can be accomplished since the SB72 provides a many-to-many relationship while USB provides a many-to-one relationship. The answer to that question lies in how and where the many-to-many relationship is handled. If we examine how we are implementing the host interface, we quickly see that the BS2 does not see more than one device from its host communications interface. In other words, all of the code managing the host relationship is in the SB72. So from the BS2 perspective it is only communicating with one host device.

The DLP Designs interface provides legacy support for RTS and CTS, and uses them exactly as RS-232 would. Our TX and RX

data lines are also identical, so the 4-Wire TTL interface we used for the SB72 will work unchanged for the DLP-232BM device. To the BS2 both are simple serial I/O devices that communicate at 9600 baud, 1 stop bit, 8 data bits, and no parity.

USB is designed to be either self powered or externally powered. Remember that a power and ground is part of the USB hardware specifications. In fact, USB can provide power to a

Figure 8-33

For our purposes we will be using just a handful of these pins even though this is a standard 24-pin package. Figure 8-34 illustrates how the DLP-USB232BM is wired for power and communications.

Figure 8-34

As you can see, pins 2, 5, and 7 get connected to Gnd. Since we are powering the DLP-USB232BM from the BASIC Stamp, pins 3, 10, and 11 get connected to VCC (+5) on the BASIC Stamp.

This circuit assumes we are using the power supply we built at the beginning of this chapter. Note how the handshake and data lines are swapped between the USB232BM and the BS2. The four-pin header in Figure 8-34 has pins 0 and 1 crossed for connecting to header CN3 in Figure 8-30.

Testing this is a fairly simple process since no code changes are actually required. To test our handshake, however, let’s enter and run the following program on the BS2 to see how well things really do work.

Running this program attached to any terminal program will produce the following output at the terminal program side.

Figure 8-35

To see if our handshake works correctly, select File | Properties | Configure and set Flow Control to Hardware. Now, connect to the USB port; you will see the same message displayed to the BASIC Stamp Debug screen when connected.

Select Disconnect from the terminal program. The debug screen for the BS2 will begin showing “Waiting..” as shown in Figure 8-36.

Figure 8-36

Figure 8-37

In order to use the USB2SER we must build a converter to get the signals that are available to the proper pins. Figure 8-38 illustrates how the crossover should be done.

Figure 8-38

With those details taken care of you will notice the complete absence of CTS/RTS signals. These have been replaced with ATN, which is connected to the FTDI reset pin. The documentation states this pin is connected to the DTR signal in the virtual COM port drivers. You are probably asking why someone would prefer to use DTR instead of CTS/RTS. There are several possibilities. First, DTR is set manually from most applications that use RS-232 ports. Few standard terminal programs enable the use of DTR and those that do claim its use may or may not correctly set the pin based on the application toggling the pin. That isn’t a problem for us because we are writing our own device handlers, but if you simply wanted to connect using a terminal program, signaling the BS2 to turn data on and off may become a problem.

This device, however, is very useful if you want to use a high-speed data link between the BS2 and a host system. In a case where the host has control of the DTR pin, the serial communications interface on the BS2 can use the ATN pin as a regular RTS/CTS pin, providing the host has software to properly handle turning this pin on and off. Before we run software to test this interface it should be noted there is no reason not to use split speed communications using the BS2 and FTDI interfaces. Data being sent from the host is for control and monitoring commands where data coming from the BS2 contains packets of information regarding temperature status and alarms. Experiment with higher baud rates to see where performance is best. Keep in mind the limitations of the variable storage area of the BS2p and see how fast you can send and receive data. You can also experiment using the direct access drivers, which removes the baud rate limitation completely. I caution you in attempting to send data to the BS2p at high speeds simply due to the same variable space constraints. The BS2p series can operate very nicely at speeds up to 19200 baud. We will look at this more closely in Chapter 11.

The following listing will send data from the BS2 through the USB-Comport interface to a terminal program.