I have some starter kit board based on Atmel ARM926 400MH. Powered by linux.
And I need to control power of USB, i.e. switch it off and switch it off.
I try to research for use sysfs, but there is no information about switching on/off.
You either can’t control USB power, or the OS will control it for you. As noted in this comment, “... users shouldn't be conscious of this layer.”
Port power might be hardwired to be always present, but more often hardware allows control by the driver. One example I’ve seen, host port through a 3320 USB PHY should have port power automatically enabled by CPEN output.
This area was enhanced with runtime power management framework introduced in 2.6.32 kernel. Details can depend on SoC and specific board support. New features can allow user space control to prevent auto suspend and resulting powerdown; otherwise, by default, USB should power down in suspend modes.
Lots more info in Regupathy.
Related
The STM32 has a read-out protection level 2 feature adjusted from ST-LINK Utility App (Options Bytes) so code cannot be read out via the debug interface (SWD) or any other way.
There was an explanation,ST Electronics website. I tried the proposed app named as Device Firmware Update (DFU). However, it did not work.
This is the MCU I work on.
In read out protection, Level 2 is selected and applied. After that, MCU cannot be seen or communicated.
RDP Level 2 can't be disabled.
It is in a permanent state, debug interfaces are disabled, the factory bootloader is disabled.
In RDP L2 only a custom bootloader (ie code running from the chip FLASH memory) can modify the FLASH, But it cant disable the protection.\
You need to physically replace the microcontroller. At the moment your board is bricked and there is no way of unbricking it
I want to know who fills the configuration space of a particular device of PCI
at the first place when a new device is connected to the PCI bus. I know both bios and operating system can configure the PCI space but who gives the information of the device to both of them.
The read-only fields of the PCI configuration space, identifying the device and its capabilities, are built-in to the device, not filled in by software.
Some fields, such as the BARs, are configured by the BIOS, as part of its responsibility to set up the address map of the system. The rest of the fields are programmed by the OS or the device driver. (The BIOS may also have a driver for the device, if the device may be used to boot the system.)
Decisions of these three software components (BIOS, OS, and driver) are based on rules and policies built into the software by its designers and/or configured by the system installer or user. For example, BIOS setup menus often have settings to control where the BAR regions may be placed. In Windows, information used to configure devices may come from the registry.
I have a USB audio device (Scarlett Focusrite 18i6) which does not require a driver, so I assume it uses the USB HID Audio Class standard.
It works on everything from Windows and Mac to Linux and iOS.
But on Mac and Windows, it has a control application which can for instance enable and disable direct monitoring.
How would I go about reverse-engineering how this is done, so that I can reproduce it on platforms where the control application does not exist?
I'm thinking of booting up Windows in a VMWare session and then logging the USB communication (somehow?) while using the control application, but it does sound tedious considering the amount of data and my very limited understanding of USB.
Any other suggestions?
You could try running the control application using Wine instead of reverse engineering it. However, if it's accessing USB devices then there is a good chance it might be using an API not supported by Wine.
To reverse engineer it, you should find a way to look at the USB traffic between the computer and the device. Total Phase has some hardware USB protocol analyzers, but you might be able to find a good software solution for free.
I am designing a USB keyboard with special capabilities. What information can such a HID device receive from the host?
Can I via USB:
Read data from a form on the screen?
Find out what OS the user is on?
Find out if there's been an error message?
Even 'know' what's going on visually on the screen, i.e. what program is selected or whether the program is windowed or fullscreen?
Thank you!
The device can't get any of this information from a standard driver that the operating system supplies because that would be a security issue. It can receive any information that your own driver or application sends it. There are many ways to communicate with it - your device could present multiple interfaces (which will appear as separate devices), multiple endpoints, or use the control channel. You will definitely need to study the spec, and I also found this tutorial helpful.
I have done something similar and used the control channel to exchange feature data with a Windows application (over the standard Windows driver). On Windows, the API calls are HidD_SetFeature() and HidD_GetFeature().
On the device side, my hardware ran embedded Linux and I used the GadgetFS library to create a user-mode driver - much easier to debug than a kernel driver.
As others have said, you'll run into issues if you try this with a normal HID. However, there is a project called the USB Rubber Ducky. From their description:
The USB Rubber Ducky isn't your ordinary HID (Human Interface Device).
Coupled with a powerful 60 MHz 32-bit processor and a simple scripting language
The USB Rubber Ducky looks like a usb-device and is recognized as a HID, but is programmable. You can make a small script that will be typed onto the screen which will allow you to performs the queries you seek.
With the USB Rubber Ducky you can:
Read data from a form on the screen? Yes
Find out what OS the user is on? Yes
Find out if there's been an error message? Yes
Even 'know' what's going on visually on the screen, i.e. what program is selected or whether the program is windowed or fullscreen? Yes
If you aren't hoping to buy this device, at least their firmware is on github so it can provide you a starting point
I have a USB to parallel port device that i want to interface with through c++ on a modern windows OS (xp and newer).
I've done a little research but the information is a bit patchy when it comes to programming to one of these USB to parallel port devices (most of the information is dated and assumes that you have a parallel port built right into the motherboard, something my brand new computer doesn't have). One reference even says that it is not possible to interface with a USB to parallel port from a C++ program without some sort of software changes.
All i want to do is to is be able to read or write 8 bits to the parallel port through a USB to parallel port device on a modern computer running a modern windows OS (with ports being dedicated to reading or writing only).
Is there any quick and easy way of doing this? Some sample code would be greatly appreciated.
Also, how many of these USB to parallel ports can I interface with my computer? Am i limited to 3 due to some sort of legacy addressing or can i have as many as my USB and CPU are able to support?
Working off VC++ 2008, running Windows 7 x64 with a Core i7 860.
Edit: a bit more information...
I've tried using inpout23 along with some prewritten test program. It compiled just fine and ran just fine claiming to have both read and written to a parallel port. I had my USB to parallel port connected to the computer and that port connected to a cable in which i had identified, stripped and soldered each of the 25 wires onto a sort of plug for quickly plugging into a breadboard for testing. None of the output pins had changed to what the program had said was written to them (instead they were all set to high and never changed).
I've done this in the past and I have good news and bad news.
The good news is that it always worked (sometimes with tweaking), which is a tribute to the electronic manufacturers of designing extremely robust protocols. Apparently the USB to parallel converters all provided the hardware port emulation.
The bad news is that performance was awful on the 'bitbanging' interface models. If you do not mind slow updates this is not an issue at all. I used it for programming uControllers and soon the price of serial or USB programmers was overcome by my impatience.
Just use the windows API to read/write the LPT or COM ports and it works (slowly).
I've worked with a USB-to-serial port adapter before and I guess USB-to-parallel should be the same. You should have got a driver along with the adapter - this does most of the work for you, hiding the USB interface and presenting it to the OS as a traditional parallel port. For example, when I plug my adapter into the USB port, it just shows up as COM4 in Device Manager. I'm guessing yours will show up as LPT1 or something. From there on, it's a matter of using the standard Windows API to access these ports. (see Communications Resources on MSDN)
Misteriously I succeed with the USB to LPT-DB25 Wire bought in ebay.com.
We should connect a LED between the /LF Line Feed and GND pins.
After discard the USB registers in order to find that one associated to the USB Cable, we should build an API (Application Programming Interface) to interact with the outputs/Registers.
I'm going to try to attach a picture to have a look how I managed it: