I have an xHCI USB host controller connected to processor with an OS that has only eHCI host driver support. Does the eHCI driver support/compatible with xHCI controller. Only USB2.0 devices are required to be connected to the host. USB3.0 device support is not necessary.
Its completely impossible as there is a huge difference between the EHCI and XHCI interface. The whole way of USB transfers have changed. The data structures changed. Only Register interface remained compatible.
Its simply impossible. I am guessing by now you already know the answer.
Related
I'm trying to implement UART over a USB interface on the STM324x9I-EVAL development board. The purpose is to send commands to a servo controller (or other hardware, for that matter) serially. I've successfully implemented the USB_Device_CDC example on the development board but am unsure exactly how this works without a PC with drivers on the other end. As far as other hardware is concerned, will the USB port now simply look like a serial port? Or is there still a need for a driver or some sort of interface on the other end?
I do want to point out that I'm aware of the following post:
Emulating UART over USB
but I don't believe my question is fully answered within the context of that answer.
A USB connection is not a peer-to-peer connection like a UART. It requires a host and a device in a master/slave relationship. The device cannot initiate data transfer; it must be continuously polled by the by the host.
A CDC/ACM class device presents a virtual COM port on a PC host, but that does not allow the device to communicate with a UART interface. It looks like a serial port at the software level, but does not implement a UART physical layer. There is an awful lot going on under the hood to make it look like a PC serial port, but none of it resembles UART communications at the physical level.
There are devices that act as UART/USB bridges (from FTDI and Prolific for example), and you could (somewhat expensively) build your own from a microcontroller that has a USB device controller and a UART, but the bridge is a USB device and must still connect to a USB host; these are normally used to connect a PC to a microcontroller that lacks a USB controller or where the software/CPU overhead of using a USB controller is too great.
In theory you could connect a microcontroller that has a USB host controller to one that has a USB device controller, but you need host and device software stacks on each respectively, and once you have the USB connection, implementing CDC/ACM is a somewhat inefficient use of the available bandwidth. The purpose of the CDC/ACM class is primarily to allow "legacy" software to work on a PC.
If you need to connect to a "real" serial port, you should use a real UART - which are far more ubiquitous than USB controllers on microcontrollers in any case.
You should learn a little bit about USB device classes. CDC is a USB device class, and ACM is a subclass that I assume you are using. The device you made could be called a "CDC ACM device" because it uses the CDC class and the ACM subclass.
These classes and subclasses are defined by the USB Implementers Forum in documents that you can find here:
http://www.usb.org/developers/docs/devclass_docs/
These documents specify things like what USB descriptors a CDC ACM device should have in order to describe itself to the host, and what kinds of interfaces and endpoints it should have, and how serial data will be represented in terms of USB transactions and transfers.
Note that CDC ACM only specifies some USB commands for transferring data between the host and the device. It does not specify what the device will actually do with that data. You can use CDC ACM to implement a USB-to-serial adapter, or you can just use it as a general purpose communication interface for whatever data you want to send.
Yes, you do need a driver on the PC side. The driver needs to be designed to run on your specific operating system. It needs to create some kind of virtual serial port device in your operating system that other software (which only knows about serial ports) can find and connect to. It needs to translate serial port operations performed by other software on the serial port (e.g. writing some bytes to the serial port) into low-level USB commands according to the CDC ACM specifications (e.g. sending some bytes out to the device on a particular endpoint in the form of USB packets). It needs to somehow know which USB devices it should operate on, since not every USB device is a CDC ACM device.
For Windows, you will probably use the usbser.sys driver which comes with Windows. For versions of Windows older than Windows 10, you will need to write an INF file to associate your device to usbser.sys and sign it. For Windows 10 and later, there is a new INF file called usbser.inf already included with Windows which will automatically match any valid CDC ACM device. This means you don't have to write or distribute a driver for CDC ACM devices if you only intend to support using the device on Windows 10 or later. The partnership between Microsoft and Arduino which began in 2015 gives me hope that Microsoft will continue supporting and improving usbser.sys in the future. In fact, they claim that in Windows 10 "the driver has been rewritten by using the Kernel-Mode Driver Framework that improves the overall stability of the driver", so that is good news.
For Linux, there is the cdc_acm kernel module, which has been a standard part of the kernel for a long time and should work automatically with any CDC ACM device you plug in.
For Mac OS X, there is the AppleUSBCDCACM driver, which should work automatically with any CDC ACM device you plug in.
Note that for any of these drivers to recognize your device and work with it, your device has to have certain values in its USB descriptors, and the requirements can vary depending on what exact driver version you are talking about.
Will the USB port now simply look like a serial port?
No, that's the wrong way to think about it. The USB port will still look like a USB port, but the various USB drivers provided by your operating system will recognize that a CDC ACM device is plugged into that port and create a new entry in your operating system's list of serial ports. Then if you run some software that only knows about serial ports, it can connect to that port.
In fact, if you make a composite device, you can have a single USB device plugged into a single USB port that actually has two or more virtual serial ports.
When I plug a USB web Camera into a PC via USB, what communications is used? I know each device COULD have its own uniques driver, but it seems as though 99% use a common built in driver now. Where is it spec'd and how do you get a linux embedded device to act like a webcam?
What you're looking for is the USB Video Class and you can download the specification for this and other standard USB device classes here:
http://www.usb.org/developers/docs/devclass_docs/
The Linux USB gadget framework has code to emulate such a device:
https://github.com/torvalds/linux/blob/master/drivers/usb/gadget/function/f_uvc.c
I want to connect a USB peripherals to a FPGA. Basically FPGA should act like an USB host. Is there a FPGA board support a USB hub so that one could connect multiple(upto 4) USB peripherals at a time.
I have a Digilent Nexys3 fpga which is based on Spartan 6. It supports only one USB device (keyboard or mouse). It doesn't support a hub. I have found Cypress host controllers, but I am not sure how to use it in a FPGA.
You need to have a USB host controller inside your FPGA, such IP is not freely available, one alternative is to use a Zynq based (for Xilinx) or Cyclone V based (for Altera) board. Those have integrated USB controllers connected to their dual ARM core.
You can find more info about those at:
Altera Cyclone V
Xilinx Zynq
You maybe able to use an external host controller but then you have to connect it to your FPGA and that is usually requires a lot of IOs and those modules are more expensive than buying a Zed board ($395) or Cyclone V board ($450).
A device has USB OTG support. Following are scenarios:
When a device is connected to a PC, the device acts as slave. (How does the device know it has to act as slave?)
When a device is connected to a printer, the device acts as master.
(How does the device know it has to act as master?)
What are the steps executed when a device is connected to OTG?
How to implement this mechanism (in brief)?
The exact behavior of USB OTG devices is described in the specification you can find at usb.org. There is a PDF inside the zip called USB_OTG.
The Host Negotiation Protocol in section 6 covers how two OTG devices decide which one is getting the embedded host. Basically this is archived by driving pull-up and pull-down resistors on the D+ line.
Note: When talking about USB the terms master/slave are not used. The master is called host and powers the bus whereas the slave is called device. In the case of OTG (in general, see specification for exceptions) both parts have the capability to be host or device. When the host was figured out by the Host Negotiation Protocol, this part becomes the so called embedded host.
In the two scenarios you mentioned the USB device is able to know whether to be a host or device by the cable. USB cables (non type-C) are not symmetrical. One side is host and the other is device. There is a pin on the connector called the ID pin which is floated on the device side and grounded on the host side. This allows the USB controller on each side to know which side of the cable it is connected to and thus which role (host or device) it should be when connected. These types of devices are called dual-role devices.
If you have a such a device, then you can plug it into a regular host (like your laptop) and it will act as a device. And you can plug it into a regular device (like a printer) and it will act as a host. This is all based on the cable.
If you plug two dual-role OTG devices to each other. Their initial roles are determined by the cable in the same way.
After the initial roles are determined, they can then swap roles from their initial cable-determined roles via the Host-Negotiation Protocol (HNP).
As far as implementing this. There is no brief way to explain it. Every controller is different and you would have to read the controller databook and programming model to implement all these procedures. As well as having a good understanding of the USB and OTG specs themselves.
A good place to start is http://usb.org where you can find all the specs.
In SoC I'm working on there is USB EHCI Compatible Controller.
Does all EHCI Controllers can work as Host or Device ?
Does EHCI Linux driver cover device/gadget mode for such controller ?
EHCI is a Host controller only, there is no specified way for one to function as a device, and it does not support USB OTG. Your SoC's controller most likely provides an EHCI compatible interface for the Host controller, using a different interface for the Device controller.