I have an FTDI 232RQ chip that I used the FT_PROG application to change the VID on in order to use custom udev rules with it. However now that I have done that Windows will not enumerate it on a COM port. I can see the device and I can see that it has the correct settings. The chip is also no longer seen in my Linux environment.
I have used the FT_INF program to create custom ftdibus and ftdiport inf files using a clean download of the driver files from the ftdichip.com website. Attempting to install these new drivers that have the correct VID on them do not work and the chip reports ftdi chip cannot start code 10
I know now that I should have just changed one of the descriptor strings and keyed off the attributes string instead of the VID. But I can not get the chip to enumerate on a COM port so that I can reprogram the VID to be default.
Is there any way to fix this or is the chip just busted?
Related
I created an small embedded WinUSB device which offers 2 bulk endpoints. This device can communicate with Linux and with Windows10 without installing driver, or a .inf file.
Now we want to use the same API with a embedded Linux. The USB-Gadget mode offers Serial CDC/ACM and RNDIS-Ethernet and many more.
I was able to create a USB-Gadget with the gadgetfs which had only bulk ep. I could communicate with Linux and Windows host. The USB-Device had /dev/ttyGS0 to communicate. But in Windows I had to install WinUSB driver manually.
I work with yocto to create embedded kernel.
I added some line of code here: /linux-imx/drivers/usb/gadget/legacy/serial.c , f_serial.c, u_serial.h to add additional variable os_desc and parameter use_winusb. But the resulting g_serial still creates a COM-Port in Windows10 or a no WinUSB device. For our device we need WinUSB-Device only.
The RNDIS Gadget does has WinUSB support. So I tried to create a own USB-Gadget device with https://github.com/libusbgx/libusbgx. But if I use the USBG_F_SERIAL function type then it can't create WinUSB. See error:
Error setting function OS desc
Error: USBG_ERROR_NOT_FOUND : Not found (file or directory removed)
If I use USBG_F_RNDIS, it works, and with manipulated USB descriptor it'll recognized by Windows as WinUSB device. But Linux implement's it as USB-ETH ethernet device. The USB-Device get's no /dev/ttyGS0 serial connection to communicate.
I'm reading the Linux kernel driver source now, to find the position, where I can simply ann this WinUSB os-descriptor stuff into the USBG_F_SERIAL type. But I think it'll take month to get through.
Any solution would be ok. Patch for the Linux driver sources g_serial or how to configure a USB-Gadgetfs would be great. Any hint, where to put additional code would also be fine.
I wanted to change the kernel, but fortunately found this:
https://blog.soutade.fr/post/2016/07/create-your-own-usb-gadget-with-gadgetfs.html
This code made it easy to add WinUSB features.
Source of modified Version for WinUSB: https://github.com/rundekugel/gadgetfsd/tree/WinUSB
I have a USB controller (STMicroelectronics) which comes with a default VID and PID. When plugged in Windows will install the appropriate drivers automatically. What I want to do is define my own VID & PID (would be officially registered) and still use the same driver. I want to have my own VID & PID since I want to make sure that my program does not try to talk to any device which happens to be using the same USB controller. I've gotten this to work fine on all but Windows 8, because of the stricter driver signature requirements. Is there any way to make this work without modifying/signing the drivers, or should I look into another way of uniquely identify the device as my own? The end user of the device should not be required to do anything out of the ordinary to make the drivers install (especially on Win8).
I have developed a USB device that communicates with linux over a simple but proprietary interface and some custom Linux drivers. My goal is to port this to Windows without writing windows drivers. What I would like to do is find an open source or inbuilt class driver for windows that would look like a COM port in Windows. Then I would tailor the embedded software to match what ever protocol and descriptors the virtual COM port expects to see.
The idea would be that I could plug my device in to a Windows machine and a relatively high speed COM port would appear with out me having to develop Windows drivers for it.
I have been looking at the USB CDC (Communications Device Class) documentation and it looks promising, but I don't know which sub interface would be best to use so that it would show up as a COM port.
Has anyone here done any work like this before or could provide some insight?
Specifically:
Are there virtual COM drivers "built in" to windows or would I need a 3rd party driver.
Which CDC sub class should I use for simple RS232 emulation (No need for modem AT commands, etc)
Is there a better option to do what I am trying to do.
Thanks
There is a USB-to-serial driver built in to Windows that will do what you want. It is called usbser.sys:
http://support.microsoft.com/kb/837637
You will have to write an INF file and distribute that to your users, but that will not be too hard because it is only a few kilobytes of text and you can find examples online.
I'm not aware of any great documentation for this driver by Microsoft, so my advice would be to find some other device that uses it, such as Pololu Wixel, and copy what they did.
Here are the device descriptors we used and the special control tranfers we had to implement:
https://github.com/pololu/wixel-sdk/blob/master/libraries/src/usb_cdc_acm/usb_cdc_acm.c
You can see our INF file, wixel_serial.inf, by downloading the software and looking in the drivers folder:
http://www.pololu.com/docs/0J46/3.a
(There are other files in there that are not necessary for you.)
You can also look at the Arduino Uno because they use the same driver.
Whatever you do, please don't use our USB Vendor ID in your product! You need to get your own.
Update: In Windows 10, you don't need an INF file anymore because of the new usbser.inf driver that comes with Windows.
If you are using a UART you can easily interface it to a FTDI USB chip like http://www.ftdichip.com/Products/ICs/FT232R.htm or a Prolific like http://www.prolific.com.tw/eng/products.asp?id=59
For development, prototype and testing I have half dozen of these laying around http://www.pololu.com/catalog/product/391
I connect it directly to the UART pins on AVR and 8051 micros.
We are creating small system which has GPS receiver and PC. We want to test my GPS receiver, We do not want to go for a driver on the first go. First I would like to test my circuit works or nor. GPS IC has been set to output NMEA sentence. We want a program which just reads data from USB port and print it on the screen.
Can we write something like this easily ? Do we have any open source tool which will achieve this purpose ?
Platform : Windows 7
All devices need a driver, so I'm going to interpret your question as "how can I read NMEA data from my GPS using only drivers provided by the OS, so I don't have to write my own?"
If the GPS chip has a USB interface, then you should have gotten a driver with it. But most GPS chips have a UART interface which in your case sounds like it is connected to a separate USB-UART conversion chip. That conversion chip most likely came with a driver as well, but if not, you could jumper the reset pin of the converter chip, disabling it, and then attach a TTL/RS-232 level converter (available off-the-shelf) to the UART traces and then to your computer's serial port.
Unless you suspect that the driver for the USB-UART converter is causing problems, I wouldn't bother.
Anything connected via USB is a device. Devices require a device driver, period.
You might be able to get away with an existing driver built into Windows. This is how USB memory keys work for example - they present a generic device that looks like a removable disk, and Windows already includes the drivers for generic removable disks.
You would need to check the documentation for your device to see if it can emulate a device which already has drivers. Otherwise you must install the company's drivers, or you're out of luck.
Have a look at libusb. You should be able to read the data with that and a little code. (Yes, it's a driver. I take the question to mean "without writing a driver".)
You need a device driver for your device. Unless Windows already have a class driver for the device.
For USB devices on Windows 7 you can write a user-mode driver, see UMDF.
This may not be considered to be directly programming related but I am at a loss to know where else to ask. I have tried looking at a variety of websites but so far Google has not been my friend.
I am having trouble finding out whether I need to write my own device driver for the various windows/linux/mac platforms that the device I am developing may be connected to, or whether the functionality is provided by the standard drivers.
My device is a USB CDC (communications device) that appears as a COM: port. It also includes a battery charger that will, once the device has been enumerated require the full 5 unit load (500mA) supply current that can be drawn from the USB connector. My problem is that if the USB driver in the host decides that it cannot deliver the full supply current then it should fail to enumerate the device.
If, as a fallback, I provide a second configuration set that only allows the device to draw 1 unit load from the interface connector will the standard drivers enumerate the device using this configuration.
You need to write a .inf file for Windows that ties up your device VID and PID with the system usbser.sys. Mine looks like this (Replace YourCompany as necessary, put in your VID and PID (in hex), and change the DriverVer line to whatever date and version you want):
; -----------------------------------------------------------------------------
; XP/2000 USB Comms Port Setup
; -----------------------------------------------------------------------------
[Version]
DriverVer=12/03/2008,1.0.0000.0000
Signature="$Windows NT$"
Class=Ports
ClassGUID={4d36e978-e325-11ce-bfc1-08002be10318}
Provider=%YourCompany%
[DestinationDirs]
DefaultDestDir=10,system32\drivers
DriverCopyFiles=12
[ControlFlags]
ExcludeFromSelect = *
[Manufacturer]
%YourCOmpany%=YourCompanySerialPort
[YourCompanySerialPort]
%YourCompanyUSBSerialPort%=YOURCOMPANYUSB,USB\VID_1234&PID_ABCD
;
; Win 2000/XP
;
[YOURCOMPANYUSB]
Include=mdmcpq.inf
CopyFiles=FakeModemCopyFileSection
[YOURCOMPANYUSB.HW]
AddReg=YOURCOMPANYUSBAddReg.HW
[YOURCOMPANYUSBAddReg.HW]
HKR,,DevLoader,0,*ntkern
HKR,,NTMPDriver,,"usbser.sys"
[YOURCOMPANYUSB.Services]
AddService=usbser, 0x00000002, FuncDrv_Service_Inst
[FuncDrv_Service_Inst]
DisplayName=%USBFilterString%
ServiceType= 1
StartType = 3
ErrorControl = 0
ServiceBinary = %12%\usbser.sys
[Strings]
YourCompany="YourCompany"
YourCompanySerialPort="Your Company USB Serial Port"
USBFilterString = "USB Serial Service"
Note this works with 32 bit OSs only. It also works with Vista although the file header doesn't say so!
Be aware that some versions of usbser.sys have significant problems, including bluescreening, for example when transferring packets that are exact multiples of 64 bytes. If you're using XP SP2 or previous then install hotfix KB943198. XP SP3 and Vista are fine.
For the Mac you simply need to report your device class correctly and the driver scan picks up the correct drivers. (Windows ignores the device class which is why you need to supply the .inf file).
EDIT: Sorry, I should have been clearer. This will not fail to enumerate if it can't draw the full load - I'm not sure that's possible.
You are correct on the driver question. When the device is plugged in and goes through the enumeration process it is required to stay < 100mA. The host will interrogate and determine the configuration(s). If there are more than one which support different power levels, then the driver will need to decide to select the appropriate configuration. If there is only high-power and it is not available, then it will not enumerate the device. In general, the standard driver doing CDC wouldn't be aware of the different device level configurations that would possible and so would require some degree of customization to handle them.
I am not sure about power question but ther is pleanty CDC drivers (or I think there is) so you could use one. For the power question, the solution with many configuration is probably good one, I have never encountered this in work (I have USB analyzer) but at home sometimes when I have 3 or more different devices that requires power from USB I got failed enumeration. I supose this is operating system choice if it can't supply power to new device it cut's it off (sensible choice as it can't power it). This is my gues rather checking USB standart.
If your device reports a device ID that the host OS already supports,
then they won't need a driver.
You may need to impersonate an existing USB uart. Data sheets are readily available.
(But I figure you already knew that.)
I'm not sure that the host OS will honour your multi-configuration idea.
But give it a punt so we all know!
If your device is connecting as USB CDC-ACM device to the windows desktop host, the windows desktop already provides the driver usbser.sys. But there are some some issues in windows Vista. You just need the inf to install the usbser.sys on desktop. For WinCE you do not have the driver and for you need to write or get one from any third party vendor. Here is one
http://www.em.avant-garde-lab.com/Products.html
If your device specifies itself as self powered in its device descriptor then the host would rely on the devices self power capability. You can check at usb.org for details.
Thanks.