> From: "Greg KH" <g...@kroah.com> > To: "John Skelton" <js...@gmx.com> [snip] > > > > It is code which is derived from V-USB > > > > https://www.obdev.at/products/vusb/index.html > > > > and is described at > > > > http://www.recursion.jp/prose/avrcdc/cdc-232.html > > > > > > > > If it worked with Linux it would be a handy way to provide output (such > > > > as > > > > debug data) from low-cost Arduinos and such like via USB. > > > > > > > > To be clear: I am not saying the Linux USB code is wrong. But it would > > > > be good to have a way to have the above kind of code work, such that > > > > screen / minicom etc can be used with it. > > > > > > > > > > That page says that any kernel newer than 2.6.31 should work just fine, > > > have you tried this out and had it fail? > > > > It does say that but it does not work. I get the dev_warn message that it > > has changed the Bulk endpoint to Interrupt but that's it. > > What happens after that? Does the cdc-acm driver refuse to bind? Any > other types of error/warning messages?
Along the lines of: usb 2-1.2: >new low-speed USB device number 95 using ehci_hcd usb 2-1.2: >device descriptor read/64, error -32 usb 2-1.2: >config 1 interface 1 altsetting 0 endpoint 0x1 is Bulk; changing to Interrupt usb 2-1.2: >config 1 interface 1 altsetting 0 endpoint 0x81 is Bulk; changing to Interrupt usb 2-1.2: >New USB device found, idVendor=16d0, idProduct=087e usb 2-1.2: >New USB device strings: Mfr=1, Product=2, SerialNumber=0 usb 2-1.2: >Product: Digispark Serial usb 2-1.2: >Manufacturer: digistump.com cdc_acm 2-1.2:1.0: >ttyACM0: USB ACM device But screen /dev/ttyACM0 (with or without a "baud" rate) just hangs. > Doing this type of thing really isn't a good idea for the obvious reason > that hubs might just die a horrible death. Who knows what a USB 3 > controller would do with a low speed device like this as well (hubs are > crazy complex, and low speed makes them really sad.) Ah. Maybe it's my laptop's internal hub that hangs. Though the other USB ports carry on working. > You would be better off spending a few cents and getting a better USB > device controller. It will save everyone here, and yourself, a lot of > time and money... True :( Consider it closed if you'd rather. I'd rather not take up the ML's useful time if there's no reasonable workaround. People can debug via flashing LEDs etc... John -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
