Which USB class?

[AlfBaz]

I want to program my stm32f4 discovery board as USB device.
From the host (pc) I want to be able to either send it data or request it to send data.

Looking through the library code provided by STM I see they have various classes available, audio, cdc (Communications Device Class), dfu (Device Firmware Upgrade), hid (Human Interface Device) and msc (Mass Storage Class).

Having a very brief read through the descriptions for each of these classes it would look like cdc may be the class I'm after as wiki recons this class provides an easy path to USB-232

Any thoughts or suggestions?
(I know precious little about USB)

[mrflibble]

USB CDC should do the trick if you want a virtual com port on the PC side.

[AlfBaz]

Thanks for that. If I were to try some simple 2 way data transfer where the device does nothing unless instructed, would I have to create a driver for the PC... Something along the line of what companies like MicroChip offer with their stack?

[JTR]

Not with CDC, you just need to use the inf file provided by microchip with windows. Nothing required for Mac or gnu/Linux.

If you bandwidth requirements are < 64KB/s and you are writing PC side code you would be far better off using hid. CDC is easy but there are a stack of issues with the windows driver. I am not going to even try to list them all but the biggie is the that CDC is PRONE to silently dropping the data IN endpoint and the only way to recover this is to close the port (PC) and reboot the USB firmware  on the micro.

Another option is to use generic bulk. This requires a USB library like WinUSB or libusb or the one provided by microchip (mchpfsusb.dll?) etc to provide the API but it is not as involved as writing a kernel level driver as such.

Generic bulk provides way more bandwidth than HID and somewhat better bandwidth than CDC (and uses the USB bandwidth in a far more social way too.)

[AlfBaz]

Not with CDC, you just need to use the inf file provided by microchip with windows. Nothing required for Mac or gnu/Linux.

Yeah sorry. In my previous post, it should have read "...simple 2 way data transfer without cdc"

If you bandwidth requirements are < 64KB/s and you are writing PC side code you would be far better off using hid. CDC is easy but there are a stack of issues with the windows driver. I am not going to even try to list them all but the biggie is the that CDC is PRONE to silently dropping the data IN endpoint and the only way to recover this is to close the port (PC) and reboot the USB firmware  on the micro.

You'll have to excuse my brain I've been into very wide and varied stuff lately, but these issues with windows, are they pre windows vista? If not then the above is no good for me

Another option is to use generic bulk. This requires a USB library like WinUSB or libusb or the one provided by microchip (mchpfsusb.dll?) etc to provide the API but it is not as involved as writing a kernel level driver as such.

Generic bulk provides way more bandwidth than HID and somewhat better bandwidth than CDC (and uses the USB bandwidth in a far more social way too.)

This rings a bell. In fact your mention of Win/lib/mchpfs-usb helped jog my memory. I remember having a detailed look at these a long time ago but never implementing them.
I might start with cdc just to have it for future use and then move right onto generic bulk

[nctnico]

Not with CDC, you just need to use the inf file provided by microchip with windows. Nothing required for Mac or gnu/Linux.

If you bandwidth requirements are < 64KB/s and you are writing PC side code you would be far better off using hid. CDC is easy but there are a stack of issues with the windows driver. I am not going to even try to list them all but the biggie is the that CDC is PRONE to silently dropping the data IN endpoint and the only way to recover this is to close the port (PC) and reboot the USB firmware  on the micro.

Can you elaborate on this? I've made plenty serial port CDC devices (with NXP's ARM controllers) and never had this issue.

[JTR]

The problem is a numbers game. The windows CDC driver continuously polls the IN endpoint. Have you got data? - reply = NAK. This happens over and over and any available USB bandwidth is consumed with all these short fast transactions that are just a few microseconds.

Should there be a period of noise on the bus some of the transactions may get corrupted. Normally this is not a big issue as in USB there are built in CRCs and retries etc. But with CDC all these transactions are short and fast and therefore it becomes far more likely that the noise may span over three consecutive transactions. It is the noise over the consecutive transactions that causes the host to basically give up on the endpoint. (Actually, this is due to the sloppy software from microsoft that does not avail itself of inbuilt USB requests to the endpoint (SET FEATURE, GET FEATURE, CLEAR FEATURE) that are there to provide a mechanism to recover "bombed" endpoints...)


So to write that in short form - it is the lack of data being sent (therefore many short IN transactions) that causes far greater probability of three strikes and your out.

On windows this happens completely and totally silently. There is no error message (indeed the port may not even be owned by an end application to report to.)  The end result is that there is still a comport that is marked as "working" and the comport will send data out and all control transfers will complete normally. In fact everything accept the data IN endpoint is working and nothing has happened to alert the CDC device, the PC side driver (usb.sys) and nothing past up the chain to any user app.

On top of this there are problems with the way windows handles the opening and closing of the USB handle. If the comport is claimed by a user app windows will not reconnect with the CDC device if it is reset only at the device end. You have to reset the connection at both ends to recover. The PC side app must close the comport then the CDC device must be reset externally.

This is the downside to not having to write any code to control the CDC USB class. You don't get any control when it would be an advantage to have it. 

This problem is quite well known to those of us who write firmware for USB and one of the reasons why the windows implementation of CDC is mourned for being partly ruined.

As this is a numbers game (probability) it is of course possible for someone who has a robust, low noise connection to never see it occur. It is also why someone may see it several times one day and not again for a week or more.

I am sure that there are far better explanations on the web for this issue than what I have posted here. I have seen it discussed on the microchip forum and the keil / ARM forum too. Hopefully I have explained enough to give you the basic idea of the problem and why you may not have seen it yourself. (Half your bloody luck!)

[nctnico]

To be honest one of things I implemented in my serial CDC devices is a USB timeout. When the time-out expires it will disconnect the device, wait 5 seconds and reconnect. This is something which got left in after I developed it. In my PC applications I close/open a com port once I notice something is wrong with it. I must admit though I have not used my serial port CDC devices for prolonged periods of time. Even though I already built in the safety measures it is the first time I've heard about the problem you describe. On the other hand I see the scenario you describe all the time with FTDI serial to USB chips...

[AlfBaz]

Another option is to use generic bulk. This requires a USB library like WinUSB or libusb or the one provided by microchip (mchpfsusb.dll?) etc to provide the API but it is not as involved as writing a kernel level driver as such.

I was just reading a README file supplied with mc's application library. It seems they are advocating the use of winusb over mchpfsusb as the latter was developed prior to ms releasing winusb and according to the author, advanced functionality, more powerful and with complete documentation.

Having said that it would appear libusb is the only one out of the three that support isochronous transfer even though I read somewhere that winusb may provide support for it in windows 8.

Knowing nothing about either of these, any advice on which of these two (winusb, libusb) I should pursue

[nctnico]

AFAIK libusb works on several platforms so that would be a smart choice if you ever want to support other platforms than Windows.

[mrflibble]

I use libusb-1.0 on linux for simple user-space usb stuff and find it quite useful. So far haven't used it on windows.

Edit: for the windows flavor, see this: http://www.libusb.org/wiki/windows_backend

[AlfBaz]

Yes I did go down the libusb route, for two reasons. So I didn't invest time in something that restricted me to the one platform and to avoid the winusb limitation of not having isochronous transfer capability, should I need it in the future but as I have found and mrflibble "pointed" out libusb seems to be just a wrapper for winusb on windows

[AlfBaz]

... to avoid the winusb limitation of not having isochronous transfer capability... libusb seems to be just a wrapper for winusb on windows

It appears they're working to incorporate the digitally signed libusb0.sys into libusb as well, which may mitigate some of winusb.sys's shortfalls
http://www.libusb.org/ticket/49