USB hotplug_callback to fast - usb

when I attach a usb memory stick to my system, I observe the creation of sd under /dev
where is related to USB port (a,b or c) and is related to USB partition.
After that I can mount, via shell, the device via mountpoint.
Now I would outomatizated this process :
I use libusb functions
use libusb_handle_events for waiting the event of USB attach\dettach
before to call libusb_handle_events I've registered the callback
when I insert the USB, the right callback is called but the mount procedure fails because /dev/sd ,checked with
access(file_path, F_OK) .
is not created and I need to wait 3 seconds more or less
My question are :
How speed up the process?
How, with libusb, detect if the device has been created under /dev?
Thanks for any suggestion.

Related

How to request only one pipe per frame on USB Custom HID?

In pipe and out pipe occur continuously within one frame when sending out pipe in Custom HID USB.
In pipe is requested periodically by the host pc every 1ms.
How can I modify the descriptor or FW that host pc don't ask for the in pipe within same frame when transfering out pipe?
Please let me know.
USB Communication Capture Image
It is not possible to modify the firmware or USB device descriptors to get that effect. That is not a standard feature of USB. You might try modifying the firmware of the device so that it can handle this situation (in fact I'm not sure why it would ever be a problem in the first place). You could also maybe modify the drivers/software you are using to communicate with the device.

How to get device path and mount path using usbdi callbacks?

I am in the progress of implementing a service which will detect usb plugin/removal using usbdi callback functions. Callback function has a parameter "usbd_device_instance_t * usbInstance" from which i can get device vendor id,product id and the device class information. But how do i get a mount point in case of a mass storage device and a device path in case of a HID device?
In QNX 6.6 and 7.0, usblauncher writes a map of detected devices, launched drivers, and their arguments such as mount point to the PPS tree. The USB Launcher Service reference manual has complete documentation on the location and formatting of these entries. You could scan them to find out what high level details you need.
That said, the usblauncher script engine also provides a place where you could add custom on-connect commands directly; that might be easier than writing a new service.

Issues communicating with devices over usb hub

I'm facing issues when communicating with devices over USB hub. When enumerating devices directly to host port, it does work, some devices over usb hub have issues.
Setup: STM32F103C8 - MAX3421E - LUFA (usb stack) (ported to MAX3421E (host) and STM32F103C8T6 (device)) - USB Full-Speed setup
Scenario:
When I attach device directly to host, I don't experience any issues enumerating almost all (some devices seems to be faulty and have weird/nonstandard behavior) devices. But when I try to enumerate over usb hub, devices starts to behave very strangely. I'm receiving much more NAK's from devices than when connected directly to host. Some devices are able to return Device Descriptor, but retrieving Configuration Descriptor fail. Some devices return Toggle Error after several NAK's, this could be remedied so far by delaying retry IN token. Also there is different behavior of devices when connected over different hubs. I.e. one device has no problems when connected to HUB1, but have issues when connected to HUB2. Then I have HUB3 (7 port) which internally acts as HUB in HUB. On this HUB3 device working fine on port behind secondary internal hub, but not on primary ports exposed over "root" hub.
I'm in suspicion that hub's TT could be somehow interfering with usb communication, but according to information I have found, TT should not be enabled under Full-Speed setup.
I have checked (many times) that I'm setting correct device address assigned during SetAddress phase (which is proved by returning Device Descriptor). When I step debug it seems that I can get Configuration Descriptor also, but while in normal system run, it isn't retrieved, but only over hub.
Does anyone has any ideas, what to look after? I've run out of ideas here after week of trying to find a root cause.
Thanks
so...
- as usual after searching for root cause, solution after days of trying comes naturally after asking on somewhere (this is hapenning to me always, but I do try prior asking always)
- when using hubs, make sure you don't suspend SOF generation during control transfers. LUFA just resume bus inside control transfer routines, so make sure you don"t stops and reenable SOF within (my fault as I'm using ported version to MAX)
- if you have tight main loop make sure you don"t reinitialize usb transfer without completion of previous try, but if you do so, check you don't owerwrite data which haven"t been processed yet fully (especially when using interrupt-driven transfer complete processing) [things seems to work when you have quite some debug output, as it delay that time critical transfers]
Enumeration over hub isuues are now second to none. Small glitches are subject for tweaking.
Unfortunately as I was in question for electrical issues, I had to unsolder usb host shield and soldered another one, which in light of new information seems unneeded. Nevermind, I have trained my soldering skills.

External USB device interface with Xilinx Atlys board

I'm trying to interface the Mindwave (http://store.neurosky.com/products/mindwave-1) with my Altys board, through the USB UART port. The dongle I'm trying to connect is basically a wireless reciever that outputs serial data stream on the USB connection. I'm trying to read in this serial stream on the FPGA.
The problem I'm seeing is that when I try to Chipscope the UartRx pin (A16), I see no activity on it even though the dongle is supposed to send 0xAA in standby mode.
Since the FPGA does not power the dongle, I have it connected to an external power USB hub and then connect the hub to the FPGA. However I don't see any activity.
Do I need to convert the signals to another level, or invert them? I thought the EXAR chip takes care of it.
Did you try swapping RX and TX?
Did you have acces to a scope? To check you can repeatly send 'U's (0x55) and look with a scope to see which line is RX and which is TX. You can also check the speed of the interface with this method.

USB HID device detection

I am trying to access an USB HID device under Ubuntu(kernel-3.0). I want to write a program which could notify me whenever an USB device is attached to the bus i.e is there any event generated whenever an USB device is plugged in which I can monitor. I have looked into DBus and HAL without any success. But I don't want linux to load its current modules(USBHID and HID) when the device is plugged in. I also want to ask if the mentioned modules are also the device drivers used for HID devices.
My sole purpose is to run a script whenever an USB device is plugged into the bus which will indirectly call the above mentioned modules.
I am writing my code in C. I am quite new to linux. So it would be of great help if anyone could point me in the right direction.
Thanks..
The UDisks deamon will send the D-Bus signal "DeviceAdded" when a USB drive is inserted, and probably another "DeviceAdded" for each partition on the drive. If you have automount you would also get a "DeviceChanged" signal when the partition(s) are mounted. You can then query the UDisks interface, as well as individual devices about their properties, for example. You can find more info on the UDisks interface here: http://hal.freedesktop.org/docs/udisks/UDisks.html
One way to get more familiar with what goes on with block devices (or whatever) on D-Bus, is to install and use D-Feet to inspect the bus. UDisks appear on the System bus. You can see what is there and inspect the properties for individual devices as well as the UDisks interface itself.
Another way, which would also allow you to see what signals are transmitted on the bus, is to run dbus-monitor from the command line.