5509A USB example

I believe that the Spectrum Digital example is about as simple as is possible.  The USB library inside CSL does not implement any of the basic responses that are necessary for proper USB operation, so basically all of the code in the Spectrum Digital example is required.  usbmain.c is about the only file where you can delete anything.  The other files, usb_ctrl.c, usb_req.c, and usb_dscr.c are pretty much needed for even the simplest USB implementation - in fact, you will almost certainly need to add some things to those files are well.

Note that I found some bugs in usb_dscr.c which prevent USB Descriptor Strings from transferring properly (many programmers seem to trip over the fact that the C55x has 16-bit char, not 8-bit).  I'm also still learning my way through this code, but I do have my C5506 talking to a host computer.

Have you read the USB 2.0 Specification?  Even if you're designing a Full Speed USB "1" device, you'll need to implement a great deal of code.  USB is fairly complicated, and that's why the Spectrum Digital code looks complicated at first.  Before you can send data out the USB, you'll need to create Device Descriptors which explain to the host computer all the details of the data bandwidth and timing.  One important fact to keep in mind is that you cannot just "send" data, you must wait for the host computer to "poll" for the data, which is why you have to create Device Descriptors explaining to the host computer how much data to poll for.

This is very different from the method you would use for a standard serial port, where all you have to do is set up the correct bit clock rates and then go about sending the data as you please, with optional handshaking.

Anyway, without getting too much deeper into USB, I wanted to suggest that the Spectrum Digital example is not any more complicated than it needs to be.  I assume that we're both looking at the same example - you should be able to recognize the same file names that I mentioned above.

Hi, thanks for the reply and the information.  Can you tell me what bugs you found in the usb_dscr.c file?  Also, I tried just getting that example running on my board, and the dsp side seems to compile and ready to run.  But the Spectrum Digital also says to install some USB drivers from LibUsb-Win32.  Did you use this as well?  After I installed these drivers, I ran the DSP code and plugged in the USB.  Windows seemed to recognize the board and started to install the drivers for it.  I pointed for it to install from the libUsb folder, but it was missing a file, sysusbst.sys, although I don't know if this is the exact file.  I did a search and found that others had trouble using this driver and missing that file.  Would you mind telling me how you got your board talking to the pc?  I would greatly appreciate the help.

I primarily test on Mac OS X, at least in the beginning, so I had no intention of running the Windows DLL anyway.  Since I have experience writing USB firmware, I really only needed the Spectrum Digital example as a starting point.  I basically ignored the code which communicates to the Win32 code.

Fortunately, USB has several levels of operation.  There are a certain number of behaviors which all devices must implement.  The Spectrum Digital code handles these and so I see a device appear on Mac OS X, telling me that the physical USB circuits on my custom C5506 board are working and that there are no errors in the USB data.  Beyond this, USB defines some common Classes, where every device in that Class must implement certain behaviors.  Mac OS X will connect with such USB devices without loading a custom driver.  Finally, there are Vendor Specific Classes which require custom code on both sides.  The Spectrum Digital example does some Vendor Specific stuff which is not actually required.

If your firmware is talking to Windows (and you seem to indicate that it does), then your next task is to identify the Class of your device, if any, study the USB specification, and being the task of implementing it.  I can see how the full example might take you further towards your goals, but I can't offer any advice on that because I'm not even trying to work with Win32 at the moment.  My client does want to support Windows, but that will come after I have the basic USB firmware completed.

As for the problems in usb_dscr.c, you can safely ignore them if you don't need custom String Descriptors.  In my case, I want the manufacturer name and product name as well as a serial number, so I must have working String Descriptors.  However, even with the bugs in usb_dscr.c, you still get a working USB Device, but it merely has blank or missing String Descriptors and that's hardly a show-stopper.

I will try to remember to diff my current sources against the originals to see how I fixed it, but you shouldn't be held up without this.