Detecting modifier keys pressed on host computer from circuitpython - usb

I have a Raspberry Pi Pico running CircuitPython. Is it possible for the python code on this board to detect if a modifier key is pressed on the host computer's keyboard when the board is connected to the host over USB?
My knowledge of USB protocols is limited but it feels like the Pico would need to be listening to data explicitly sent over USB. I don't think that key presses would be sent that way.
I'd be happy to be proven wrong.

I don't think you can do this without installing something on the host computer side to detect when the Pico was connected, check what keys were pressed and communicate with the Pico accordingly.
If the host computer is Windows then a quick search finds this which uses Windows Management Instrumentation to run Python code when a USB device changes.
Alternatively, you could attach a hardware button to the Pico and check that button when the Pico detects that it has been connected to a USB host - you appear to have already figured this out.

Related

Detect USB connection on atmega168 v-usb

I'm using atmega168 with AVRUSB. (yeah, old version of V-USB. already integrated and seems to work otherwise, so no hurry to change)
My hardware can be powered by USB or via other source. How can I detect if the host is actually connected? It would be also nice to init USB whenever it's connected, but not necessary. Most important is that I need to skip the blocking USB polling if there's no host.
The hardware I'm using doesn't have USB VBUS connected to any GPIO, so a software-based method is required. Maybe I could add some timeout to the USB init routine or something similar?

Devcon Disable Port vs Digital Relay

I have a device connected to a USB and it periodically sends data to my PC. During the time it is not sending data, the USB cable needs to be removed, else, the device won't work (a fail-safe feature, if the USB cable is connected and attached to pc, the device is in communication mode, if the USB cable is disconnected from pc, it is in stand-alone operation mode).
I was thinking to use the Devcon so I font has to use another hardware, I'll just disable the USB port during an operation mode, then enable it during communication mode. However, the periodic transfer of data can be set to every 5,10,15,30 minutes depending on the settings.
My question is, will it be okay to disable/enable the USB port periodically? Say every 5 minutes? Won't it cause any problem in the long run? Or would it be more efficient for me to use external hardware, a switch to connect/disconnect the USB? Appreciate any advice or thoughts.
If devcon works for you, I don't see why it would cause any problems in the long run. There is no inherent reason why the hardware should get damaged when you run some commands in your software to disable a USB port.
Using external hardware to accomplish the same thing would not be more efficient because you'd have to pay for the hardware and maintain it.

STM32F04 in DFU mode recognized only when powered from battery (Win10)

I made a STM32F042k6, battery powered device, that I would to flash vi DFU protocol.
In order to do so I disconnect the battery, I pull BOOT0 to VCC, and then plug the device in USB3 port of PC (no USB2 available). The device is not recognized and showed
VID:0000 PID:0002 (case I)
However, when I first connect battery, and then connect the device to PC it is recognized without a fuss (case II).
The problem I face is that I would like to initiate jump to bootloader program by command in software - but then I reach exactly the same condition as in case I.
Could you help me to identify what conditions for proper boot I am violating?
EDIT:
The way I have discovered the problem was when I implemented software jump to bootloader. It seemed not to work at all (VCP device dissapeared, and erroreous <> device appeard in system PID:0002 VID:0000).
I wanted to enter bootloader by pulling up BOOT0 pin, but I could see that I sucseed only when battery-power cycled. USB power cyccle resulted in the same "failed descriptor" device.
I suspect that when powered on via USB, the booloader has som ecommunication problems and cannot establish proper PID and VID. When powered via battery - this problem is not existing.
Do you have a discovery board?
I read in the STM32F042x4/x6 Reference Manual (DocID025832 Rev 5):
The STM32F042x4/x6 embeds a full-speed USB device peripheral compliant
with the USB specification version 2.0.
(part 3.19, p.27).
In the AN2606 (Rev 33), a table shows the USB configuration which is used by the DFU Bottolader in USB FS (Full-speed):
I assume that the USB in the bootloader is the 2.0, but USB 3.0 must be USB 2.0 compliant. So it is possible to use an USB 3.0 port.
I suggest you use the DfUSe Demo from ST. Its interface consists of a tab where the DFU devices available are displayed when detected. I try it on another STM32x by following these steps:
Open DfuSe Demo software.
Plug BOOT0 to Vdd to put the micro on DFU mode.
Plug the USER USB to your computer port.
The name of your device should appear in “Available DFU Devices” field.
You could try to use directly PA11 and PA12 as well (according to Table 12) instead of the USB port of your board.
EDIT:
Another solution to upgrade your firmware without driving boot0 is to jump directly into the DFU bootloader of ST inside your firmware. Else you could design your own IAP bootloader (In-Application Programming).
I hope that helps.
I faced this same issue with the STM32 Mini F401 and dug into it for several days. Unlike the OP I was unable to find any electrical conditions which reliably got the bootloader to do the right thing. I was able to program my board maybe once every 20 tries, which was really slowing down my process.
In the end I discovered that I can go to the Windows device manager, show hidden devices, and there will be an entry in Universal Serial Bus Devices called STM32 BOOTLOADER. When the issue is happening the board is connected in dfu mode but that device is not marked active in the device manager.
To resolve the issue consistently, you can manually delete the hidden STM32 BOOTLOADER entry, uninstalling the device (no need to delete the driver, just uninstall the device). Then reboot your board in DFU mode and it should connect as expected every time. Unfortunately I need to do this process every time I want to program, but that's far better than the inconsistent/intermittent failures before.

VMware USB autoConnect blacklisting?

Is there a way to stop VMware (Workstation 12 Player) from automatically connecting a USB device?
When I wake up my Surface (Win 10 x64) it connects the Type Cover to the running Linux (Ubuntu 14.04.3, 4.3 kernel) guest, which doesn't seem to know how to handle it. I then have to use the touch screen to manually disconnect the device (= attach it to the Windows host) to be able to move my cursor or type again.
I'm sure there is an option to ignore a device in the .vmx config file...?
Edit: Note that I don't want to generally disable usb.autoConnect, because I need it for another device (an Arduino Micro that must be quickly reattached in bootloader mode...)
You can either stop Mware USB Arbitration Service
or
try to uncheck "Automatically connect new USB devices" in "VM Setting ->USB controller panel" and check "do not show this hint again".

communication to usb port by using vc++2008

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.