May 2004, Issue 166

USB in Embedded Design (Part 2):
HIDmaker Converts an Application

---

HUMAN INTERFACE DEVICE

As its name suggests, a HID has to do with devices that interact with you. This covers numerous input and output devices (e.g., keyboard, mouse, steering wheel, rumble pack, and joystick). Many monitors have an embedded HID device, which is used for screen configuration rather than video. In actuality, a device does not need to interface with you to be a HID. If your device’s data requirement fits within the HID class’s specifications, you’re golden.

My conversion project fits within this specification. I needed to be able to transfer 3 bytes out of the PC to the interface or 2 bytes into the PC from the interface.

X10 transmissions are slow because they are based on 60-Hz zero-crossings. X10 commands require about 0.5 s (22 60-Hz cycles) to be completed on the power line, so you don’t need to be worried about exceeding available frame times. As far as sending data from the PC, the interface is designed to transmit an acknowledgement of received data (loop back); therefore, loss of data because the interface is busy is handled by the host application expecting looped-back data.

On the interface side, I had to create the appropriate descriptor tables and change the interface application code to make use of the USB hardware in the micro. Assuming the generic HID driver is usable on the host (PC), I had to change the data exchange routines in the application from serial to USB. 

HIDmaker

Trace Systems looked into the future and built a product to get you up and running quickly with USB. HIDmaker was designed for use with the HID class, so no device driver programming is required. You get all the benefits of USB with less work than RS-232 serial because it does the hard work for you!

HIDmaker creates two documented programs—one for the PC and one for your microprocessor—that already communicate with each other using USB. The programs, which are built around the data that you describe, are written for Microchip USB PICs in your choice of environments: PicBasic Pro, Microchip MPASM, CCS C, or Hi-Tech PICC. On the PC side, HIDmaker supports Visual Basic 6, Delphi, and C++ Builder. (These environments are the first to be supported by HIDmaker with other microcontrollers and manufacturers to follow.) It’s a perfect fit for this project because I originally used a PIC (and PicBasic) for the device and Visual Basic for the application.

Photo 1 shows the opening HIDmaker screen. The program is set up in the familiar Wizard style. After you add the required information to each page, click the Next button to move on. You can save the project file and exit any page. Loading the project file brings you back to where you left off.

(Click here to enlarge)

Photo 1—HIDmaker simultaneously generates programs for the peripheral device and the PC. The programs can communicate with each other over the USB via the HID class. Even complex interfaces can be modeled with HIDmaker.

To begin the HIDmaker process, select a device type. This tells HIDmaker how complicated your new device is. The device in this project is simple. More complex devices have multiple, independent types of functionality (a combination keyboard/mouse).

On the second page, you name your project and select a location for the files that HIDmaker will produce. You also add information like the vendor ID and project ID, which are required by Windows to identify your device. Any device sold commercially must have a vendor ID from USB Implementers Forum.

Notice the various boxes labeled “Use in F/W.” If checked, the optional information can be placed in device firmware by HIDmaker to be discovered through enumeration by the host.

HIDmaker offers two types of help. The “I need more help...” button provides context-sensitive help for using the controls that are currently visible on the screen. The USB Advisor button gives advice about appropriate inputs, what the inputs mean, and how they relate to the process.

The third page gets down to the nitty-gritty. I’ve already indicated that this is a normal device. As such, it has a single configuration. As you can see in Photo 2, most entries already have selections; these are the most common usages, but alternatives can be selected.

(Click here to enlarge)

Photo 2—Most projects can use the normal device selection. They need a single interface defined. Complex devices require you to define an interface scheme for each configuration.

If you want the USB interface to supply power to the device, you must also indicate the device’s current consumption. Because the total current available through the USB interface is limited, the host uses this value during enumeration to determine if there is available current to allocate to the device.

As you know, low-speed devices are limited to two kinds of transfer types, control and interrupt. I chose to use interrupt transfers to ensure periodic transfers. Because I need data to go in both directions, I choose EndPoint1 IN and EndPoint1 OUT. The host creates separate pipes (virtual connections) between it and the device endpoints based on this information. Note that you also get to indicate how often you want each transfer to take place.

Only one more bit of information must be defined: the data that will be transferred. Clicking on the Define Data button brings up the fourth and final page (see Photo 3). The data for this project consists of three values going to the device (using out endpoint 1) and two values going to the PC (using in endpoint 1). This page has three buttons on the left and a large drawing area. Use this page to create data items—one for each variable used in each pipe.

(Click here to enlarge)

Photo 3—Data items can be placed in logical or physical collections. Collections aid in understanding how the data items are used but do not affect how the data is actually handled.

The two lower icons on the left—Physical Collection and Logical Collection—help you indicate which data items are grouped together. They can be placed in the drawing area as placemats for the data items. For instance, you may want to use two Logical Collection placemats, one for the three out data items and one for the two in data items. These don’t actually affect how the data will be defined; they merely aid in documentation. For each item of data, click the Data Item button and place an icon in the drawing area. Now all that’s left is to define each item.

When the mouse hovers over a data item, a pop-up shows a description of the item’s configuration. By double-clicking on the item, you’ll see that data item’s editable properties (see Photo 4). I changed each data item’s name to the variable name I use in the applications (again, to help with documentation).

(Click here to enlarge)

Photo 4—Although each data item must be fully defined, many default selections can be used. Take some time to make sure your data will be handled with the respect it deserves.

The data type must be selected based on the endpoint, either input or output, for this project. The usage info consists of a combination of two numbers: a Usage Page number and a Usage ID number, which is the number of an item in the Usage Page. A Usage ID represents some particular function or feature of a device, and the Usage Page is a collection of Usage IDs that belong in the same category. The HID usage table’s specification defines and documents nearly 1600 combinations of Usage Page and Usage ID. Click the Browse Usages button to pick from a list of all the standard usages that were recently defined as well as a modest number of Vendor Defined usages.

It is important that every data item you define has a distinct Usage ID; this is the only way that the HID class, as implemented by the Microsoft Windows HID API, can identify and locate your data items. I chose to use the vendor-specific User Page (0xFF, the default) and User ID’s 0x00–0x04 for the five data items. Notice that you can define the maximum and minimum values for each data item. This, in turn, determines the number of bits necessary to define your item.

My HouseCodeIn/Out items require 8 bits. The UnitFunctionCodeIn/Out and RepeatOut items only require 5 bits each. (The transferred USB data packet contains data items packed together to save every bit possible.) 

Although this project is fairly simple and the default values are used in most cases, you can see that the data properties offered are both flexible and complex. HIDmaker’s guidance isn’t fully appreciated until you look at the output generated by compiling and building sample applications based on all the input that you complete.