I would like to know the DeviceID and PNPDeviceID format for PS/2 Mouse. On my system Device ID for PS/2 mouse is ACPI\PNP0F13\4&1F1D307&0. So is the format is ACPI\PNPxxxx{something} or some thing else? I mean is ACPI is mandatory for PS/2 mouse?
The PS/2 port is not on a bus that can discover all devices connected to it. i.e. it is not Plug-n-Play. Therefore the OS relies on the system's firmware to find all the devices that would otherwise be undiscoverable. On modern x86 systems, this mechanism is ACPI. However, older OSes such as Windows 95 used a different firmware interface called PNPBIOS to do the same thing. the PNP0F13 pnpid is a carry-over from PNPBIOS. The ACPI\ prefix is there to indicate that it was enumerated by the ACPI bus driver. The Windows driver model hides such details from the mouse driver -- it can just list the pnpid in its .inf, and get an AddDevice irrespective of what platform enumerator its device was found by.
Of course, PS/2 mice existed before ACPI and even Win95. Back when you used your mouse on DOS, the device driver just assumed the port was at a particular io or memory location, and probed those itself. Fun!
Related
The Microsoft article "USB serial driver (Usbser.sys)" tells that:
If you want to load Usbser.sys automatically, set the class code to 02
and subclass code to 02 in the Device Descriptor.
If I program a STM32 MCU with a CDC example with 02 class code (CDC) and 02 subclass code (ACM), the usbser.sys loads. And this makeshift USB-UART bridge detected as "Ports (COM and LPT)/COM5". If I use some USB-UART bridge IC (like FT232), commonly it's class is "Vendor specific" and they need a vendors driver. If the vendor driver has install this devices are also detected as "Ports (COM and LPT)/COMx"
The Cypress USB-UART bridge CY7C65213 has 02/02 class/subclass in the descriptor. But without the Cypress driver, this IC detected as "Other devices/Virtual Serial Port Device 00".
Actually, I can install the Cypress driver, this IC will detected as COMx and my soft will work well.
But I want to understand why the usbser.sys driver is not loading with this device? How can the Windows understand that some USB CDC-ACM devices need the usbser.sys and the other don't need this driver? Is the difference in the descriptor or somwehere else? What instruments shall I use to spot the difference and to tell one devices from other?
If you open C:\Windows\inf\usbser.inf in a text editor you can see what kinds of devices it matches:
[Standard.NTamd64]
%UsbSerial.DeviceDesc% = UsbSerial_Install, USB\Class_02&SubClass_02&Prot_01
%UsbSerial.DeviceDesc% = UsbSerial_Install, USB\Class_02&SubClass_02
This part tells us that it only matches devices that have a compatible ID equal to "USB\Class_02&SubClass_02&Prot_01" or "USB\Class_02&SubClass_02&Prot_01". I am guessing your Cypress device either doesn't have those compatible IDs, or it has some other driver that is matching that device using more specific IDs.
You can see the compatible IDs of your device by double-clicking on it in the Device Manager and going to the Details tab. It also helps to view devices by connection so you can know whether you are clicking on an actual USB device or just one of its child devices.
Question: Why the usbser.sys is not used with a USB CDC-ACM device?
Answer: usbser.sys is for USB CDC-ACM devices but your device isn't a USB CDC-ACM device.
Question: But I want to understand why the usbser.sys driver is not loading with this device?
Answer: see above
Question: What instruments shall I use to spot the difference and to tell one devices from other?
Answer: Use any tool or software that can read the USB device descriptor and configuration descriptor.
Question: How can the Windows understand that some USB CDC-ACM devices need the usbser.sys and the other don't need this driver?
Answer: It reads the device descriptor and configuration descriptor. If it contains a USB CDC-ACM compatible device, it will load usbser.sys. The requirements for USB CDC-ACM are described in the associated USB specification. In short, it requires two USB interface in a particular order, linked by an interface association descriptor and with the correct class code / subclass code (in the interface association descriptor).
Question: Is the difference in the descriptor or somwehere else?
Answer: Yes, the difference is in the descriptors (device and configuration).
Note: On Windows 8 and earlier, usbser.sys is not automatically loaded as mandated by the USB standard. A manual installation (possibly in conjunction with an INF-file) is needed.
I recently got an Arduino Leonardo, and I'm fascinated by its ability to emulate USB HIDs.
But from what I can see, there are only libraries for keyboard and mouse emulation.
Is it possible to make it emulate a printer, microphone, headphones, anything other than a mouse or keyboard?
Yes, assuming that the device is HID compliant. You would just need to simulate the signals.
That said, it's unlikely that these other devices are HID compliant. They might, however, be class-compliant. Class-compliant means that you don't need special Windows drivers to plug it in and use it. There are a number of devices that are class-compliant; here is an example.
In the case of your Leonardo, it does not appear to be generally class-compliant, but more specifically HID compliant. I suppose, however, that you could write a driver on the Leonardo to make it class-compliant (for some other class).
See Also
USB Device Classes
You can use the LUFA toolchain to build much more than a few Leo examples.
It is possible to emulate any HID device with Arduino Leonardo, Pro Micro or their clones. It is not possible though with the stock Arduino HID library because it supports only SendReport method (Interrupt pipe), while generic HID support requires SetFeature/GetFeature methods (Control pipe).
Without going too deep into the theory of HID protocol implementation, you may check the emulation of the HID-compliant UPS on Arduino and implement something similar for any device class.
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.
http://www.microchip.com/forums/m522571-print.aspx
Any ideas? Thanks.
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.
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.
we are developing a sendor device, with a arm7(current: LPC2368) .
this device samples a mv signal,A/D, and need to send this signal data to the PC.(continusly)
at the same time, PC need send command to arm7 (like get temperature, control status, etc..)
rs232 is too slow, so we choose USB.(20K/s - 200K/s)
but the question is, we donnot known how to do usb programming(both pc and arm..)
any direction? any portal? any tutorial?
currently we only sim the device as a HID....
For the ARM side you need a USB Stack. For the PC side you need to implement an USB driver and an application interfacing the driver. It is therefore easier to stick to one of the common profiles (HID, Mass Storage, Virtual COM). For all these you will be able to find USB stacks and not to have to implenent your own. Also you won't need to implement a USB driver for the PC.
I think that the easiest thing to do is to use a Virtual COM approach. From the PC side it would like you are accessing a Serial Port. The speed however can be higher than standard RS232 ports. I have found this USB Stack targetting an earlier processor. You could adapt it for your needs or use it as reference. Generally a Virtual COM driver for the PC will be provided along with the ARM USB stack.
Another approach is to use libusb. This will allow you to interact with USB without writing a kernel driver.
For application notes and commercial USB stacks look here. If you are determined to write your own stack and driver, Jungo is the industry leader for embedded USB stacks and drivers.
I have a device that came with an AC power adapter where the connector is a mini USB plug. The device however doesn't seem to power itself from a computer's USB port (using a standard USB-mini USB cable) unless a specific driver is installed. The driver is only available for Windows. I would like to charge the device from USB plugs on different platforms.
My question is: why isn't power getting to the device without the driver? Is a driver always required for a USB port to start giving power? Or is it this device that's specifically made not to take a charge unless some software routine triggers it to do so?
I guess my question can be summarized as: Is power not present on the USB cable or is it present but the device ignoring it. If the answer is the former, I'll be trying to figure out how to write software that will enable the voltage to always be present.
Thanks
Why isn't power getting to the device without the driver?
USB ports are always powered when the computer is on and the USB control software hasn't detected current overdraw.
Is a driver always required for a USB port to start giving power?
No, the USB port is always required to start off providing power to the device, otherwise the device could never initiate a connection.
Or is it this device that's specifically made not to take a charge unless some software routine triggers it to do so?
This can be complex. To meet the USB spec a device cannot pull more than a few mA until it's registered with the computer.
However, nearly every computer allows the USB port to pull the full 500mA (and more) before it'll shut the power off.
The device you're charging is being nice by not pulling any significant power until the computer gives permission.
Writing software won't help, the device has to register with the USB bus, which will best be done with the driver.
However, the plug in charger doesn't do that. It likely has shorted the two data lines of the USB plug together, which signals the USB device that it's not connected to a computer and can pull the full 500mA without waiting.
Take a USB extension cable, cut off the jacket, and short the data lines (green and yellow, sometimes) together on the end going to the USB device, and leave them cut without touching anything on the end going to the PC, and leave the read and black power wires connected through.
It might work. If not, take the wall charger apart and find out what it's doing with each of the four USB wires, and see if you can duplicate that.
This might be helpful if you are targeting a linux system.
This seems to be platform-specific. In Linux, USB ports are always energized, while on Windows they don't. Thumbdrives with LEDs turn off when unmounted in windows, but in Linux they stay lit. My cellphone's manual says that it can't be charged by a PC, but I regularly do on my linux machine, I guess that's because they don't have a driver and windows won't power up without one.
Have you tried plugging it into a 'dumb' USB port - like the one on a car charger? Those ports are pure power and don't create a USB network. I think.
Unless you have the hardware specs from the manufacturer, I think you are out of luck. You could try reverse engineering the driver to see what it does, but I'd expect it would be cheaper and easier just to buy one with cross platform drivers or charges without the driver.