Hi all,
We have a USB product using an EFM32 CPU that normally appears as a USB Mass Storage device and does not require drivers. However, it uses the USB-CDC (USB serial port) configuration for special purposes such as firmware updates, and we may offer new products in the near future that use this in mainstream operation.
What is the 'official' recommended way for (our) end-customers to get the CDC driver?
It doesn't seem to be on e.g. Windows Update, nor could I find a public download link on silabs.com. Based on some forum crawling, the only way to get it seems to be by fishing it out of a large dev tool download (http://community.silabs.com/t5/32-bit-MCU-Knowledge-Base/EFM32-USB-CDC-driver-location/ta-p/158930) .
Is it accepted/recommended to package a copy with our own software downloads*, republish it on our own website and/or (as I believe the support folks have *actually* been doing), hand out dropbox.com links as needed? Are there any near-future plans to make it available via Windows Update?
* There's always a catch: There is an optional software tool that goes with the product, but it just unzips and runs and doesn't require 'installation', so it also doesn't present a good opportunity to preinstall Windows drivers.
Thanks!
Just specify Windows 10 as required Operating system - problem solved.
Windows 10 supports USB CDC out-of-the-box.
Turbo_J wrote:Cubase asio directx full duplex driver. Just specify Windows 10 as required Operating system - problem solved.
.. except for those users not running Windows 10.
Agreed; this is not a solution. There is currently nothing else preventing us from supporting all the way back to WinXP - and yes, there are still some customers using that (or 'XP Mode' in later versions)! It turns out a lot of industrial control equipment is tied to legacy software, including an expensive (and fairly new!) piece of equipment we use to calibrate this very product.
Microsoft has been distributing a USB-CDC driver with Windows for years already. I think all the way back to Windows XP. But before Windows 10 they never provided a signed default .inf file with it (like they did for e.g. USB-MSD). For Windows XP it's not so hard to make one since it warns you once about an unsigned driver and then happily lets you install it. Later versions became more and more restrictive making things harder for you and me. Until Windows 10.
Note that you are not allowed to ship a product with the Silabs/EnergyMicro VID/PID pair, thus the default .inf file would be useless for any end user product. You will have to edit it - replacing the VID/PID with the correct numbers, and probably also the strings for the device that will show up in device manager.
I see no reason that should prevent you from shipping the edited .inf with your product, but IANAL.
Windows versions up to 7 will allow installing an unsigned .inf file for a driver.
Note that the composite CDC interface in the EFM32 example code will not work with windows XP SP2 and earlier, resulting in blue screen when used.
See also: How to optain USB VID/PID pair
Turbo_J wrote:Note that you are not allowed to ship a product with the Silabs/EnergyMicro VID/PID pair,
Not allowed by whom? Last I checked, the USB-IF has no legal power over the use of VID/PID values, otherwise it would not be possible for SiLabs and other vendors to sublicense individual PIDs (as the USB-IF terms explicitly forbids this). Given that the product contains a SiLabs Chip using the SiLabs bootloader, which comes pre-burned on the chip with the SiLabs VID/PID baked in, I don't suppose SiLabs would object to this scenario (although I would welcome an actual SiLabs employee chiming in on this).
I don't suppose every vendor selling a product with a PL2302 or FTDI serial chip buys their own VID/PID, changes it on the chip and then pays to maintain their own Microsoft Digital Signature and WHQL certification on their custom-modified .inf text file, which they separately push to Windows Update?
Turbo_J wrote:Windows versions up to 7 will allow installing an unsigned .inf file for a driver.
Only the 32-bit versions, and not without protest at that. And again, we do not intend to enforce OS limitations on the customer over a silly text file if this can be avoided (say, by using the already signed text file that already exists).
Drmn4ea wrote:Turbo_J wrote:Note that you are not allowed to ship a product with the Silabs/EnergyMicro VID/PID pair,
Not allowed by whom?
The Operating System (you know, like Windows). They use VIDID to assign drivers. This means you cannot change the USB descriptors to get rid of the component device, for example, as this may confuse the OS. You would need at least a new PID here.
Note that libwdi shows a way to distribute an unsigned .inf file and install it in windows without any error or warning message. It generates the certificates on-the-fly.
It looks like I will just need to submit a support ticket to get a real answer on this.
Does anybody know if it's possible to emulate UART (simple serial transmit and receive) over USB? How would this be accomplished?
I found this link on the Microchip website, but it's not very forthcoming.
Any ideas? Thanks.
Basically you have two options to emulate UART over USB:
Use an existing product. The company FTDI provides well known and solid UART-USB bridge chips, e.g. FT230X. Pro: You don't need any detailed knowledge about USB. Cons: Expensive if used in mass production. Additional hardware, needs additional power.
Implement the USB device class 'Communication Device Class' (CDC). The specification of CDC is available from the USB.org, see here. Pro: Cheap in mass production (if your Microcontroller has USB on board). Con: You need detailed knowledge about USB.
You need to implement the device stack as a CDC ACM device (also known as Virtual COM port or VCP). Most vendors of microcontrollers with USB support have example code or app notes.
Given that, your device will look like a COM port as far as Windows is concerned. At the device end, you will get raw blocks of data transferred. An appropriate abstraction layer can be implemented for both UART and USB interfaces to give then the same interface if necessary.
One gotcha is that USB devices require a Vendor ID allocated by the USB Implementer's Forum, at a $5000 fee(correct 23 JUly 2016). If you are going to release your device in the wild, you really will need one if your device is to be recognised and behave correctly with other devices. Some microcontroller vendors will allow you to use their vendor ID for a subset of product IDs for free or a smaller fee, but they might only do that if you were purchasing significant quantities of devices from them.
Another issue is that while on OSX or Linux a CDC/ACM is recognised without any additional drivers, Windows is more fussy and required an INF file to associate the specific USB Vendor and Product ID to the usbser.sys driver. Then you get into the whole world of driver signing, which is essential if using Windows Vista 64, or any version of Windows 7. A code-signing signature will also cost you money. If your vendor has provided example VCP code, they will also probably provide a signed driver. STMicroelectronios's STM32 VCP example is even WHQL certified so can be acquired automatically via Windows Update.
So the upshot is that for experimentation you can do it if your vendor already provides code and a signed driver (or you are not using Windows), but to deploy a product you will need an Vendor ID and a code-signing certificate. It is a bit of a minefield to be honest.
A simpler approach is to use an FTDI USB<->Serial chip. This is especially useful for a microcontroller without a USB controller of its own, but the data transfer rate will be limited by the micro's and/or the FTDI's UART interface rather than USB speed. An FTDI chip can be used as-is using FTDI's VID/PID or you can customise it with your own VID/PID. Customising puts you back into needing to acquire a VID and a signing certificate, but allows your device to be identified uniquely rather than as a generic serial port.