On reading many websites, I got confused.
Is the USB driver essential for making the device work? Or is it essential for making it communicate with the OS to do functions such as printing and doing other OS stuff?
To explain my question more clearly -
I am working on developing a USB device, that will communicate with the software i will write.
Do I need to develop a driver for such a system?
or
Do I just need the software program to send the proper messages to the device?
I am assuming your micro controller will be a USB device and your PC will be USB host.
The below diagram is the SW architecture for USB host. Now since your host is a PC, you do not need to worry about any part except the application at the top.
So lets talk about the device. What you need is a device stack which resembles with the host stack below. You can get the device stack easily and port it in your micro controller. But I suppose you need an application in your device too same as the top box of the below diagram which will understand the requests from the host and service the request.
So basically what I am saying that you need two applications and the rest of the components you can get it with some effort.
Regards.
Related
For testing purposes I need to power off a USB device from my computer programmatically. The microprocessor in the USB device is ARM Cortex M4.
I have tried using Devcon, although the device was disabled, power was still provided to the device.
I have also tried to disable the USB root hubs ,that also didn't work.
I have read some other posts indicating that a SSR could be used, this option is not desired. I would rather choose the software solution(if there is one of course).
Some other answers have indicated that this is an OS issue, and some others a chip-set architecture issue.
So my question is what options are there available. And also is this purely something dependent on the computer side or do we need to implement something on the USB device side as well.
Thank you in advance.
I've been asked to work on a project for Windows 8 where I have to detect:
Type of device inserted to USB port (mass storage drive or android phone or windows phone etc.)
Port in which device was inserted. (if I have 4 USB ports in PC then identify which port received new device)
Detect when the device was ejected from the PC
Are there some managed C# API's that can be used to query or if there are some callbacks that can be subscribes to.
Any help or direction will be very useful.
Thanks
You don't specify whether you are writing a desktop app, or a Modern UI app. If it is the latter, I'm afraid you are going to be out of luck as this level of information is simply not passed down to the app's sandbox.
You may have better luck with a desktop app. I don't have any direct experience of doing what you ask for, but I do remember having read that it may be possible through .NET.
Just as the question states, the goal is to reverse engineer the protocol used by a device.
Let's say you have a webcam, an Arduino and an Arduino USB Host shield. You want to talk to that webcam, from which you don't know the protocol. Can it be done by monitoring USB data packets and by analyzing the driver installed for that device?
It would be a really interesting project.
Thanks in advance.
I often use a serial spy program to look at the conversation between two devices. In windows you can pay for it...
http://www.sinnovations.com/htdocs/serial-port-monitor.htm
In Linux it's free...
http://www.cyberciti.biz/faq/howto-monitor-data-on-a-serial-port-in-linux/
I have been tasked with writing a USB driver for our embedded software to send raw data to Host. This will be used to send some logging data to host. We are using iMX31 litekit for development.
From the documents that I have read on USB, my understanding is that the embedded device will be in device mode only. Also it will only be communicating with host machine.
So can any one guide me here? Any article, reference or code is welcome.
Some things to consider:
Is this a high bandwidth device like a camera or data recorder, or a low bandwidth device?
For low bandwidth, I would strongly consider making your device act as a USB HID class. This is the device class that supports keyboards, mice, joysticks, gamepads, and the like. It is relatively easy to send data to nearly any application, and it generally doesn't require that you write a custom device driver on the host side. That latter feature alone is often worth the cost of lightly contorting your data into the shape assumed by the HID class. All the desktop operating systems that do USB can use HID devices, so you get broad compatibility fairly easily.
For high bandwidth, you would still be better served if your device fits one of the well established device classes, where a stock device driver on the host end of the wire can be used. One approach that often works is to use the Mass Storage class, and emulate a disk drive containing one file. Then, your device simply mounts on the host as if it were a disk, and you communicate by reading and writing to one (or a few) file.
I would expect there to be a fair amount of sample code out there for any serious USB device chipset that implements either or both of HID and Mass Storage.
If you really must wander into fully custom device territory, then you will need to be building device drivers for each host platform. The open source libusb library can be of some help, if its license is compatible with your project. There are also ways in newer versions of Windows to develop USB drivers that run in user mode using the User Mode Driver Framework that have many of the same advantages of libusb, but are not portable off the Windows platform.
The last custom device I worked on was based on a Cypress device, and we were able to ship their driver and an associated DLL to make our application code easier to build. I don't know off the cuff if there is any equivalent available for your device.
For a really good overview, I recommend the USB FAQ, and the latest edition of Jan's book, USB Complete.
The rest of my team will make for my application a simple non-standard USB microphone, but until they finish it I will have to emulate it, for integration testing purposes.
Is there any risk in a physical loopback? Yes there is
Will a physical loopback work? Only with a USB bridge
There is any way to create a logical loopback? (MSDN has something about this)
There is any general purpose USB emulator software?
In case there is many options available I'd rather work it .NET/Matlab/Python solutions.
Edit: Proof of concept here
I strongly recommend this project, USB IP. It is a way of connecting USB devices over the network. There is a Windows client.
What this means is, you install the client on your Windows computer.
This device then expects to talk to a USB device connected to a Linux computer, the server:
What you now do, is either create a fake device driver for Linux, that looks like is connected to a physical USB device, but in reality is just logic pretending to be your USB device. There are tutorials for writing USB drivers for Linux. Or you create your own stub driver for the Device Control Manager (see picture above). This stub driver could run on Windows or Linux, it wouldn't matter. It could even run on the same Windows machine which is the USB client.
The DSF USB Loopback Device mentioned in the question itself, would be the same kind of solution as a stub driver for the Device Control Manager, but taking Linux out of the picture altogether.
You can write virtual USB device using QEMU.
You can duplicate already existing device, like the dev-serial.c found in this QEMU repository and change it for your needs.
After you write and compile your USB device you can simply attach it to your VM using the QEMU command line interface.