Consolidation of serial comms issues

[adammwest]

Related issues
#24
#69

Broad themes
the counting of TX (work) send fails
the counting of successful conversion of RX_bytes->nonces and RX_Bytes==0
the warning if consecutive RX have no messages or they are failing to convert to nonces
some cases of byte processing is likely wrong from RX byte stream

(1) For RX fails warning #69
there is no pr, but it would be very trivial
for all chips the return value of send_work is ignored, this can be counted, in a metric like send TX fails/total TX send
counting the raw values rather than the division is preferable.

https://github.com/skot/ESP-Miner/blob/master/components/asic/bm1366.c#L623
https://github.com/skot/ESP-Miner/blob/master/components/asic/bm1368.c#L357
https://github.com/skot/ESP-Miner/blob/master/components/asic/bm1370.c#L435

if the fullscan_ms is not less than half of the time when dups appear, a TX send fail will result in duplicates, it has explanatory power.

for receive work the value is again handled but not counted
to receive a nonce and not convert it is a metric of interest chip_diff_nonces /(asic_rx_bytes/11)

https://github.com/skot/ESP-Miner/blob/master/components/asic/bm1366.c#L629
https://github.com/skot/ESP-Miner/blob/master/components/asic/bm1368.c#L362
https://github.com/skot/ESP-Miner/blob/master/components/asic/bm1370.c#L441

we can then warn for consecutive problems, 3 in a row or something maybe 10 or 100 to not spam log.

• asic_rx_bytes==0
• low ticket_nonces /(asic_rx_bytes/11)

both partially explain low hash rate should it occur

(2) For RX byte handling #24
there is already a pr https://github.com/skot/ESP-Miner/pull/48/commits

it would need to be extended for BM68/70 and tested

if misalignment by 1 byte many cases where nonce could exist this is not handled

0xYY represents any value
0xYY 0x55 0xaa 11 bytes fails but could be nonce
0x55 0xaa 0xYY 11 bytes fails but could be nonce
0x55 0xaa 10 bytes fails but could be nonce
not only that but for all these fails the whole 1024 buffer is cleared with a potential 93 messages
clear buf should not be executed on asic message fails, only if offset messages are handled correctly
buf size should be multiple of expected nonce asic message len 11 maybe 11*100
when a misalignment happens the function serial rx should be calling an adjustment length to realign rather than 11

finally if a nonce is given at the end of a timeout it can be split over 2 calls
https://github.com/espressif/esp-idf/blob/master/components/esp_driver_uart/src/uart.c#L1504C3-L1543C2
the first call will get a portion of the message (invalid) and the second call will be misaligned (invalid)
in such a case the nonce that is split is lost, im not sure if it is worth to be reconstructed