I have a system consisting of a computer and various sensors. The sensors have a USB communication interface. I want to design GPIO and communication card between computer and sensors. I want to read the data from the sensor (Usb interface) with a microprocessor (ESP32-S3), pass it through various processes and send it to the computer (Usb interface). I have tried usb CDC ACM and HID sample codes but failed. Can I use ESP32-S3 as USB HUB or USB HOST for USB data communication? If possible, where could I be making a mistake?
I programmed an Esp32-S3 as if it were a sensor. With another Esp32-S3, I was able to send the data I received with the USb protocol to the computer. But I was not successful with other sensors.
Related
I'm working on a USB MIDI device that will function as the receiver for a wireless system. This device will communicate bi-directionally though a radio module with the transmitter, a separate piece of hardware that runs in USB host mode.
The receiver will be plugged into a PC. MIDI devices plugged into the transmitter need to show up on the PC as MIDI ports. Since the transmitter supports a USB hub, there can be multiple devices plugged in.
There are two requirements that I'm not 100% how to meet:
1.) The MIDI port names on the PC end need to reflect the name supplied by the USB device plugged into the transmitter so that it's clear which device the port is for.
2.) The set of MIDI ports on the PC needs to update when devices are plugged/unplugged from the transmitter. This is the crux of the question: is there a way to update the available USB interfaces/MIDI jacks initiated by the device?
The brute force way of doing this would be to completely reset the receiver any time it receives a message from the transmitter that there's been a change (on reset,the receiver would then poll the transmitter for current devices and supply the updated info when the host PC re-enumerates).
The transmitter/receiver hardware are both based on PIC32MZ MCUs (no RTOS). I'm good with writing the USB code to get the host/receiver end to do whatever. The question is about how, at the level of the USB protocol, to do this.
Also, just to be clear: The transmitter/receiver communication will be an ad-hoc protocol and the receiver will set up all its USB configuration data itself; the idea isn't to attempt to seamlessly enumerate devices over the wireless link.
To show the port names on the PC, just copy the USB descriptor strings over to the transmitter.
The only way for a USB device to change its configuration is to reset itself, as if it had been unplugged, and to let the host re-enumerate it. So the only way to prevent multiple devices from interfering with each other is to have multiple (virtual) USB devices on the receiver. If your hardware does not support this, then you cannot avoid the reset.
Wondering how can the PC distinguish among multiple USBs. For example, when i plug my flash drive USB into my computer how can it know that it is a flash drive USB not a keyboard USB ?
Thanks in advance.
in the USB standard there are USB classes a memory stick is USB mass storage class, keyboard, mouse, joystick are USB HID class (Human Interface Device), cameras implement USB PTP (picture transfer protocol), USB-to-serial (virtual COM ports,...) is USB CDC ACM class ,...
the following link lists all USB classes for that windows has drivers https://msdn.microsoft.com/en-us/library/windows/hardware/ff538820%28v=vs.85%29.aspx
when the USB device is plugged in there is a communication between the MCU on the USB device (firmware) and the PC (USB host) . in this communication the device says which USB class it it and the host loads the fitting driver
you can sniff this communication using wireshark or see dmesg (on linux)
this communication is very low-level and not easily human-readable. there are tools like wireshark or lsusb -v for this
a USB device has to implement a special hierarchy of descriptors in which information of the internal structure of the USB device is contained. the hierachy is:
device descriptor -> configuration descriptor -> interface descriptor -> endpoint descriptor
EP0 is reserved for control transfers, else any transfer has to go to or come from an endpoint (OUT endpoint / IN endpoint)
see http://www.beyondlogic.org/usbnutshell/usb1.shtml
USB is a higly complex standard because it implements a wide functionality for a large number of different devices in one physical interface. i think the most complicated USB class standard is USB audio...
I'm working on the project in which I should transfer data from a microcontroller to a PC with the USB protocol. I am working with the STM32F407 microcontroller for transferring data to a PC with the USB Protocol.
I am using libsub for transferring data in Windows 7.
I have written a program with STM32cubeMX and configured the USB device class library. I can transfer data with the CDC virtual COM port, but I want to transfer data with libusb. I install the libusb driver for my device, but when I send data from the microcontroller to PC nothing is send!!!!
What is my problem? How can I send data from a USB device to a PC with USB and high speed?
Enter image description here
In USB protocol the host device initiates any transfer, for example a bulk transfer. i assume that the ST32f407 is the device and the pc ist the host so the ST32 can not initiate any USB transfer. The communication over virtual COM works because it the virtual COM is like a tunnel, but this tunnel was also initated and is (logically) kept alive by the host (pc)
Bulk transactions
Like all other USB transfers, the host always initiates a bulk
transfer. The communication takes place between the host and the
target endpoint. The USB protocol does not enforce any format on the
data sent in a bulk transaction.
source: https://msdn.microsoft.com/de-de/library/windows/hardware/ff539199%28v=vs.85%29.aspx
All data transfers are initiated and controlled by the host and USB
peripherals are slaves responding to host commands
source: https://www.midi.org/articles/basic-of-usb
in usb even interrupts have to wait until the host polls:
Any one who has had experience of interrupt requests on
microcontrollers will know that interrupts are device generated.
However under USB if a device requires the attention of the host, it must wait until the host polls it before it can report that it needs
urgent attention!
source: http://www.beyondlogic.org/usbnutshell/usb4.shtml#Interrupt
See http://www.beyondlogic.org/usbnutshell/usb4.shtml#Bulk for bulk transfers
So you can send data from the device to the host but the host has to establish the communication meaning has 'ask' for the data. This is done via the bulk IN endpoint that is used to read data from the device to the host
Hopefully I will have more luck today. I have no prior USB integration and about 8 months of learning embedded systems on Atmel devices. I am trying to use an Atmel SAM L series to connect over USB to a computer. The use case is for data transfer. Specifically, the MCU will be gathering data from it's sensors and packaging it for USB transfer.
I have searched through and read up on all of Atmel's included USB examples. I have also started reading through usb.org's class specifications for CDC.
I have running now something that lets me send data along one com port, into the target usb and then out the debugger usb to another com port. However, I don't think this is real USB.
My problem is two fold.
1.) I do not fully understand what differentiates USB from serial communication on a com port.
2.) Even if I were doing it correctly, I'm not sure how to test and verify that I have indeed created a legitimate USB device that can be accepted by a host computer.
Links to documentation(Atmel or generic) or example code would be appreciated.
1) USB is defined in the USB specifications from http://www.usb.org. Serial ports were an older and simpler interface that involved sending data back and forth asynchonously on pins with names like TX and RX. The USB CDC class and its ACM subclass allow you to make a USB device that emulates a serial port. If you make your device be a USB CDC ACM device, then you don't need to supply any drivers for Windows 10, Linux, or Mac OS X.
2) You can read the USB specification and the CDC ACM specification. You can run the USB command verifier. You can test your device with a variety of different USB hosts to make sure it works.
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.