On 06/05/14 15:17, Allan Herriman wrote:
> On Tue, 06 May 2014 01:12:34 +0100, Theo Markettos wrote:
>
>> Allan Herriman <allanherriman@hotmail.com> wrote:
>>> I'll second the "USB is crap" comment.
>>
>> It may be.
>
> I should clarify. I've made many boards over the years, using a variety
> of interface standards. USB has never struck me as being elegant or
> efficient. Its ubiquity, low cost (in volume), a robust connector and
> power on the same cable as the signals seem to be its biggest plusses.
>
> The USB physical layer isn't too bad, IMO. Most of the issues
> encountered during development are to do with the (software) drivers.
> That and the reuse of VID / PID values by cheap knock-off clone gizmos
> that don't quite match the functionality of the original, yet are still
> expected to work. (That isn't the fault of the USB standard though.)
Drivers /can/ be a problem with USB, but they don't have to be.
If you need your device to integrate with the operating system (such as
happens for mice, printers, USB speakers, mass storage devices, etc.),
then it is easy if you can re-use existing standardised drivers (such as
the OS's own HID or MSD drivers). If you need to make your own
specialised drivers, then it is a tough job on Linux - you need to learn
the details of how USB works on the OS as well as the details for the
USB class you are implementing, and distributing the drivers can be a
challenge. On Windows, even if you understand everything and can do all
the windows driver development, it is still a nightmare of signing,
certification, etc.
But if your device only needs to talk to programs /you/ write, or
libraries/dlls/so's that /you/ write, then it is a lot easier. On
Linux, libusb lets your application have direct access to the endpoints
on your USB device - you have full control without any drivers in the
middle. Until a few years ago, it was still hard on Windows - but
someone helpfully ported libusb from Linux to Windows as WinUSB, and
with the simple installer "zadig" you can avoid almost all issues with
drivers on Windows too.
>
>
> Other posters mentioned the need to purchase an official VID / PID. The
> process is too expensive for low volume or hobby projects.
>
> USB isn't alone there - for example my current employer owns an Ethernet
> OUI (a big block of MAC addresses) as well as an Ethertype (protocol
> specifier). Both of those cost money, but it's a modest once-off cost
> unlike the annual charge from USB-IF.
The charge for a USB VID is one-off. The charge to use the USB logo,
trademarks, etc., is annual.
For a hobby project, there is no problem - pick a VID of a company you
would never use, or an unassigned VID, and use that. For any
professional product, the $2000 (IIRC) charge to buy a VID is annoying
but if you budget it as though it were a piece of development equipment,
it is not going to be an issue.
> Another thing to consider is that for (e.g.) Ethernet, there are MAC
> addresses and Ethertypes that you can use for your hobby projects and
> experimental protocols that won't get you into trouble. The USB-IF don't
> provide VID / PID values intended for a similar purpose. (I understand
> that if you buy a VID with the purpose of making it "free" they will come
> after you.)
>
>> But look at your FPGA. How do you connect it to your PC?
>> It might have ethernet or PCIe, but almost invariably what comes first
>> is USB.
>
> It's the opposite for me. If one of my boards with an FPGA on it is
> connecting to a PC, it'll be via Ethernet.
>
> During debugging, I might rarely use USB to connect a JTAG pod to my PC
> though.
>
>>> If you must use USB2, I recommend using external PHY parts.
>>
>> This is the wrong solution
>
> I respectfully disagree. One thing that you might like to consider is
> the I/O required for USB2. It matches well to the sort of process that
> you would use for a $2 microcontroller, but not so well to the low
> voltage I/O that you'd find on a 28nm FPGA.
> There are also analog functions that are needed that you will not find on
> an FPGA. FPGA vendors don't like including anything that doesn't have
> wide applicability.
>
> OTOH USB3 uses serial signalling that might be a good match for FPGA
> transceivers. I haven't looked closely enough at the standard to know
> for sure, but I suspect there will be problems with idle or sleep (or
> something like that). OTOH, FPGA transceivers now have support for the
> analog signalling for SATA, so if there's enough demand in the
> marketplace, anything can happen.
> I only put a USB3 controller into a product once - a (then new) NEC /
> Renesas part that connected to my system using PCIe, so I can't claim to
> be a USB3 expert.
>
> I'm also aware that low speed (1.5Mb/s) USB can be bit-bashed in software
> on a cheap microcontroller. I don't think it would be compliant with the
> spec but it does seem to work and is extremely cheap.
Bit-banging low speed USB should be perfectly compliant with the specs
(if it is done right, of course). On an FPGA there should be no problem
implementing 12 Mb/s USB directly, or 480 Mb/s using an external PHY
(the XMOS devices do that, with the 480 Mb/s USB device running in
software). The USB protocol is not /that/ complicated.
> That really sounds like it could easily fit into an FPGA, possibly with
> the addition of some external level translators.
>
>> because those [PHY] chips are never there when you
>> need them.
>
> I know you're talking about boards, but if you were talking about part
> availability, that would be a good point. USB is used in consumer
> products, and this means that the parts sometimes have short production
> lives.
> Some years ago I designed a USB2 hub from ST-Ericcson into a product.
> They had been made obsolete before our second production run. Now
> there's an SMSC one in its place. Since then, SMSC has been bought by
> Microchip and who knows what's going to happen.
>
> Those issues can apply to any part on your board though, and aren't
> unique to USB. (Has anyone tried to get DDR3 RAM chips when some company
> in China is manufacturing a large batch of tablets?)
>
>> If you're doing your own board you can put on one, but many
>> dev boards don't have them.
>
> I don't use dev boards, so I really shouldn't comment.
>
>> Why isn't USB2 an FPGA programming option (in addition to JTAG)?
>
> Substitute the string "PCIe" for "USB2" and you have a question I asked
> of the local Altera and Xilinx reps about five years ago.
>
> I'm still waiting for a good solution to that problem that doesn't
> involve putting a "bootloader" NVM on the board to configure the FPGA
> just so it can talk PCIe to get the rest of the configuration.
>
> My guess: USB2 - never. USB3 - a very remote possibility.
>
> Regards,
> Allan
>