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.
Related
For USB Host Controllers there are the UHCI/OHCI/EHCI/XHCI specification that define how to program a driver. Is there an equivalent specification for USB Device Controllers?
No. Generally, every USB-capable microcontroller has a USB block that you can control by writing to some registers in your code, but those registers are pretty different on the different microcontrollers and I have not heard of any attempt to standardize them.
I need to write a number of drivers for both HID USB devices as well as some old serial devices. The drivers are to pull data off the device and then send the data over to an application that then consumes it. Since the Apple Docs mention that a lot of USB and HID communication can be done from the user space I had assumed that I would not need to write a kernel extension, at least not for the HID devices. Could some one tell me a more solid way to determine this?
Thanks!
If you're writing a single application that must talk to one or more USB HID devices you may well find you can just access the devices straight from the application using the application-level USB APIs.
A kernel driver would be more for something like a networking or mass storage device that needed to integrate with the kernel to be be available to multiple applications.
This Apple document Common QA and Roadmap for USB Software Development on Mac OS X goes into some detail on the matter and links to example code too.
I want to write a usb touchscreen kext for usb touch screen .
I have read the Kernel Extension Programming Topics and the I/O Kit Fundamentals etc,
My question is,
1 . how to get the input report messages from touch screen ?
2 . how to post the coordinate info to system ?
I have no idea, anybody help?
It depends on the hardware; moreover, this question is quite broad - you'll need to be more specific in your question to get more specific answers. I'll try to provide a broad overview:
A touchscreen has 2 parts:
Output: showing the image coming from the computer on the display
Input: the touch events to feed back into the computer
As you haven't asked about (1) at all, I assume your device just plugs into a display port on the Mac and is already displaying correctly. If not, you'll want to look into the IOFramebuffer API.
For (2) - Pretty much all USB input devices are HID devices of some form. If you're new to HID in general, you'll probably want to read and understand the USB HID specification and related documentation as you'll be using that information throughout.
OSX already comes with comprehensive support for the standard HID device classes such as keyboards, mice, touchpads, graphics tablets, etc. If your device claims to be any kind of HID device, OSX should already be detecting it and attaching its generic HID driver to it. You should see a IOUSBHIDDriver instance in the I/O Registry (eg. using Apple's IORegistryExplorer tool, or ioreg on the command line).
I'd also expect your device to conform to HID's absolute pointing device profile, so at least single touches should already be working properly. If it's a multitouch device, or you need other extra features, you'll probably want to implement a IOUSBHIDDriver subclass that generates or converts the necessary multitouch events.
If your device for some reason isn't already a HID USB device, you'll need to write a custom USB driver for it, and convert the events coming from it into HID events, as the HID events are passed directly into userspace and processed there. You can actually write USB drivers and generate HID events from userspace, so you might be able to avoid writing any kernel code at all if you prefer.
Apple provides some documentation on HID:
The HID Class Device Interface Guide covers some general concepts and the userspace interfaces.
The Kernel Framework Reference has API documentation for the various IOHID* classes in the kernel.
If you're going to be writing your own kernel HID device driver, your best bet is probably the IOHIDFamily source code. You can probably also find some open source examples around the web.
Apple's USB mailing lists is probably also worth checking, both for the archives and if you have questions. The darwin-kernel and darwin-drivers lists are also relevant.
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.