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.
Related
I would like to use a windows machine as a USB488/USBTMC device. USB488/USBTMC is a reimplementation of the good old GPIB/IEEE-488 on USB rails. But most articles on the topic refer to a Windows machine as a host/controller. The Windows USB stack is not well suited for USB device/USB OTG modes. However, if you look at some of the high-end gear like oscilloscopes and spectrum/network analyzers, it is well known that they are often Windows machines inside with some additional hardware. So, how it is done?
To some background: it is a project to retrofit a very old SEM microscope with new hardware. The current one is a 68k custom system with a CRT that uses a GPIB interface for comm with a PC. Things like sample spectroscopy are done as a BASIC program running on a pc and communicating through that gpib port. The plan is to replace that 68k junk with a modern day windows pc with an FPGA on a PCIe bus. For compatibility reasons, it would be nice to have a usb488 port in the new PC. Though I have no idea of how to do it properly. The only solution I have so far is to have some cheap USB-capable micro hanging on the SPI bus on the FPGA facing side and a USBTDM class on the USB side. But maybe Im missing something and there is a specific thing or chip that exists that can do it that Im not aware of.
I can only speculate how high-end oscilloscopes achieve it. The most likely option is that they use a dedicated chip like a MAX3420E. It is connected via SPI. Part of the USB protocol is implemented by the chip, part of it will be implemented by the oscilloscope software.
Most USB controllers chips found in PCs can operate as the host only. And even if they could do a role swap, Windows (for Desktop) has not supported device/peripheral mode until recently. It now does. See USB Dual Role Driver Stack Architecture. But I don't fully understand it to tell you what hardware you would need to purchase where this feature is enabled.
Role swapping is very common on smartphones. It is also implemented in Linux (search for "Linux USB gadget"). Many Apple Macs can run in Target Disk Mode, which is a USB device/peripheral mode as well.
I have a project based on a Nucleo H743ZI2 board that communicates with a PC through the USB OTG port on the Nucleo.
Everything is working fine as long as, weirdly enough, I have the STlink USB cabled plugged in (which I have been using to work on the firmware, flash, debug, etc).
However, today I was getting ready to do actual tests with this project and used an external power source to power the H7. I initially tried a 3.3V external source which is available from one of the shields, and then tested a lab PSU at both 3.3V. Thinking it could be PSU related I also tried external 5V with the same results.
Basically, the device is not recognized by the computer operating system, unless the STlink USB is plugged in.
I can't really put my finger on this one; I initially thought it was a PSU related issue (that nucleo board has some restrictions when it comes to using external power sources) but at this point I am fairly confident I am failing to initialize something in my code. Not sure what though.
I'd be happy to share with my code, but wouldn't know where the start. I haven't done much as far as the USB OTG is concerned other than modifying the receive callback to process the data.
Any idea what I might be missing here?
Cheers
Is there a place where I can find documentation or an SDK about the Logitech Unifying Receiver?
I recently obtained a wireless mouse, which came with a Logitech Unifying Receiver (a small USB dongle that plugs into the computer and communicates with the mouse/other compatible devices (such as keyboards)).
I wanted to try writing an app for my smartphone that pretends to be a mouse and sends data to the receiver.
I was able to monitor the data from the USB bus by using usbmon, and could probably use that to hack something out, but wanted to know if I could find the info I need somewhere on the internet without having to derive it on my own.
I'm going to try using SL4A on Android, if that helps any.
I have discovered some Logitech documents on a shared folder in Google Docs via this Chromium bug report. For convenience, I converted all doc(x) files to PDFs and put those on https://lekensteyn.nl/files/logitech/.
You will find Logitech HID++ 1.0 Specification for Unifying Receivers (pdf) very interesting, it describes the USB traffic (instead of the 2.4GHz wireless traffic as noted by Avery). My article Logitech Unifying for Linux: Reverse Engineering and unpairing tool documents a way to capture the traffic with usbmon and QEMU. It also includes tools to make the usbmon output prettier to read (for this protocol).
This is Avery, aka Tequals0. The USB dongle is a USB HID mouse/keyboard device, so all that traffic that you are seeing is basically generic HID traffic- if you want to pair your phone to your dongle, you will have to emulate the wireless traffic, not the USB traffic-that is generated by the dongle.
There is some info at Tequals0 blog, and AveryLouie also got some python tool operating with unifying
I'm trying to connect a usb sensor (see Toradex) to an android phone (Desire Z) running android 4.0.3.
To test this, I wrote a small app to enumerate the attached device(s).
This supposed to have USB HOST mode implemented and to power the usb sensor (HID)... but it doesn't.
I got a USB OTG cable and now, when I attach the cable, a small icon appears in the status bar (car mode).
I'm disappointed since I waited for this feature for awhile now...
Any thoughts? I read almost everything out there related to this (Sven work and whatnot) but I might have missed something...
Thanks!
I have worked a lot in the past year and a half to build custom android platform. Some was under Froyo but mostly on Gingerbread. Most on the hardware I added was on either a UART or on USB, which is what you want to do. Unfortunately, it is not as easy to add a USB peripheral on an Android device than on a PC or a MAC. PCs and MACs have virtually unlimited memory space (hard drive). They can hold the drivers of a very large number of devices. That makes it possible to do auto-detection and automatic loading of drivers. On an Android device, it is a lot more lean therefor, just the required drivers are stored on the device. Every time I added a new device, I had to compile the driver for my platform and make some modification in my configuration. It is also possible to load the driver as a module instead of compiling it with the kernel (gives a file.ko output). Although, the driver must have been written accordingly. But, you will have to install it by modifying the "init.rc" which requires root privilege.
here is a few link of question/answer about about drivers in Android. That should give you a little bit more info:
USB touchscreen driver
Hope it helps but unfortunately, it is quiet a lot of work do do.
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.