Sorry to change the subject from Heatsinks.
I'm a little concerned about the plan for reading RESULT using the ESAUSRT. It seems like a nice hack but what happens if the serial port gets into a bad state - if an extra clock edge is caused by a reset, noise, or a result collision, and the framing comes out of sync - the serial port's bit count is wrong.
I agree that result collisions will be rare enough that they can be ignored - as long as the failure mode is simply a dropped share, but if the failure mode is that it stops being possible to get a valid result until a system reset, that would not be acceptable. It could also be very difficult to debug.
The solution might be as simple as a periodic process that detects that the serial port is in a bad state, has been for minimum amount of time, and does a firmware reset of the port to correct the situation.
I've seen this type of problem in other designs and just wanted to make sure you were aware of it.
I would probably re-init the serial receiver at the end of pushing new work each time. That way it is always in a known state at the start of work.
It's all a big guess for now.
Also, there seems to be no schematics for the Klondike design, which makes it very hard to troubleshoot or check for the community.
I'm very surprised nobody asked for the schematics before (except for me, but no answer from the designer).
It doesn't give me a good feeling.
Many people have asked for schematics (every day) but I won't be providing them until I have a working product to release. I believe I stated that up thread somewhere. If not, well, I thought I did. I gave this much consideration before deciding that I'm not obliged to help everyone flood the market with clones before I even get the product of my own efforts released.