The USB code generated by the HIDmaker FS package for the USB peripheral must be compiled and programmed into the target microcontroller before it can become part of a working USB peripheral application. The same compile-load-run idea goes for the HIDmaker-FS-generated USB code on the host side.

If you don’t want to code your peripheral USB application code in assembler, C compilers currently supported by HIDmaker FS include Microchip’s C18 and the HI-TECH PICC-18 C compiler. On the host side, your choices are Visual Basic 6, Delphi, and C++ Builder. I stuck with the basics and used MicroEngineering Labs’s PICBASIC Pro compiler on the peripheral side and Visual Basic 6 on the host side.

The HIDmaker FS wizard gave me the choice of creating a normal device, a composite device, a soft-detach device, or a complex device. All I really wanted to do was connect my LAB-XUSB board to my PC via USB. So, I clicked on the normal device. All I needed was a single USB interface and a simple USB configuration. The USB advisor told me that this was the simplest device and that I could use it in a lot of applications. I assumed that as soon as I figured out how HIDmaker FS moves data, I would then move on to bigger, more complex USB projects.

Just for grins, let me walk you through the process of building a USB project called USB Widget. For our purposes here, assume the USB Widget is manufactured by Circuit Cellar and has a USB vendor ID of 1229. Let’s also assume that the brass at Circuit Cellar has given release 1 of the USB Widget a product ID of 2006. In addition, the Circuit Cellar USB programming staff has agreed to cc_widget as the device’s variable name. To prepare for this example, I entered all of the aforementioned information into the HIDmaker FS wizard’s Project Information window.

I wanted to move data back and forth between the USB Widget and a host PC. Because this is a basic device, only a single configuration and a single USB interface were required. If you don’t believe me, just ask the USB Advisor.

I want to show you the code and its relationship to the data as it’s entered in the HIDmaker FS Visual Data Designer. So, the USB configuration for the USB Widget (Configuration 1) is Widget_Config and the USB interface (Interface 0) is Widget_Interface_0. 

Let’s keep it simple and transfer only 1 byte to the USB peripheral from the host and 1 byte from the USB Widget to the host PC. Within the HIDmaker FS Visual Data Designer, let’s define an 8-bit variable called widget_inputdata and a second 8-bit variable called widget_outputdata.

Because I can’t programmatically send and receive via a USB peripheral application at this point, I set up some test values for the two 8-bit variables, which was as simple as clicking on the Test Values tab in the Define Data area in the HIDmaker FS Visual Data Designer. I assigned 0xAA to the widget_inputdata variable and 0x55 to the widget_outputdata variable. After I defined my data to HIDmaker FS and set up my test values, the HIDmaker FS wizard informed me that I must select USB IN and USB OUT endpoints at this time. Again, keeping it simple, I clicked on and selected EP1 In and EP1 Out. The next HIDmaker FS wizard window enabled me to select PICBASIC Pro and Visual Basic 6. 

I then clicked on the Next button. This provided visual copies of both peripheral and host source code in my selected compiler formats. Now, let’s scan the peripheral USB code to see if we can find any references to the data that I entered in the HIDmaker FS wizard and Visual Data Designer.

The stuff we’re looking for is in Listing 1, which is a combination of code snippets gleaned from the multitasking PICBASIC Pro USB source code generated by HIDmaker FS. Recall that I assigned test values to the input and output USB variables, which are also defined as byte variables.

HIDmaker FS doesn’t generate application code to do anything with the USB peripheral’s received data. It does, however, allow for the test value to be sent to the PC host. Adding application functionality is the programmer’s responsibility.

I selected Endpoint 1 in the HIDmaker FS wizard. This is reflected in the inline assembler code in Listing 1. Note that the HIDmaker FS code also provides services to pack and unpack data that’s sent and received over the USB link opened with HIDmaker-FS-generated code.

The 8-bit widget_inputdata and widget_outputdata variables are also defined in the Visual Basic 6 source code (see Listing 2). Note the use of the device variable cc_widget I defined earlier with the HIDmaker FS wizard in both the send and receive Visual Basic 6 subroutines. The device variable cc_widget isn’t used on the USB peripheral side. Just in case you’re wondering where all of the product data went (vendor and product ID numbers), it’s all in a Visual Basic 6 constants file, which was also generated by HIDmaker FS.

OK. Enough of this analyzing stuff from the HIDmaker FS set-up process. I used the HIDmaker FS wizard and successfully generated some good USB peripheral and host code. Let’s put it all to the test.

I did nothing but open and load the Visual Basic 6 project that HIDmaker FS generated and hit the Run button. The Visual Basic 6 program then popped up a window telling me that it couldn’t open USB Widget. That was a good thing because I hadn’t programmed the USB peripheral code into the PIC18F4550 on the LAB-XUSB board yet. 

I had no problem compiling the PICBASIC Pro code. The new USB Programmer worked flawlessly. After the programming was completed, the Windows USB Device Found bubble appeared in the bottom right-hand corner of my screen. I continued to click the OK button in the “Can’t open USB Widget” window in the Visual Basic 6 test program. This performed a retry operation.

A short time later, I was greeted by the “Opened/Connected” messages shown in Photo 3a. I then punched the Read All Reports button in the Visual Basic 6 test GUI and received the upper half of what you see in Photo 3b. This response proved that the host portion of the HIDmaker-FS-generated code spoke successfully with the peripheral USB Widget, which, at the request of the host, transmitted the test value of 170 decimal (0xAA) to the host via the USB link. 

(Click here to enlarge)

Photo 3a—Very little brain strain went into getting the connected/opened messages. If you have no interest in the details behind the USB protocol, you can write a useful USB application “in the blind,” so to speak. The idea is to let you concentrate on your data and application without having to know about what’s going on in the USB forest. b—All data direction is referenced to the PC. So, widget_inputdata is what is sent to the host PC. widget_outputdata is what the host sends to the USB peripheral. You can see my test values and their assignments in this shot.

Clicking on the Send All Reports button didn’t do much because I couldn’t see any physical peripheral reaction to the transmission from the host. I hadn’t coded anything to force the peripheral to use the data it got from the host, so nothing should have happened. I fixed that.