2 ms·
I'm not an expert on USB protocol, so I'm not sure how your suggestion would work. The driver bricks it in the sense that the Product ID of the device is wiped
by HCIdivision17 12y ago
I'm not an expert on USB protocol, so I'm not sure how your suggestion would work. The driver bricks it in the sense that the Product ID of the device is wiped (zero'd). As a result, the OS doesn't know what to do with it or what drivers to connect it with.
Is there some signature to the USB device that would allow the OS to know what to do with the affected gizmos? Or do you have to explicitly tell the system "no, really, the device on this USB port is specifically this"? If it's not automatically deployed like the initial driver but rather actually requires the user to screw with firmware-style updates, then it's effectively ruined for many beginners with these chips. (Thankfully, there's been a lot of fuss over this, so newbies will likely be able to troubleshoot this problem after a few hours of groping in the dark for why their device has gone silent.)
- serf 12y agoIt's an eight step process. http://www.reddit.com/r/arduino/comments/2k0i7x/watch_that_windows_update_ftdi_drivers_are/clgviyl http://www.reddit.com/r/arduino/comments/2k0i7x/watch_that_w...
- HCIdivision17 12y agoDang. If a person's not familiar with the ins and outs of USB protocol, I'm going to bet they're not going to be able to think up or through that procedure. At best it'd just be some incantation to recite in the hopes the gizmo comes back to life. And if you're using the FTDI chip specifically because it abstracts away serial to USB communication stuff, well, hopefully the device is cheap enough to just replace. Still, perhaps it could be automated somehow via a responding Windows Update? That's the thing that gets me - it was autmatically propagated, it oughtta be automatically fixed. Nice find though.