only to find all the windows problems were driver related - not my code.
I'm presuming that you had problems with the usbser.sys from Microsoft. Did you also had problems with the Prolific/FTDI drivers as well?
I think (though not 100% sure) the serial-USB device's existence is decided by the firmware so it can be fixed after the fact anyway?
On the LPC1343 like ModMiner yes. ngzhang used hard serial-USB chips (Prolific or FTDI) in his designs. Same with Enterpoint (FTDI).
I've only done the MMQ so far. Though the code is 'done' and in my git I haven't sent the pull to cgminer yet coz I've had to rebase it and there seems to be a bug in the ~2k lines of code I've changed that I still have to track down
Most likely I'll try Icarus/Prolific next and find more obstacles
(unless I get side tracked on something else ... an ASIC device shows up?
)
The Windows driver work around, in the MMQ case, was to use
http://sourceforge.net/projects/libwdi/files/zadig/ to force it to use WinUSB (on WinXP)
So it's not insurmountable - but best if not every windows end user has to do that.
I've bitched about Serial-USB for a long time but only recently got around to doing this USB direct implementation
Firstly, I've only been messing with USB for a few weeks, so if anything below is way off - let me know.
Guessing at the early figures and considering around 50GH/s from a single device using 1 diff shares, and that USB has a standard transaction time of 0.125ms for 480MB/s USB 2.0, there already isn't a lot of space (and txn time is higher for 12MB/s, 1ms)
50GH/s is 11.6x1diff shares a second on average so just dealing with 6 transactions for that (send work, verify, request, receive, request, finished)
You're using up almost 1% of the USB for a single device (0.87%)
There's of course more overhead (device status e.g. temperature or anything else available to be monitored) but 6 is pretty much the minimum.
Add 10 of these devices ... and I've no idea how well USB works running at ~9% capacity (and how that affects other USB devices)
Also, if the device is idle for even 1ms waiting for work, that's more than 1% of it's work time lost
Thus why I'm certainly using USB direct for all ASIC USB devices - not Serial-USB and adding more overhead on top of it (and timing issues)
Down the track, once the first version ASIC devices have been optimised more for hashing performance (e.g. adding passing share difficulty to the firmware if not already ... or even going as far as implementing something like Stratum in the firmware) this will reduce the bandwidth usage of a single device, but then again it shouldn't be that far down the track when 50GH/s per USB device might increase substantially.