That depends. If the two devices are completely different in their feature set, I'd rather have two applications open, than one common one that shoehorns everything into the same format that either throws away a lot of features, or requires an overly complex specification to capture all possibilities.

Here we go....

The problem is that the information from the hardware is unstructured. One piece of hardware may have a board temperature sensor, another piece of hardware may have two. Or, maybe one for the board, and one for the power regulator, and maybe one integrated into each of the 512 chips. It's going to be impossible to find a common way to bind all these different kinds of properties, and find a nice way to format them all in a single line on a screen.

And the bizarre thing is that all the information about LEDs, clocks, voltages, error rates, and chip temperatures goes into the mining software, which doesn't really have a clue what to do with that. So, you need equally complicated config files to tell it that LED A needs to turn color B when temperature sensor C is >= D degrees.

Really, this information is something that only concerns the mining hardware and the user. There's no need to standardize it all, just for the benefit of the middle man who doesn't really care anyway.  A better approach would be to create a mining library that's responsible for reliable network communication, and provides a standard get/put work interface. That way, the vendor can just write his own application, communicating with it's own hardware, and just call the mining library to get fresh work and submit the results.

Instead of 'skipping', think of it as 'replacing'. The hardware is still looking for valid solutions, just using different combinations of coinbase/timestamp/nonce. You are just as likely to find a solution if you only search half the nonce space, increment timestamp, and search the same half again in the same time as another miner searches the whole nonce space once.

Very nice, very colorful!

It makes no difference whether you scan 1 full range, or 2 half ranges. The only thing that matters is how many hashes per second you can do.

It's a limitation of the hardware. The bitfury chips have 756 separate hashing cores, all working in parallel, with each core hardwired to search a fixed 1/1024th of the nonce space.

With partial scans, you just introduce a lot of extra complexity. Before you can use it, you need to know if the hardware has options to set the nonce range, and you need to know the exact limitation of the hardware. For instance, the bitfury chips only scan 756/1024 of the nonce range, but the hole is not contiguous, and not user-settable. To match this limitation with other hardware is very complicated. Even if you wanted to try, it requires extra commands to obtain the information from the hardware.

To generate some new work is simple. You just call the code you already have, except a little more frequently. Sure, it wastes some CPU time, but I'd like to see that this is a problem before creating a solution.

Why would you care about scanning the rest of the nonces ? It's much easier to ignore that part of the nonce space, and create some new work instead.

The way I have it implemented in my USB firmware is:

work job_id block_header

The block header includes the time stamp, and the hardware is allowed to increment it. The job_id is just a number. There is no nonce range (hardware always searches full range), ntime rolling is always permitted, difficulty is set through separate command but I like your idea of including it in the work command. I don't really see a need for a nonce range. With fast hardware, the entire 32 bit nonce range is searched in just a few seconds max, and with slow hardware (what's the point ?) you can always cancel old job when a new one comes in.

To submit a valid nonce, the firmware responds with

submit nonce job_id timestamp

I have no 'needwork' command. The idea is that the host provides work quickly enough to satisfy the hardware. In case the work doesn't come quickly enough, the hardware starts incrementing the timestamp. So, if the host does not want to accept ntime rolling, it is responsible for supplying fresh work before the hardware needs it. 

I also don't have cancel job mechanism. The hardware detects that prevhash field has changed, and automatically cancels old work as quickly as it can. Of course, it doesn't hurt to include an explicit cancel command. Another option would be to include a cancel flag in the 'work' command, which is nice because when you cancel old jobs you must provide new work at the same time, otherwise the hardware has nothing to do.

And you should also change your default password, otherwise the unit can still be accessed.

Here's pinout diagram of the RPi I/O connector. There's a +5V pin that can be used to power the RPi. On the m-board is a 12V->5V regulator that feeds into that pin.

Correct. The M-board has a regulator that provides power to the RPi connector.

No, just remove the bad h-card, and reorder the cards so that the unused sockets are all at the end. Likewise, a single partially broken h-card can be moved to the end of the chain.

The spitest program was announced here:

https://bitcointalk.org/index.php?topic=228677.msg2515472#msg2515472

You mean a board to interface to the current m-board ? That's basically only a RPi replacement, but less powerful, and at least as expensive.

I was thinking more of a small PCB with an edge connector, where you plug in a single H-CARD. This replaces both the big m-board and the RPi, and would be useful for people only interested in mining with 1 or 2 H-CARD attached to a PC.  For more H-CARDs, the m-board is the more practical solution.

If there's enough interest, we wouldn't mind drawing up an adapter board for a single H-CARD to USB and/or ethernet.

Our S-HASH board has a native Ethernet connection and can connect directly to a pool.

See this thread for more info

Like with the S-HASH design, we're not looking to mass produce this ourselves, but we're open for licensing agreements with 3rd parties to build them. It's hard to estimate a cost. It all depends on volume and what kind of deal you can make with the bitfury ASIC sellers.

The 5 parallel resistors on the back are (counting from corner): 220k, 147k, 187k, 220k, 100k. Did they put silk screen on the back ?

Or in the (over)current sense resistors. I assume the resistors are all unmarked ?