-----BEGIN PGP SIGNED MESSAGE----- Hash: RIPEMD160 On Thu, 19 Jan 2012 00:33:30 +0000 Oli Glaser wrote: > Completely customizable interface with docked windows and > user-defined screen sets. > Display all plugged USB devices in a hierarchical auto-refreshed > tree-view. View and explore the USB Devices and their components. > View detailed USB-related information about each USB device: Device=20 > Descriptor, Configuration, Interfaces, Endpoints, etc. > View detailed PnP-related information about each USB device: Hardware=20 > IDs, Instance ID, Software Key, PDO Name, etc. > Real-Time monitoring at any level in the USB driver stack from USB > Host Controller to target USB Device. > Display detailed information about IRP, IO_STACK_LOCATION and URB=20 > structures associated with each captured request. > Display the buffer contents, if any, associated with the request in > hex format. > Capture several USB devices simultaneously. > Separate log records for request issue and completion. > Capture almost all types of USB Request Block (URB). > Capture all USB-related kernel-mode device I/O control requests. > Capture all user-mode device I/O control requests to USB Host > Controller and USB Hub. > Capture state transition PnP IRPs. > Automatically capture hot plugged devices. Can be used to monitor > device enumeration process. > Saving captured data in binary file for later analysis. > Configurable filtering to exclude non-essential information from the > view. Search feature to search the capture file for the particular > request types. Export all captured data or any part of it to plain > text, CSV or HTML formats. A lot of this is the same kind of information you could get on a Linux system using lsusb in its most verbose mode and Wireshark/usbmon. The parts that are notably missing are things like data PIDs and handshake packets. Wireshark/usbmon, for instance, can't tell you if you got a data PID wrong because PID toggle is handled by the host controller hardware; the OS won't see the discarded packet at all, whereas a proper sniffer will show you the transaction and also which PID it used. Similarly a decent sniffer will show you what sequence of NAKs, no-handshakes, ACKs, or STALLs are flying around, whereas Wireshark will basically only tell you whether the transfer timed out (too many NAKs), failed with I/O error (which one assumes means too many no-handshakes, but you can't see the individual attempts), stalled (which typically would mean a single STALL handshake), or completed (which would mean an ACK, but with an unknown number of NAKs before it, plus maybe a few no-handshakes as well). And in my case these tended to be the issues that sucked up quite a bit of time before I bought the analyzer. A software sniffer is certainly MUCH better than nothing, and if you're working on a kernel driver it's probably very helpful as it can show you more details about how I/O requests travel through the kernel layers, but IMO the hardware sniffer has a lot of advantages when working in firmware. The Beagle USB12, by the way, can also capture from multiple devices simultaneously; you would just put a hub downstream of it with the devices plugged into the hub (the analyzer acts like a tapped transparent USB cable). Chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iEYEAREDAAYFAk8X0hoACgkQXUF6hOTGP7cSPgCgm8amATqIpceCXMH6LiHo/l16 3lcAoIF3i1b/9+b2HmAQB9ixy9oflVpm =3DY1Jl -----END PGP SIGNATURE----- --=20 http://www.piclist.com PIC/SX FAQ & list archive View/change your membership options at http://mailman.mit.edu/mailman/listinfo/piclist .