I've got a strange problem with some code I inherited from another programmer who's left the company, and need some guidance on how to even begin to solve it.
The problem is this - on a semi-regular basis, we are finding that duplicate USB virtual comm ports are being created. For example, on my PC, when I view the Ports in Device Manager, and select "View Hidden Devices", I have two entries for the same device - one on COM6, and one on COM8.
Unfortunately, we cannot reliably re-create the problem. We suspect it may happen when someone quickly disconnects and reconnects the USB cable when our software is running, but that needs to be confirmed.
As far as I can tell, the code was written assuming that no one would ever unplug a cable. I see no logic whatsoever to detect this condition after the SW is started. And it fails when you re-plug the cable - silently generating read and write errors even after the cable is plugged back in. You have to restart the program before it will work again.
I have very little serial and USB experience, and am at a bit of a loss as to how to even get started on fixing this.
Can anyone suggest why this might be happening?
Misc. details, in case they might be relevant:
USB serial code is in a C++ DLL
VS2008
FTDIBUS USB/Serial drivers
Windows XP and Win7
Screen shot of duplicate Registry entries (note the value of the selected key!)
As explained on Raymond Chen's blog, the Old New Thing, here, and by commenters above:
https://blogs.msdn.com/b/oldnewthing/archive/2004/11/10/255047.aspx
To summarize:
Devices which are unplugged and plugged in again are tracked so they are not treated as a new device every time.
Usually this uses the device serial number to detect whether a device is the same one.
However not every device has a serial number. These devices are treated as the same device only if they have the same vendor ID and product ID and are plugged into the same port. If they are plugged into a different port they are treated as a different device.
Some manufacturers do not understand the word "Serial" in "Serial Number" and give all devices the same number instead of giving them numbers serially... To cope with this there is a registry setting which can be used to force these devices to be treated as if they have no serial number.
Therefore, if a device with no serial number or which is flagged in the Windows Registry as having duplicate serial numbers is plugged in to a serial port it has not been plugged into before, it will be treated as a new device rather than a reconnection of an old device. This will result in "Ghost" devices as you describe.
Some FTDI devices are specifically called out as having this problem by the manufacturer:
http://www.ftdichip.com/Support/Knowledgebase/index.html?ignorehardwareserialnumber.htm
Related
I am looking for a piece of software, or assistance with where to start for coding, that will let you select a USB device and convert its output signals (when buttons are pressed on the device) into keystrokes or configurable macros.
In more detail, I have this remote control (more accurately, a USB handset/phone) that sends USB signals depending on which button is pressed and the software I currently use converts those signals into keystrokes or macros. The software I currently use however is extremely limited, non-configurable and obsolete. The software which I retrieved from the CD that the device came in is simply named 'USBPhone 5 in 1' however there is no mention of this anywhere on the internet.
The device is unfortunately unbranded and also has very little visibility on the internet so I cannot see if there's any updated software or even any way to edit it.
Any help is greatly appreciated!
I think you need to start by getting basic understanding of the USB standard and device classes. Then you need to find out if your device implements a specific device class or some proprietary interfaces. Then you will either need to use a driver for the device class or implement a proprietary driver.
While USB is abbreviation from Universal Serial Bus, it is not transferring some random analogue data but well defined digital packets. The standard defines Audio Class for audio devices, Video class for video devices etc. Most devices implement one or more of those classes. For keyboards and mouse it defines HID class, which is most likely what your device implements. You can find HID device class related specifications here. It is not the most simple one to begin with, but it should work when you just plug the device to your PC and open e.g. notepad and start writing. USB device class codes are listed here.
In order to find out what device class your device implements, you need to read it's descriptors. In Windows one of the easier ways is to use usbview. You can read more about USB decriptors from here.
You do not mention what is your USB host (Windows or Linux PC, Mac or something else), so I am not going to go into actual USB driver implementation, but hopefully I was able to give you some information on what could be needed. In any case, if the device has some proprietary implementation, you will either need to have specification for it, or reverse engineer it by monitoring the USB packets. There are lots of expensive hardware solutions on the market for analyzing the USB traffic, but there are also some free SW solutions that might be good enough for your purpose. Quick Googling brought up this.
You can try joyToKey, this software do exactly what you want but with gamedpad. I don't know if it will work well with your USB controller.
http://joytokey.net/en/
The situation is as follows: I have a piece of hardware connected to a, windows running, PC via a serial port. This custom hardware is used to interface other hardware through GPIB. Now, the software that is used to operate this setup on the PC side needs to be changed without touching the hardware in the middle. The problem is getting a hold of the proper serial comm. parameters used for communication - setting them (the timeouts in particular - baud rates and bits are fine) to arbitrary values in the new software leads to a lot of comm errors so I'd like to know them precisely. The function GetCommTimeouts() would do the job, however you need the handle to the comm. device aquired via call to CreateFile() - only the original software has access to it. So the question is if one can get a hold of these settings from outside of the running, old app?
Thanks,
drinker
I would suggest using a tool like Process Monitor. This tool can monitor the calls that are used to open and configure a serial port.
I'm trying to make my program robust against network disconnections. Right now, if I disable ethernet network from OS (I'm over Ubuntu 11.10, but I guess that should not matter), my sockets recover once the network is enabled again and everything goes all right.
Since now I have supposed this test was the same as unpluging the ethernet cable. But it is not, since my program is suddenly terminating when doing this.
I want to know what's the difference between these two scenarios, and how to detect both of them. I'm using QTcpSockets from Qt and C++.
Also, when wifi is no longer detected, I guess it's equal to unplugging ethernet cable, while disabling it at the OS is equivalent to disable ethernet network. Am I right?
When the driver is enables, it means there is a program running at the OS kennel that manages different scenarios. For example, on cable disconnect, there is a link drop. And entering to low power mode.
When disabling the driver either there is a firmware on your device that could manage the device on, or there device will be off.
First of all, we are working with a 3rd party software that ties itself to a USB device. When this USB device is disconnected and reconnected, the software cannot communicate with the device will stop working until the program is restarted. i.e. It only detects the USB device on startup.
Windows is able to see the device, but goes through the full detection/driver installation procedure every time it is reconnected, even if it is reconnected to the same USB port.
The difficulty here is that we have no way of modifying the third party software to poll for the appropriate USB device after the device is unplugged.
As such, we would like to ask if anyone has knowledge on how to go about writing a c++ program to save a USB state/register, prevent Windows from re-enumerating the USB port upon re-connection, and restoring the saved state/register. If so, we would appreciate some guidance in this endeavor. Naturally, we are open to other approaches to solving this issue.
You can't do this at application level. USB is managed by drivers. Furthermore, while the details of USB devices are managed by specific drivers, the basics (such as enumeration) are handled by the standard Windows USB driver. That's logical: Windows has to enumerate the device first to determine its Vendor ID and Product ID, which then determines the specific driver to load.
As for the full reinstallation on every reinsertion, that suggests a violation of the USB spec by the device or the Windows API by the driver. My first guess would be that the device doesn't have a proper serial number.
I want to develop code to transmit data from system to PIC through USB.
Can anybody give good link regarding data transmission through USB.
because i am new to this.
NOTE: Very simple is code is enough to me.
Thanks in Advance
The PIC16F877 does not have a USB peripheral built in. I assume that the product that you are building is a "USB Device" and that the "system" that you are referring to will provide the USB host functionality. If this is the case then you will have to add a USB interface chip to your hardware to provide async serial to USB connectivity. Suitable devices are made by TI (TUSB series) or FTDI. You then connect one of these to the PIC internal USART and pretend that you are transferring the data over a simple serial port. If you are using a pc then the connected device will appear as a standard COMn: port.
I totally agree with the FTDI route, however if you're not looking for a UART tunnel over USB then you have to get a bit more in-depth.
You'll have to write the USB routines yourself or find libraries/projects for your processor. What you will definitely have to have is a fast clock - 12MHz is necessary More is better because on small uC's like these you'll spend most of your time just handling the basics of USB - signaling and so forth. You'll also need a fair bit of memory because the USB code takes up around 1.5K I think. Then you need room afterwards for your own code.
I've seen the V-USB (http://www.obdev.at/products/vusb/index.html). It's for AVR not PIC, but it says it provides all of the USB functionality you'll need and even provides vendor and product IDs for you to use (non-commercial I believe). There's also a PIC project for USB that doesn't run on the same hardware as yours here: http://www.alanmacek.com/usb/
To make the driver you'll have to use libusb - here's a link for the win32 version: http://libusb-win32.sourceforge.net/
It's surprisingly more simple than I had expected, but I just looked at example code and not actually made anything. Good luck!
As your task will involve Windows Device Driver development, I do recommend to downlaod and install the WDK and look through the contained sample USB drivers.
This might get you some hints about the complexity of the topic. Device driver development is not the easiest thing to start with.
Maybe you can start with UART communication (RS232).
check http://www.beyondlogic.org/usbnutshell/pic16f876.gif will surely help u
also
ttp://www.beyondlogic.org/usbnutshell/usb7.htm , type h in front of 2nd link.