...
This is the scheme I'm coding right now. My intention is to keep it simple, both to understand and for the PIC to work with, but also flexible enough that a long rigid data structure like the Avalon uses isn't required. I am interested in feedback before I get too far along, especially from ckolivas or kano who have had to code several drivers and know where difficulties may lie. My plan is to write the driver by adapting from the Avalon one where needed, but perhaps there is a better/simpler driver model for this cmd based architecture.
The scheme above sounds good since it is an actual (simple) protocol, not simply send data and receive answers.
I'd risk making the comment (but it is true) that of all the working devices so far, the BFL ASIC has the best protocol and MCU design.
BFL polling for an answer sux however, but since it has a 20 length output queue, there is no need to poll much more often than a reply is expected
(it also has a 20 length input queue)
Anyway,
The ability to send status commands and get replies while mining is important. I can't tell from your comments if it can or not.
Having to halt/finish mining to send a status request or get a status reply e.g. is very inadvisable.
The Avalon also does something right out of left field ...
It mines the work it is given continuously until more work is given - so if it reaches 0xffffffff it will start from 0x00000000 again and repeat the work.
Hopefully that ... weird ... idea hasn't been incorporated.
Having an input queue (which is what yours sounds like) is of course the best thing to avoid lost processing power (latency) between work items.
Hopefully the design is to allow adding items to the queue when it isn't full - so if it is a 1 length pre-process queue, we'd add 1 item each time a work item completes and thus there would always be work waiting for when a work item completes.
A bigger queue is way better and since on windows it's REALLY unreliable timing stuff, the bigger the queue the better.
Adding an ID (a few bytes) would be pretty much necessary if there is an input queue - where the miner could pass in an ID of it's choice and that would be returned with the nonces.
i.e. the miner would simply send a unique ID it could use on reply to identify the work source - an input queue with an ID solves any work source confusion
For LP we need to be able to abort all work and start new work (and even better if it can be done in a single command), but knowing how much work was already done at this point is necessary since at this point any incomplete work that has not provided any answers is indeed valid work done that counts towards the device performance.
It's also nice to be able to stop all work if the e.g. a temperature report says something cgminer or the user has decided is too high
Handling overheat should have 2 levels:
1) The device has a critical level that aborts work
2) The miner has an optional lower level it can use commands to do things like increase the fan or reduce the clock or even stop mining to wait for it to cool down
Make sure there is a clear way to identify the version of the protocol used
And PLEASE put a name in iManufacturer and iProduct and a unique serial number for each device in iSerial
I will be using iSerial (or some other unique id if it exists) to handle reanimating ZOMBIE devices soon in the code
(e.g. when a hotplug is detected for a device that was lost and it matches the exact same device by e.g. iSerial, it will make sense to reanimate the ZOMBIE device rather than creating a new one like it does at the moment)
Don't adapt the Avalon driver.
I don't want more serial-USB code in cgminer.
Adapt the driver-bflsc.c
No doubt once it's done I'll just rewrite it, but use that as a basis anyway for how to use usbutils.c
(there are 3 in there already modminer, bitforce and bflsc, and I'm doing icarus right now to complete all the non avalon USB drivers)
If you do it correctly, hotplug is enabled, device identification is simple (and easy to avoid overlap for devices with the same USB chip by checking iManufacturer and iProduct), and device failure is handled by usbutils.c automatically (among other things like very helpful development statistics automatically stored for devices)
Of course usbutils.c will be enhanced over time as required and the aim is for those enhancement to cover all devices automatically.
I can ramble more, but that's just repeating stuff I've spoken to the ASIC vendors about before that I've written down and you've probably already dealt with anyway.
If you want I can PM a bunch of old comments on the subject.
