I want to communicate to halios system(hardware) through usb port. I have a code which shows that the device is attached. I used USBTrace which shows that how many bytes are going in and out from the device to the host. But I do not know how to implement this is vc++2008 and by using windows xp.
If this is an evaluation board for an Elmos optical sensor IC I would guess that a USB to serial converter is involved. You could confirm this by watching Windows Device Manager for a new COM port appearing when you attach the device.
If that's the case you can use Basic example of serial communication with Windows XP/win32 but you may need to contact Elmos for the command protocol.
Related
I am working on a project that involve accessing USB port using browser.I have seen WebUSB API and WebSerial API. Though I can't seem to get what is the difference between them? Can someone highlight the difference?
The difference between the two APIs is how they interface with the operating system to communicate with the device. WebUSB uses the platform-specific USB API while Web Serial uses the platform-specific serial API. This matters because USB is lower level than serial and because not every serial device is a USB device. With WebUSB you will be able to communicate with many different classes of USB device, including serial devices, but it requires the operating system allow the browser to "claim" the USB interface, which means there can't already be a USB device driver present. With Web Serial you will be able to communicate with USB serial devices, but also other types of serial devices such as Bluetooth as well as built-in RS-232 ports and other UARTs. The tradeoff you make with using Web Serial to connect to a USB device is that the operating system needs to have the correct USB serial driver installed so that the device is available through the platform-specific serial API used by the browser to implement Web Serial.
WebUSB API is for providing access to USB (Universal Serial Bus) devices from web, But WebSerial API is for providing access to serial ports complying with RS232 standards from web, like old printers port or old mouse port. RS232 is used on many devices like medical devices.
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.
I am currently developing an application that connects to a device via USB but due to project modifications I have to move it to a target device whose only serial communication is via RS-232 DE-9 port.
To communicate with the device I use a proprietary API. Using strace I know that it scans all devices in /dev/bus/usb and after finding the right one the API connects to it.
I wanted to know if I could some how emulate my device in /dev/ttyS0 to an unused usb device in /dev/bus/usb/ to connect to it
I'm working on a Communications Device Class (CDC) driver for an embedded device, a Full Speed implementation of USB 2.0. The COM port settings are 115200, 8-bit, no parity, 1 stop bit, no flow control. Our PC application (32-bit, Windows 7, .NET 2.0) communicates with the target device through a virtual COM port, which on the target device can connect to either a FTDI (USB-to-SCI bridge) chip or the integrated USB peripheral in the microcontroller, depending on which port is selected by the application.
Both virtual COM ports work without any problems using Realterm. However, while our desktop application works using the virtual COM port connected via the FTDI chip, it hangs when attempting to use the virtual COM connected via the microcontroller's integrated USB peripheral.
When connected via the virtual COM port using the integrated USB, the application consistently hangs on the second call to SerialPort.Write(...). Using Serial Monitor from HHD Software I can see that the data is transmitted on the first call to SerialPort.Write(...). However, that data is never received by the target device.
It's odd because the only time I have seen similar problems on previous projects was when the flow control settings on each side of the bus were mismatched.
Additional info...
Here is the data captured from various port monitoring tools while running our PC application connected to the target device via its integrated USB peripheral. Any insight would be appreciated.
Sysinternals Portmon
Advanced USB Port Monitor
Device Monitoring Studio - Request View
Device Monitoring Studio - Packet View
For those that are interested, I am using CodeWarrior 10.2 with the MCF51JM128 from Freescale.
Any ideas or suggestions would be appreciated. Thanks.
It is clear from the logs that you are making the classic mistake of not taking care of the hardware handshaking signals. That only ever works by accident, a terminal emulator like Realterm will never make that mistake.
You must set the DtrEnable property to true. That turns on the Data Terminal Ready signal. It is important because RS-232 is an unterminated bus so is subject to electrical noise when the cable is disconnected or the power turned off. DTR convinces the device that it is in fact connected to a powered device. This is emulated of course in your case but the driver or firmware will still typically implement the RS-232 behavior.
And the RtsEnable property is important, used to handshake with the device and prevent the receive buffer from overflowing when the app isn't emptying the buffer in a timely matter. You really should set the Handshake property to Handshake.RequestToSend, the most common way a device implements it. Which then also takes care of turning RTS on. If you have to use Handshake.None for some reason then you have to turn it on yourself by setting RtsEnable to true.
This ought to take of the problem. If you still have trouble then use PortMon to spy on the way Realterm initializes the driver. Compare the commands you see against the commands that the SerialPort class sends. Make sure they are the same. In value, not in sequence.