USB Development

[NikkiC]

I have a device I am developing that requires 32Kb of configuration data to be uploaded to a PIC. Once the PIC is configured it will be unplugged from the PC and will rarely need updating.

I don't know much about USB, but I have decided USB is the best way to go to. I've heard talk about FTDI and HID devices.

Some altruistic genius has already written the drivers for the USB960x device for CCS. Can someone highlight any reasons why I shouldn't just modify these drivers for my own use for the development of my device? In fact, it just needs a few modifications here and there and that's about it!

Or am I naively missing something crucial?

Nikki

[rwyoung]

Based on past experiences with the FTDI chips, I would definately use them again. As far as the PIC is concerned, it is talking to a serial port. It can be a simple RX/TX port, one with software handshaking or add some more lines and do full hardware handshaking. Very easy on that side. And you can run much faster than HID devices because you can do bulk transfers.

On the PC side it is relatively easy as you can let the FTDI look like a COM port (for example, on my desktop it looks like COM9 to my software). The down side to the VCP drivers is you loose some degree of control over the FTDI chip behavior. Or you can use its "native" mode drivers and have much better control Even in the native mode, the API looks a lot like the API for a serial port but not 100%. And you have much more control over the device and you can do fancy stuff like detect multiple instances of your device and deal with them accordingly.

Hardware additions to the board aren't bad, at the minimum you need the FTDI chip, a USB connector, cyrstal and a handfull of common value Rs and Cs. A nice addition is an EEPROM to hold configuration data for the FTDI so you can customize it a bit. Good notes in the FTDI datasheets and application notes.

FYI, there are some minor issues with WinXP SP1 and the "native" mode drivers but they are pretty simple to overcome. I would expect that FTDI is working with Microsoft to correct the problem with the hardware wizard but as I said, there is a work-around. The good news is you only need to do the work-around once if you add EEPROM to your FTDI chip.

FYI, I don't work for FTDI, just tickled at how easy it made my last couple of USB projects. Ahead of schedule and underbudget for a change!
_________________
Rob Young
The Screw-Up Fairy may just visit you but he has crashed on my couch for the last month!

[Darren Rook]

FTDI is a good solution, but you are forced into a serial port mode. That doesn't bother a lot of people though. But if you want a HID, bulk or multi-interface device the FTDI chip won't cut it.

[NikkiC]

Hi Darren,

That's the thing, why would I want a HID device over an FTDI one? Apart from not having to fiddle with COM ports, what are the benefits?

As far as I can tell, your HID device drivers provide all the functionality I will need.

I can see that Windows 2000/XP has the HID drivers built into its OS which simplifies things a bit.

The USBN9603 chip looks cheaper.

There aren't any royalties to pay?

Nikki

[Darren Rook]

Say you want to have a Mouse, Keyboard, Joystick or Point-of-Sale device. These are standard HID devices and are built into the HID driver which is included in pretty much any operating system. See ex_usb_mouse.c, which sets the descriptor to mouse. All you have to do is compile it and it acts like a mouse, no other driver or software is needed. You can't do this with FTDI, it's stuck as a serial device.

You can use HID to send generic data, so it's not limited to a Mouse, Keyboard, etc. There's an API for communicating and using the standard Windows HID driver.

You can do more, like bulk or isochronous devices. This is possible, but requires you to write a driver or obtain a generic 3rd party driver. The reason you may want to do this is because HID doesn't have the best throughput.

Royalties? Depends. A USB device needs a PID/VID number, and you need to pay the USB organization to get a VID. If you're only producing a small number this may not be a problem. However, you will have the same problem with FTDI so the cost is the same.

Summary -
FTDI: Fast to develop, easy to develop. Chips may cost more. Only a serial device.
USBN960x/PIC16C7x5: Cheaper parts. Longer development time. More flexibility.

[NikkiC]

I see in your device description, usb_desc.h, you use this VID: 0x61,0x04, //vendor id (0x04D8 is Microchip, or is it 0x0461 ??)

If only 100 units will ever be made, can that be left as is or am leaving myself open to a future legal quandary?

Nikki

[rwyoung]

[bertronicom]

I've worked on many projects using a FTDI module with paralell port (very fast), I'd recomended to you for stream data from your PIC to Host. Easy to program and working for any Winxx. I have develped code in host by Visual Basic and work fine.

[dais]

I'm also using ftdi245b for my project, I use dlp 245pb which has ftdi 245b and pic 16f877. IF I call FT_Write it will cost at least 1 ms. I don't know if it is because 1 ms frame in full speed option. Every time I use FT_WRITE, I only send at most 10 bytes. so the throughput is really low. Does anyone know if there is any way to improve the throughput in my case.

Thanks in advance

Simin