SILabs Universal Bee - A Possible FTDI Killer?

[JoeN]

That SILabs "universal bee" part that Dave showed off looked interesting to me once I saw the price.  The price for the 24 pin version (EFM8UB11F16G-B-QSOP24) is $1.33 at Digikey versus $4.50 for the FT232RL.  Both claim to be full-speed USB 2.0 compliant.  With the SILabs part you also get a 16KB, 50Mhz 8051 processor thrown in essentially for free and you can get an even better one with 64K and 48 pins for $1.93 (EFM8UB20F64G-A-QFP48).  I was able to build a demo board, download Simplicity Studio, get a free Keil license for it, compile their USB-to-UART bridge sample, and put it on the board, and have it work all without any serious hassles in a few hours.  After the demo software was uploaded to the board, Windows recognized the board as a USB device, found the right driver from Windows Update, and didn't even brick my computer for the effort.  There is also a demo for a HID keyboard, mouse, and joystick included in Simplicity Studio and no doubt these will work too.  I am going to make a numeric keypad next to test it out.  (These demo source code by default assumes you have the board that Dave got, I had to rework the code for my hand-made board a little).

Maybe there are some advantages to the FTDI chip that I don't know of.  Does anyone have enough familiarity with the FTDI chip or the USB ecosystem to comment on this?  I am a total USB newbie myself, other that having just made a useful peripheral with this IC and no real deep knowledge of USB at all.  So in that way it seems like a pretty decent product to me.  What am I missing?

Self powered, the incoming character 0-9 and A-F typed in PUTTY is displayed on the seven segment display, other characters displayed as a dash.

[Bassman59]

Silicon Labs does it right.

I just hope that one of the Big Guys doesn't swoop in and buy them.

[andersm]

A big part of the appeal of FTDI's chips is that there's no firmware to worry about. They're also very well supported, and the drivers come bundled with all major operating systems. The newer FT-X series chips are also much cheaper, eg. the FT230X is $2.04 in single quantities at DigiKey.

[JoeN]

A big part of the appeal of FTDI's chips is that there's no firmware to worry about. They're also very well supported, and the drivers come bundled with all major operating systems. The newer FT-X series chips are also much cheaper, eg. the FT230X is $2.04 in single quantities at DigiKey.

When I first used an FTDI chip, it behaved the same way this one did, Windows ran off to Window Update and downloaded the drivers automatically.  That is not bundled, or, if it is, SILabs is bundled in exactly the same way.  This is my memory of it anyway.  I did a quick Google check and at least Sparkfun seems to agree with my memory:

By default, windows does not have FTDI drivers installed. If you plug in your FTDI, open the Arduino IDE, go to ‘Tools -> Serial Ports’, and see nothing, you need the drivers! Let’s go get them!

https://learn.sparkfun.com/tutorials/how-to-install-ftdi-drivers/all

[andersm]

I misremembered then. Recently I've mostly used OS X and Linux, where support is out-of-the-box (for most distros anyway).

[Rasz]

That SILabs "universal bee" part that Dave showed off looked interesting to me once I saw the price.  The price for the 24 pin version (EFM8UB11F16G-B-QSOP24) is $1.33 at Digikey versus $4.50 for the FT232RL.  Both claim to be full-speed USB 2.0 compliant.  With the SILabs part you also get a 16KB, 50Mhz 8051 processor thrown in essentially for free and you can get an even better one with 64K and 48 pins for $1.93 (EFM8UB20F64G-A-QFP48).

waaaait, that sounds awfully like Cypress EZUSB is it serial or serial and parallel? dont tell me, running to read the datasheet!

this could mean $5 not so cloned clones of salealeaeblah

[Psi]

I like the onboard 3.3V reg of the CP21XX

[mikeselectricstuff]

The FTDI has an alternate API (D2xx) which is much more flexible than COM port emulation. There is also a seamless upgrade path to high speed and (slightly less seamless) multi-port devices, as well as sync serial and parallel port interfaces.
They are also supported on a very wide range of platforms. 

There are many low-cost MCUs with onboard USB, but this is always going to be an order of magnitude more work to implement than a ready-made USB-serial converter.

[nctnico]

I have just started production on a design with a CP210x USB to serial converter instead of the FTDI chip. They work OK. I had to use the CP2103 because I also needed RS485 communication.

I don't agree with Mike about controllers with built in USB. If I need serial to USB and a microcontroller I use a CDC stack. I made that once based on existing code and re-use it ever since. The advantage is that the bandwidth is much higher and the baudrate setting doesn't matter anymore so less can go wrong.

[Brutte]

There are many low-cost MCUs with onboard USB, but this is always going to be an order of magnitude more work to implement than a ready-made USB-serial converter.

Mind COM is a byte-oriented low level communication. So you have to add a custom additional layer above it. Another PITA is debugging an embedded application that uses USB2serial. If uC hits a breakpoint while your uC is receiving then most likely it means you have to restart both applications (unless you provide some sort of retransmission, CRC and alike). That is not the case with debugging USB capable uCs as (hardware) USB interface is packet oriented, has its own CRC, retransmissions etc.

[janoc]

Mind COM is a byte-oriented low level communication. So you have to add a custom additional layer above it. Another PITA is debugging an embedded application that uses USB2serial. If uC hits a breakpoint while your uC is receiving then most likely it means you have to restart both applications (unless you provide some sort of retransmission, CRC and alike). That is not the case with debugging USB capable uCs as (hardware) USB interface is packet oriented, has its own CRC, retransmissions etc.

Uh, did you actually try to debug a live USB stack on a micro? The moment you hit a breakpoint the host will time out and drop your connection or do something else you don't want. These things are very hard to debug on live hardware because of the millisecond magnitude timeouts. Basically you can hit a breakpoint, use it to poke at the guts of the micro, but then you must start over because it is impossible to resume the execution correctly.

Compared to that, a micro with a USB to serial bridge is very easy to debug. Yes, you may have communication protocol issues, but you typically have control of both sides of that, so you can deal with it. Unlike the PC host controller resetting your gizmo's USB whenever you are trying to debug it ..

I have built both types of solutions and the USB to UART bridges are by far the easiest to develop firmware for (try implementing your own or adapting/debugging a vendor's USB stack!). They also save you the driver writing work. Then for small scale outfits there is the issue of the USB VID/PIDs - if you use a bridge, you don't have to worry about that too much, you can keep using the vendor provided one. However, you do pay for that convenience with higher cost, more board space needed and slower/less flexible communication.

[Brutte]

Uh, did you actually try to debug a live USB stack on a micro? The moment you hit a breakpoint the host will time out and drop your connection or do something else you don't want.

I am not talking about software-based USB (like V-usb on atiny13) but about hardware USB (like STM32 stack on STM32L1xx). Yes, I did try debugging STM32L1xx and I cannot recall any timeouts when debugging application (not to be confused with debugging USB stack that I never did).
You could timeout USB device during enumeration stage (by pulling up D+ and not servicing USB IRQs within 1s when host requests descriptors) but after that stage a USB device is configured, then everything that involves USB is event-based and serviced by hardware, not time-out based. Similar with the host side application but I am sure it can also be written to timeout or not when some condition happens.
Mind I have used interrupt and bulk, not sure how isochronous and setup data exchange behaves.

[Rasz]

well that was short lived enthusiasm, this chip is weaksauce :/
2KB ram, and half of that is usb FIFO, no dma, no dedicated hardware GPIO serializer
no cake there, high speed usb is a lie

[mikerj]

well that was short lived enthusiasm, this chip is weaksauce :/
2KB ram, and half of that is usb FIFO, no dma, no dedicated hardware GPIO serializer
no cake there, high speed usb is a lie

Does it claim to be high speed?  I only see "full speed" mentioned.

[Brutte]

well that was short lived enthusiasm, this chip is weaksauce :/
2KB ram, and half of that is usb FIFO, no dma, no dedicated hardware GPIO serializer
no cake there, high speed usb is a lie

Yes it is a lie and nobody said it has a high speed usb.
EFM8UB10F8G is $0.61 in 1k5 reel. Dirt cheap.

[Rasz]

well that was short lived enthusiasm, this chip is weaksauce :/
2KB ram, and half of that is usb FIFO, no dma, no dedicated hardware GPIO serializer
no cake there, high speed usb is a lie

Does it claim to be high speed?  I only see "full speed" mentioned.

what is wrong with me today 
you are absolutely right

[Bassman59]

no cake there, high speed usb is a lie

You seem to have confused "USB 2.0" with "High Speed." Although that is a very common mistake, one would hope engineers wouldn't make it.

(And it would be nice if the micro vendors would indicate in their various parts search whether their products are HS or just FS/LS.)

[JoeN]

Yeah, 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.  I read both of these parts as being full speed, not high speed.  I am not saying the SILabs parts are competition against high speed USB ICs which I have not looked at yet.  Maybe I shouldn't have said something as provocative as "FTDI Killer" and instead said "FT232RL Killer".  I see some good arguments so far as it not even being a FT232RL killer.  But for me, the thing is working out very well and I am not very good at USB at all so that makes it very useful to me.  What a nice and cheap little IC it is.

[JoeN]

Now I have a keypad going too.  First HID device for me.     Thanks to SILabs great demo code.  It downloads the SILabs HID Keyboard driver from Windows Update and just works, it acts like a second keyboard.

Input from device:  123456789*0#8675309

[Brutte]

What about the EFM8 development tools? The 8051 C compiler should not be a problem, anyone has first hand experiences with a debugger (with MI) and the debugging dongles? What about OCD resources? I read there are only 4 program breakpoints, no software breakpoints. What about data breakpoints? Can it run or halt timers in debugging mode?
Anyone compared the development tools with those for MSP430/PIC8/AVR8/ARMv6M/ARMv7M?

[janoc]

I am not talking about software-based USB (like V-usb on atiny13) but about hardware USB (like STM32 stack on STM32L1xx).

Me neither, I am talking about HW supported USB. V-USB and such are a completely different kettle of fish.

Yes, I did try debugging STM32L1xx and I cannot recall any timeouts when debugging application (not to be confused with debugging USB stack that I never did).
You could timeout USB device during enumeration stage (by pulling up D+ and not servicing USB IRQs within 1s when host requests descriptors) but after that stage a USB device is configured, then everything that involves USB is event-based and serviced by hardware, not time-out based. Similar with the host side application but I am sure it can also be written to timeout or not when some condition happens.
Mind I have used interrupt and bulk, not sure how isochronous and setup data exchange behaves.

The hardware only triggers the USB stack's code by interrupts when certain things happen on the bus, there is no magic there. It is all happening on the CPU, the USB stack code is normal software as everything else. All that the built-in USB phy does is that it offloads things such as encoding/decoding the wire format, detects bus resets and sends/receives the data from/to the endpoint buffers for you. The rest - responding to the various protocol-specific issues, including responding in time to avoid timeouts - is up to your code (i.e. the USB stack).

If the CPU is stopped because you are poking its guts by JTAG (e.g. attached a debugger) the connection will time out reliably, because you will likely break in the middle of a transfer and it won't get ACK-ed in time to avoid a timeout. This was pretty much my experience with debugging code on STM32F103xx, STM32F30xxx and PIC18F22j55 - the moment the debugger attached the USB connection has died a few seconds later and was impossible to recover without re-enumerating the device.

I was using mostly the CDC and HID classes (i.e. interrupt transfers), but it was pretty much the same story each time - the host OS drivers ended in a weird/undefined state because of the unexpected timeout on an outstanding transfer, the host controller tried to reset the device sometimes, timeouts in the logs, etc. Of course, the drivers can be modified to avoid these issues, but do you really want to write and install a custom USB driver to permit you to debug your device? That sort of defeats the entire purpose of using a HID or CDC class.

[Brutte]

If the CPU is stopped because you are poking its guts by JTAG (e.g. attached a debugger) the connection will time out reliably, because you will likely break in the middle of a transfer and it won't get ACK-ed in time to avoid a timeout.

You are describing a phenomenon I have never experienced.
AFAIK the USB driver does not have any timeouts (with regard to the user packets) once the USB device is configured(although I would not call myself a USB pro). I have used libusb (MinGW, Windows XP) extensively and there an API has an explicit transfer request timeout YOU define. Could be an hour, a weekend or forever, but this timeout is the user's choice, not an underlying USB driver's timeout as your posts suggest. If you are debugging both applications you are free to set the timeouts arbitrarily long or disable those. OT: There is also a choice of an asynchronous communication.
Now, if host had not received an ACK from a device (because of uC's breakpoint) then it would retransmit the same packet 1ms later and it is pushing out those futile packets till death. Where in the USB specification (lets limit to USB 2.0 as I do not want to get into the USB 3.0 details) there is a word about some timeouts the USB device has to obey (ignoring an obvious timeout during the enumeration stage, which I mentioned earlier)?
Can you give a reference?

May it be that the smartass STM32L1xx does NACKs when halted by debugger 
That could also explain why I do not face those timeouts you describe. Just speculating

[JTR]

USB setup packets (including class and vendor requests) can be sent ANYTIME and they have specified timeouts that the device must respond to the request.

Therefore you cannot really halt a USB stack for debug purposes and be safe. In practice you sometimes can get away with it when the host does not need to send any additional setup packets. However there is absolutely no guarantee provided by the USB spec that says this condition will be met and by design the USB device must respond to the host requests without predicting what request may or may not come.

You can get lucky though, just don't count on it...

[JoeN]

I used the Simplicity Studio debugging facility with the 8-Bit USB Debug Adapter while working on these boards and I hit many breakpoints while working out the kinks and even left it sitting for minutes at the breakpoints while consulting documentation.  I didn't have any problems with Windows complaining or disconnecting the device.  That's just my experience here.  It may be that the debugger doesn't resolve this sort of periodic host query correctly, but at least with Windows as a host it doesn't seem to be a big issue.

[janoc]

You are describing a phenomenon I have never experienced.

Well, consider yourself lucky then.

AFAIK the USB driver does not have any timeouts (with regard to the user packets) once the USB device is configured(although I would not call myself a USB pro). I have used libusb (MinGW, Windows XP) extensively and there an API has an explicit transfer request timeout YOU define. Could be an hour, a weekend or forever, but this timeout is the user's choice, not an underlying USB driver's timeout as your posts suggest.

That is not true. Once the setup packet is sent, the device has to respond in time, otherwise the OS will time it out and declare the device dead.

For example, increasing timeouts for the USB HID protocol in the Linux kernel:
http://lxr.free-electrons.com/source/drivers/hid/usbhid/hid-core.c (around line 158)

If you are debugging both applications you are free to set the timeouts arbitrarily long or disable those. OT: There is also a choice of an asynchronous communication.
Now, if host had not received an ACK from a device (because of uC's breakpoint) then it would retransmit the same packet 1ms later and it is pushing out those futile packets till death.

Um, certainly not. It will try a few times, but eventually it will give up and signal an error. Come on, if what you are saying was true, then the computer could never figure out that you have disconnected the USB device or cut its power (if it is self powered). It would just keep sending forever.

Can you give a reference?

May it be that the smartass STM32L1xx does NACKs when halted by debugger 
That could also explain why I do not face those timeouts you describe. Just speculating

See the source code above. Also here you can search for the keyword "timeout":
http://lxr.free-electrons.com/ident?i=timeout

Did you notice how many of those are in drivers that are in the "usb" subtree? Especially those in the "core" or "hid" in the filename. I obviously cannot show you Windows source code, but I am pretty sure it is going to be similar - it is basic functionality.

Also USB spec here (sorry, I don't have access to a "more official" one):
https://www.freebsd.org/doc/en_US.ISO8859-1/books/arch-handbook/usb-dev.html

Transfers to an endpoint are serialised in the pipe. A transfer can either complete, fail or time-out (if a time-out has been set). There are two types of time-outs for transfers. Time-outs can happen due to time-out on the USBbus (milliseconds). These time-outs are seen as failures and can be due to disconnection of the device. A second form of time-out is implemented in software and is triggered when a transfer does not complete within a specified amount of time (seconds). These are caused by a device acknowledging negatively (NAK) the transferred packets. The cause for this is the device not being ready to receive data, buffer under- or overrun or protocol errors.

You are obviously referring to the second form - those are indeed controllable from software, when you are sending the setup packet. 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.

This document even has some of the timeouts specified:
http://www.beyondlogic.org/usbnutshell/usb6.shtml

They even make an explicit comment on the timeouts being an issue during debugging there.