SILabs Universal Bee - A Possible FTDI Killer?

[andersm]

Also USB spec here (sorry, I don't have access to a "more official" one)

All USB specifications are available as downloads on the USB-IF website.

[nctnico]

IMHO this is one of the cases where you want to debug using a simulated software environment to get the protocol right and then use printfs to trace/verify execution paths.

[janoc]

Also USB spec here (sorry, I don't have access to a "more official" one)

All USB specifications are available as downloads on the USB-IF website.

Ah, thanks! I was under the impression that the official specs were available only to the USB-IF members under an NDA. Not sure why.

[janoc]

IMHO this is one of the cases where you want to debug using a simulated software environment to get the protocol right and then use printfs to trace/verify execution paths.

I think we had this argument elsewhere already - this is simply not an option in many cases, especially when dealing with real hardware, timing-sensitive issues, etc.

It doesn't make your method invalid (and I do use it for some things, e.g. when developing complex algorithms - those are easier to make work on a PC first), but it doesn't help at all when the issue is hardware-related.

[Brutte]

You are obviously referring to the second form (..) However, I am speaking about the first ones, there isn't any NAK from device necessary for that to happen. If the device doesn't reply in time, either by ACK or NAK, the host will consider it failed/disconnected and game over. The USB phy in the chip won't do that for you, it cannot know that you aren't busy at the moment and are able to reply to the incoming request.

Thanks for the input.
I must underline here I do not know low level USB.
What I report(ed) is that for me  debugging USB application, single stepping, dumping sram etc (STM32) of a configured USB device I have never experienced the "timeout of first type" you refer to.
XP+MinGW+libusb/STM32_USB_stack+STM32L152, interrupt +bulk.
Libusb was in a release version, room temperature and humidity, tongue kept at correct angle.
From your post and links one could infer I am the luckiest uC programmer in the world because the USB stack should time-out in 50ms (or so).
How is it possible that my setup does not work that way?
Have you ever tried debugging a pair of USB applications (x86+uC)?

[JTR]

You are obviously referring to the second form (..) However, I am speaking about the first ones, there isn't any NAK from device necessary for that to happen. If the device doesn't reply in time, either by ACK or NAK, the host will consider it failed/disconnected and game over. The USB phy in the chip won't do that for you, it cannot know that you aren't busy at the moment and are able to reply to the incoming request.

Thanks for the input.
I must underline here I do not know low level USB.

Not just you. Janoc has little idea ether and you can safely disregard what has been posted above. ACKS and NAKs on the device side are generated automatically by the SIE, not the USB firmware. The SIE may NAK a BULK or INTERRUPT USB transfer indefinately but it must NEVER NAK a SETUP PACKET.

> ALL SETUP PACKETS MUST BE RESPONDED TO WITHIN A FIXED TIME. <

However, as you have found and I tried to explain before,  you can get away breakpoints in a USB stack for as long as the host does not send any more SETUP PACKETS.  As it turns out this situation tends to happen often enough for there to a practical chance to break and single step a USB stack after enumeration and the initial CLASS REQUESTS (if any) have been done.

The important take away is that there is no guarantee though because the host always controls the transfers and can abort any transfer and issue a SETUP PACKET at ANYTIME and this must be responded to within a fixed and specified time.

That is basically it, that is why (and when) you can and cannot single step a USB stack.

[Brutte]

(..)ACKS and NAKs on the device side are generated automatically by the SIE, not the USB firmware. The SIE may NAK a BULK or INTERRUPT USB transfer indefinately but it must NEVER NAK a SETUP PACKET.

Yes, that is how I understand that, this is governed by a timeout of the first type.
And because:

• for data transmission (interrupt and bulk) these timings are controlled by SIE,
• for enumeration (setup) these are sent only during first ms of startup

thus I have never experienced the timeout (of 1^st type) of those transactions as the USB stack has always got what it requested for on time.
 
Then I must assume that a debugging resources of some uCs (like STM32L1xx) allow the SIE to be fully operational (and NAKing or ACKing in the background) even when the core is halted by a debugger. The reference manual does not explain details of that feature.

[janoc]

How is it possible that my setup does not work that way?
Have you ever tried debugging a pair of USB applications (x86+uC)?

You may have been simply lucky - if your application/driver is not trying to poll your device while you are debugging it, then likely nothing will happen, because there is nothing to time out (no transfer being initiated). In my case the driver was constantly trying to poll the device.

And yes, I have my share of USB debugging behind me.

[janoc]

Not just you. Janoc has little idea ether and you can safely disregard what has been posted above. ACKS and NAKs on the device side are generated automatically by the SIE, not the USB firmware. The SIE may NAK a BULK or INTERRUPT USB transfer indefinately but it must NEVER NAK a SETUP PACKET.

OK, you got me to actually pull out the reference guide to both STM32f101 and PIC18F14k50 and check how the ACK/NACK sending is implemented. Both you and Brutte were, indeed, right that it is done by the USB phy and not by the interrupt handler/USB stack. However, there you can still set a flag that next request should be NACK-ed, for flow control purposes. I guess that is what has confused me, making me think that all ACK/NACK sending is handled through that. 

> ALL SETUP PACKETS MUST BE RESPONDED TO WITHIN A FIXED TIME. <

Which is what I was referring to as well.

Moreover, I was trying to illustrate that, apart from the setup packets, there are various timeouts built-in in the host OS's USB stack at various layers (the HID example), so expecting that one can arbitrarily stop the device and nothing bad will happen is foolish. Brutte simply got lucky.

Anyway, going back to the original topic, I have seen this project yesterday:
https://hackaday.io/project/4994-bsu-bs-free-usb

Right now it is still vaporware, but it could be an option in the future, especially if you don't want to/can't obtain your own vid/pid or be bothered with implementing your own USB firmware (which can be a royal PITA).

[Brutte]

You may have been simply lucky - if your application/driver is not trying to poll your device while you are debugging it(..)

There is no such possibility. As I mentioned, I did try interrupt communication and as you might know the poll interval is selectable from 1ms to 255ms max. No, I didn't interrogate uC below 255ms - sometimes halting lasted long enough to go for a pee. Still no time-outs (of 1-st type) there.

[janoc]

You may have been simply lucky - if your application/driver is not trying to poll your device while you are debugging it(..)

There is no such possibility. As I mentioned, I did try interrupt communication and as you might know the poll interval is selectable from 1ms to 255ms max. No, I didn't interrogate uC below 255ms - sometimes halting lasted long enough to go for a pee. Still no time-outs (of 1-st type) there.

Well, then we have to agree to disagree here. The "no such possibility" doesn't really mesh with multiple people having experienced the issues you are discounting as impossible.

I rest my case here, there are more qualified people here than me that have tried to explain the problem too.

[donotdespisethesnake]

Anyway, going back to the original topic, I have seen this project yesterday:
https://hackaday.io/project/4994-bsu-bs-free-usb

Right now it is still vaporware, but it could be an option in the future, especially if you don't want to/can't obtain your own vid/pid or be bothered with implementing your own USB firmware (which can be a royal PITA).

I like that idea. Even if very limited functionality, it would be very useful at the low end, if you just want to flip a few outputs, without needing own VID or signed driver. I tried bit-banging with FTDI, it was quite a pain, and Windows specific. Their driver API abstraction is terrible if you want to support different types of FTDI chip, different setup structure for each chip.

If it starts simple and takes off, it is likely to get more advanced later. Finally we might have something to replace the "cheap, easy and direct" nature of the old parallel port.

[janoc]

I like that idea. Even if very limited functionality, it would be very useful at the low end, if you just want to flip a few outputs, without needing own VID or signed driver. I tried bit-banging with FTDI, it was quite a pain, and Windows specific. Their driver API abstraction is terrible if you want to support different types of FTDI chip, different setup structure for each chip.

There is the cross-platform libftdi, if you want a cross platform support for FTDI chips. However, even the proprietary driver/library is cross-platform, at least Windows & Linux for sure.

http://www.intra2net.com/en/developer/libftdi/

For me the interest of the "BS Free USB" project is mainly the drivers for Windows and VID/PID issues. Those are an enormous pain unless you are a big company that can afford the various fees and paperwork required. I rarely need more than USB 1.1 full speed, so this sort of solution would be OK.

[Brutte]

(..)if your application/driver is not trying to poll your device while you are debugging it(..)

There is no such possibility.(...)

Well, then we have to agree to disagree here. The "no such possibility" doesn't really mesh with multiple people having experienced the issues you are discounting as impossible.

It seems either your English or my English is a problem here.
You give remarks not referenced with the subject of my posts. The recent one didn't touch the problem of issues of others.
What I meant was that there was no such possibility for a host to not poll an interrupt communicating, enumerated device. The polling interval is guaranteed by USB standard thus your remark about my luck in that subject is out of the question (a.k.a. impossible). The device (or rather endpoints) was constantly polled while it was debugged/halted, still no time-outs of first kind experienced.

[westfw]

I was asking if this was competition against the FT232RL, a popular IC which has been part of a few Arduino models and which Sparkfun and Adafruit sell, as well as many other vendors.

There are lots of alternatives to the FT232RL, many of which are significantly cheaper and/or offer greater programability.  The FTDI chips were still the "go to" solution for hassle-free USB/Serial comm.  At least until their recent driver miss-step :-(

1) FTDI provides turn-key chips with their VID/PID and serial number/etc.  Does Si-labs have a policy here?  Traditionally, if you use a programmable controller, you're supposed to get your own VID (several thousand dollars/year) and have the additional overhead of managing "all that")  Some vendors have been bending the rules a bit lately, allowing users to use the manufacturer VID as long as they're using the reference library code.

2) FTDI has maintained multi-platform drivers.  That work.  I've seen vendors ship usb/serial bridges with only a windows driver :-(  And assorted bugs with vendor drivers

3) the FTDI has utilities and support for additional features.  Painlessly putting your branding (VID/PID/etc) on their chips, if you so desire.  And stuff like that.  It's a mature product that has learned "lots of stuff" over the years.

4) As others have mentioned, the FT232RL is now a "legacy" product.  The newer FT230x and similar are cheaper and "better" in several ways.

If you want cheap, there's the CH340G.  About $0.50 from Aliexpress; now shipped on countless arduino derivatives and pretty well proven (?)
SO-16, so smaller AND easier to solder than FTDI SSOP packages.  The main disadvantage seems to be that it requires an external crystal.

[andersm]

you're supposed to get your own VID (several thousand dollars/year)

Just getting the vendor ID is a one-time fee. If you want to become an USB-IF member, or use the USB logo on your products, you have to pay an annual fee.

[westfw]

Just getting the vendor ID is a one-time fee.

Really?  I always thought that you had to "become a member" to get a VID.   Though I guess if you let your membership lapse, they can't really revoke the VID...
(I guess I could just look at the web site: http://www.usb.org/developers/vendor/ : $4000/y to become a member (includes VID.)  $3500/2y + $5000 to get a VID and license the logo.  $5000 to just get a VID.)