USB clarification needed

[asgard20032]

If I want to make USB peripheral, from what I understand, there is no difference between bulk, interrupt and isochronous transfer, from the device point right? Its just a matter of setting the right descriptor, and just sending normally data. From device (micro controller point of view), nothing special to do, right descriptor, and thats all, the same write/read function for interrupt and isochronous and interrupt. I am right thinking that? From what I understand, it is just on the pc side that thing change, and when he see the descriptor, he just change the priority and frequency of pooling that said device. Can someone either confirm or correct my tough? If I am right, USB development won't be that complicated from device side.

[ataradov]

I am right thinking that?

As a first approximation, yes. There may be minor differences in some implementations, but in general interface from the device point of view is pretty uniform.

If I am right, USB development won't be that complicated from device side.

Nope, not gonna happen. Unless you are using manufacturer-supplied libraries, USB development can be hell. Most USB device controllers in MCUs have really strange interfaces and most hosts will fail really hard as you try to debug and don't do everything just right.

It takes no time at all to kill Windows and Linux with a (unintentionally) rouge USB device. So if you are doing your own drivers, I advice to have a spare machine, that can crash freely.

[Delta]

UART <--> USB bridge, appearing as a virtual serial port to the host.

K.I.S.S. 

[ataradov]

You may not want to put external IC that is more expensive than your main MCU. You may want to get 1MBps bandwidth, which is pretty much impossible with UART.

Also, you may want your device to not spam device manager with COM ports.

[Delta]

You may not want to put external IC that is more expensive than your main MCU. You may want to get 1MBps bandwidth, which is pretty much impossible with UART.

Also, you may want your device to not spam device manager with COM ports.

Very true, but by the same token, you may not want to fanny around with all the crap mentioned by that ataradov bloke! 

[asgard20032]

If I am asking this, its not to take the uart bridge approach, but to go real USB. UART over USB has a big disadvantage that its not 100% plug n play, it just enumerate a new com port, and the user has to manually select that port. If we want to automate the device detection from the program(detecting which com port is related to which USB device), we need to go so low level(detect which USB device has the right endpoint/outpoint to be a valid CDC device, or enumarate all the device with the right PID/VID) in abstraction that going that road is as hard as just going plain (when we are detecting which USB device it is, we are already using the api needed to do raw write and raw read over those said endpoint.)

And learning USB is such a nice asset for many project, like using isochronous with a 1d camera to do scanning...

[Lukas]

The libopencm usb device api is really straightforward to use. Set up your descriptors, write some handlers for receiving data and you're basically done. Approx 200LOC, most of which are structs with descriptors. libopencm does the rest.
One the host side, you should use libusb. No need to write kernel drivers, you can even write you 'driver' in python if you're lazy. It works on linux and windows as well.

[ataradov]

If we want to automate the device detection

Windows has APIs to get more info about underlying USB device just from a COM port number. No such thing in Linux and MAC OS though.

And learning USB is such a nice asset for many project, like using isochronous with a 1d camera to do scanning...

  I would advice against this unless you are doing a truly streaming device.

Bulk will get you best results in most cases.

Also, support for isochronous transfers is real sketchy in libusb. The whole libusb thing is a mess, especially if you want to be cross-platform.

[asgard20032]

I mostly want to use USB on msp430, some arm cortex (2 manufacturer and maybe psoc also) , and maybe pic32 (not because its from microchip, but beceause its a mips architecture and it got many nice feature at a lower complexity than arm equivalent, altought its bugged as hell). Maybe even on FPGA with a soft CPU and an ip core or an open source core from opencore. In one of my project, I want to do midi over usb to interface my retrocade (a megawing for papillo pro FPGA), create my own synthesizer, and I just want to learn USB in general, because my fun would be to create computer peripheral.

[dgtl]

Iso and bulk transfers are not the same. Iso transfers do not have ACK/NAK/STALL response from other side, bulk has. Iso is like UDP - if data gets lost, no-one cares to re-send. For example, on sound cards, you do not want to resend the broken packet; you continue with the next one, because the old is already history. See http://www.beyondlogic.org/usbnutshell/usb4.shtml

[stmdude]

.....or enumarate all the device with the right PID/VID) in abstraction that going that road is as hard as just going plain

I realize that there's other aspects to this, but enumerating all COM-ports, and inspecting their VID/PID is actually not very difficult..  For a semi-skilled app-developer, that should be a <1h task.

[ataradov]

I realize that there's other aspects to this, but enumerating all COM-ports, and inspecting their VID/PID is actually not very difficult..  For a semi-skilled app-developer, that should be a <1h task.

That is if you only care about Windows. Add Linux and MAC OS and things become more complicated.

[stmdude]

That is if you only care about Windows. Add Linux and MAC OS and things become more complicated.

It's just as simple (just different) in Linux. Done it there as well.
OSX, I haven't tried. They're just all kinds of suck when it comes to low-level stuff (or OpenGL), so it might be trickier there.

[asgard20032]

With Linux, it is even easier than on windows. Just write a simple udev rule that will mount the CDC under the desired name. Then from program side, just access the desired name.

[dgtl]

In linux, things are much easier for both "raw" usb devices via libusb or cdc-acm serial ports. The vid/pid/serial can be looked up via libudev and that's it. Everything goes out-of-the-box for the major distros. No drivers needed; the application just must install a udev rule file to /etc/udev/rules.d to give non-root users access to the device. If needed, dynamic renaming of devnodes can be done etc, but usually this is not needed when the application does the lookup and the user does not see or need to know the dev name.

Windows is a different story. Cdc-acm serial still requires inf file to load usbser.sys up to win10 (win10 has finally usbser.sys bound to usb cdc-acm device class!). On win8, your inf has to be signed. On win7 and below, the user can just accept the warning. Still, the inf should be installed before the first connection attempt to give the smoothest user experience or needs to be accessible via windowsupdate. ("install the software before connecting device")

For raw usb devices, libusb works under windows, but has the same inf file problems with installing it. On win8, the signature check can be worked around with zadig-like self-signed locally generated certs, but this is a hack and far from commercial quality user experience. Microsoft has made their own competitor to libusb - winusb. This is a beast compared to libusb. For example, the device is identified by GUID from applications and then there are usb vid/pid to GUID mapping. This winusb thing kind-of-works on all windowses, but differently. Win8 and win10 works driverless - the usb device must present microsoft-specific descriptors, that are hacked on top of existing usb layer and that does not look similar to usb at all (why are the vid/pid not enough; there are some ms descriptors with VeryLongTextualNamesAndValues, that get imported into registry etc). When this is available, libusb loads automatically. On win7 and below, the application must pre-install inf and some CoInstaller stuff with dpinst to system before connecting device. This stuff has different versions for different windows versions and different versions for 32/64-bit os-s, so a lot of things needs to be carried with install package and installed depending on windows version. At least, it can be left un-signed as it is winxp/vista/7. In addition, at some point there was a windows phone inf file bound to whole winusb class, not just the excact windows phone devices, and this inf file is left behind on some machines, adding more confusion to this mess.

I have no experience with mac os.

All in all, the winusb solution can be made working quite well, but this requires a lot of work. Libusb without signed inf is no go. Cdc-acm without signed inf is no go. We can't still have nice things and the easiest way out is usb-serial converter, that has already had this pain handled.

[Howardlong]

I mostly want to use USB on msp430, some arm cortex (2 manufacturer and maybe psoc also) , and maybe pic32 (not because its from microchip, but beceause its a mips architecture and it got many nice feature at a lower complexity than arm equivalent, altought its bugged as hell). Maybe even on FPGA with a soft CPU and an ip core or an open source core from opencore. In one of my project, I want to do midi over usb to interface my retrocade (a megawing for papillo pro FPGA), create my own synthesizer, and I just want to learn USB in general, because my fun would be to create computer peripheral.

Choose only one. USB is not trivial, and most vendors have completely different stacks. Seriously, nobody in their right minds would attempt to write their own USB stack except for an academic exercise.

Also be careful with PIC32 because there are two stacks, one is part of the old MLA which will work fine for your application, I am pretty sure there is a midi example in there too. The other is Harmony which is the new "framework" (ugh, been hating that word since .NET came out) which despite being around for 2.5 years is still very buggy and has a very steep learning curve because you are forced to write and structure your programs under a strict new regime that some ivory tower utopian intellectual dreamt up who doesn't know one end of a soldering iron from the other.

The PIC32MX chips are well characterised and generally not too buggy. On the other hand, the PIC32MZ series, in particular the EC family, are best avoided at all costs as they are very buggy. The EF family are far better in this respect. Keep in mind too that unlike the MX devices, the MZ processors don't work with the old MLA, you have to use Harmony.

One nice thing about Microchip and NXP is that they offer a VID/PID service. I don't know about other vendors.

[asgard20032]

Same for TI, offer pid/vid. NXP look restrictive for their pid/vid, and I wonder if it also apply to freescale microcontroller, now that they own them. At least, microchip just ask what is the product name, without much justification.