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.