SILabs Universal Bee - A Possible FTDI Killer? - Page 1
Forum section: electronics / general

author: JoeN
author_rank: Frequent Contributor
timestamp: April 28, 2015, 03:20:00 am
content: 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.

author: Bassman59
author_rank: Super Contributor
timestamp: April 28, 2015, 03:55:32 am
content: Silicon Labs does it right.I just hope that one of the Big Guys doesn't swoop in and buy them.

author: andersm
author_rank: Super Contributor
timestamp: April 28, 2015, 05:32:59 am
content: 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.

author: JoeN
author_rank: Frequent Contributor
timestamp: April 28, 2015, 05:53:15 am
content: Quote from: andersm on April 28, 2015, 05:32:59 amWhen 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:Quote from: Sparkfunhttps://learn.sparkfun.com/tutorials/how-to-install-ftdi-drivers/all

author: andersm
author_rank: Super Contributor
timestamp: April 28, 2015, 06:10:33 am
content: I misremembered then. Recently I've mostly used OS X and Linux, where support is out-of-the-box (for most distros anyway).

author: Rasz
author_rank: Super Contributor
timestamp: April 28, 2015, 08:54:35 am
content: Quote from: JoeN on April 28, 2015, 03:20:00 amwaaaait, that sounds awfully like Cypress EZUSBis it serial or serial and parallel? dont tell me, running to read the datasheet!this could mean $5 not so cloned clones of salealeaeblah

author: Psi
author_rank: Super Contributor
timestamp: April 28, 2015, 09:41:37 am
content: I like the onboard 3.3V reg of the CP21XX

author: mikeselectricstuff
author_rank: Super Contributor
timestamp: April 28, 2015, 10:00:39 am
content: 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.

author: nctnico
author_rank: Super Contributor
timestamp: April 28, 2015, 11:41:20 am
content: 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.

author: Brutte
author_rank: Frequent Contributor
timestamp: April 28, 2015, 01:11:26 pm
content: Quote from: mikeselectricstuff on April 28, 2015, 10:00:39 amMind 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.

author: janoc
author_rank: Super Contributor
timestamp: April 28, 2015, 02:07:21 pm
content: Quote from: Brutte on April 28, 2015, 01:11:26 pmUh, did you actuallytryto 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.

author: Brutte
author_rank: Frequent Contributor
timestamp: April 28, 2015, 02:41:27 pm
content: Quote from: janoc on April 28, 2015, 02:07:21 pmI 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 debuggingapplication(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.

author: Rasz
author_rank: Super Contributor
timestamp: April 28, 2015, 03:15:34 pm
content: 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 serializerno cake there, high speed usb is a lie

author: mikerj
author_rank: Super Contributor
timestamp: April 28, 2015, 03:20:43 pm
content: Quote from: Rasz on April 28, 2015, 03:15:34 pmDoes it claim to be high speed? I only see "full speed" mentioned.

author: Brutte
author_rank: Frequent Contributor
timestamp: April 28, 2015, 03:37:49 pm
content: Quote from: Rasz on April 28, 2015, 03:15:34 pmYes it is a lie and nobody said it has a high speed usb.EFM8UB10F8Gis $0.61 in 1k5 reel. Dirt cheap.

author: Rasz
author_rank: Super Contributor
timestamp: April 28, 2015, 03:54:28 pm
content: Quote from: mikerj on April 28, 2015, 03:20:43 pmwhat is wrong with me todayyou are absolutely right

author: Bassman59
author_rank: Super Contributor
timestamp: April 28, 2015, 07:36:49 pm
content: Quote from: Rasz on April 28, 2015, 03:15:34 pmYou 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.)

author: JoeN
author_rank: Frequent Contributor
timestamp: April 28, 2015, 08:34:42 pm
content: 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.

author: JoeN
author_rank: Frequent Contributor
timestamp: April 29, 2015, 07:23:56 am
content: 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

author: Brutte
author_rank: Frequent Contributor
timestamp: April 29, 2015, 07:50:03 am
content: 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?

author: janoc
author_rank: Super Contributor
timestamp: April 29, 2015, 01:50:08 pm
content: Quote from: Brutte on April 28, 2015, 02:41:27 pmMe neither, I am talking about HW supported USB. V-USB and such are a completely different kettle of fish.Quote from: Brutte on April 28, 2015, 02:41:27 pmThe 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.

author: Brutte
author_rank: Frequent Contributor
timestamp: April 29, 2015, 04:16:08 pm
content: Quote from: janoc on April 29, 2015, 01:50:08 pmYou 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 debuggerThat could also explain why I do not face those timeouts you describe. Just speculating

author: JTR
author_rank: Regular Contributor
timestamp: April 30, 2015, 06:42:31 am
content: 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...

author: JoeN
author_rank: Frequent Contributor
timestamp: April 30, 2015, 08:35:52 am
content: 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.

author: janoc
author_rank: Super Contributor
timestamp: April 30, 2015, 10:46:09 pm
content: Quote from: Brutte on April 29, 2015, 04:16:08 pmWell, consider yourself lucky then.Quote from: Brutte on April 29, 2015, 04:16:08 pmThat 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)Quote from: Brutte on April 29, 2015, 04:16:08 pmUm, 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.Quote from: Brutte on April 29, 2015, 04:16:08 pmSee the source code above. Also here you can search for the keyword "timeout":http://lxr.free-electrons.com/ident?i=timeoutDid 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.htmlQuoteYou 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.shtmlThey even make an explicit comment on the timeouts being an issue during debugging there.

author: andersm
author_rank: Super Contributor
timestamp: May 01, 2015, 12:42:10 am
content: Quote from: janoc on April 30, 2015, 10:46:09 pmAll USB specifications are available as downloads on theUSB-IF website.

author: nctnico
author_rank: Super Contributor
timestamp: May 01, 2015, 12:56:11 am
content: 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.

author: janoc
author_rank: Super Contributor
timestamp: May 01, 2015, 11:53:44 am
content: Quote from: andersm on May 01, 2015, 12:42:10 amAh, thanks! I was under the impression that the official specs were available only to the USB-IF members under an NDA. Not sure why.

author: janoc
author_rank: Super Contributor
timestamp: May 01, 2015, 11:55:55 am
content: Quote from: nctnico on May 01, 2015, 12:56:11 amI 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.

author: Brutte
author_rank: Frequent Contributor
timestamp: May 01, 2015, 04:47:05 pm
content: Quote from: janoc on April 30, 2015, 10:46:09 pmThanks for the input.I must underline here I do not know low level USB.What I report(ed) is that for medebugging USB application, single stepping, dumping sram etc (STM32) of aconfiguredUSB device I haveneverexperienced 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)?

author: JTR
author_rank: Regular Contributor
timestamp: May 02, 2015, 08:27:00 am
content: Quote from: Brutte on May 01, 2015, 04:47:05 pmNot 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.

author: Brutte
author_rank: Frequent Contributor
timestamp: May 02, 2015, 03:43:38 pm
content: Quote from: JTR on May 02, 2015, 08:27:00 amYes, 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 startupthus I have never experienced the timeout (of 1sttype) 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.

author: janoc
author_rank: Super Contributor
timestamp: May 02, 2015, 08:47:27 pm
content: Quote from: Brutte on May 01, 2015, 04:47:05 pmYou 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.

author: janoc
author_rank: Super Contributor
timestamp: May 02, 2015, 09:15:52 pm
content: Quote from: JTR on May 02, 2015, 08:27:00 amOK, 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.Quote from: JTR on May 02, 2015, 08:27:00 amWhich 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-usbRight 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).

author: Brutte
author_rank: Frequent Contributor
timestamp: May 03, 2015, 08:46:57 am
content: Quote from: janoc on May 02, 2015, 08:47:27 pmThere 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.

author: janoc
author_rank: Super Contributor
timestamp: May 04, 2015, 12:02:05 am
content: Quote from: Brutte on May 03, 2015, 08:46:57 amWell, 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.

author: donotdespisethesnake
author_rank: Super Contributor
timestamp: May 04, 2015, 10:27:13 am
content: Quote from: janoc on May 02, 2015, 09:15:52 pmI 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.

author: janoc
author_rank: Super Contributor
timestamp: May 04, 2015, 03:26:20 pm
content: Quote from: donotdespisethesnake on May 04, 2015, 10:27:13 amThere 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.

author: Brutte
author_rank: Frequent Contributor
timestamp: May 08, 2015, 03:53:38 pm
content: Quote from: janoc on May 04, 2015, 12:02:05 amIt 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.

author: westfw
author_rank: Super Contributor
timestamp: May 08, 2015, 11:24:33 pm
content: QuoteThere 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 drivers3) 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.

author: andersm
author_rank: Super Contributor
timestamp: May 09, 2015, 06:27:01 am
content: Quote from: westfw on May 08, 2015, 11:24:33 pmJust 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.

author: westfw
author_rank: Super Contributor
timestamp: May 09, 2015, 09:06:17 pm
content: QuoteReally? 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.)