May 2004, Issue 166

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

TIME TO CONVERT

HIDmaker’s microprocessor test application code is well documented and uses embedded comments to suggest where you might add your application code. PicBasic’s USBIn1 command retrieves any received USB output data packet while HIDmaker’s code unpacks the data and sets the HandleEp1Rcv flag when data is available to you from the host. In a similar fashion, you set the EP1XmtDataReady flag when you have data to send to the host. HIDmaker’s code packs your data and uses the PicBasic USBOut1 command to send USB packets to the host when it requests data.

On the PC side, I opened my serial-based application in Visual Basic. All of the modules and class modules that HIDmaker created for the test application are added to the project. The MSComm object on my main form (Form1) was replaced with the HIDAgentX object. The FRMPROPS.FRM form was deleted because this is the MSComm popup form that allows you to set the serial port properties. The project was saved as USBX10.

Next, the code in the USBX10_M.frm form that produced the test application form had to be eliminated or the necessary code had to be copied from the USBX10_M.frm form to Form1. I chose the latter.

Gone are four routines that deal with the serial port, opening and closing the serial port, and sending characters to and getting characters from MSComm. In their place HIDagent’s routines become the low-level engine that does all the hard work of opening HID devices, accessing HID data items, and packing and unpacking reports. After HIDagent has detected, identified, and bound itself to an enumerated device, its runtime events become accessible.

The Sub ReadRpts() routine periodically transfers data items from an input report. I placed code within this routine to test for new data, manipulate it, and perform an update on the form using the received X10 command (new data). To send an X10 command, I used the CmdSendX10_Click() event to assign values to the data items before requesting a WriteAllReports. 

SALVATION AT LAST

The finished application shows little sign of change (see Photo 8). Two areas of concern popped up while using HIDmaker to help convert the application. First, thanks to Microsoft’s wisdom, all data is treated as signed unless specifically told not to. This results in a popup asking if this should be ignored each time the program is executed. The Windows routine is avoided by setting the Scale mode to a value of one (unscaled conversion only) in the OneHidVar.cls class module file.

The second area has to do with the way I designed the USB device. USB likes to have data available from a device at all times. This can cause a problem for your application if you have new data that is the same as the old. If it is the same, how will the application determine if the data from the device is old or new? Instead of adding complexity using some kind of flag exchange, I don’t provide data to the USB port unless it is new. So, most of the time when the host asks for data, the device will not answer and the host will timeout after a default (default = 5000, 5 s). This causes some rather nasty application lags during periods of no new data (most of the time). Shortening the USB timeout property to 100 ms in the CreateHidObjects routine eliminated it.

Using USB for I/O is no longer as easy as writing to a port. To become a user-friendly interface, USB has made the designer’s job extremely complicated. Luckily, manufacturers are realizing they need to help reduce the burden. Trace Systems’s package shortens the learning curve. HIDmaker, along with its optional tools AnyHID and USBwatch, provides the support needed to make USB come alive for the designer. Trace Systems knows what you need, and it supplies plenty of support documentation like the USB, HID class, and usage table specifications.