Rust FW for bitaxe is a big subject i am working on everyday. As I said in a previous post, it is better someone work on a standard C FW based on existing component (cgminer) instead of waiting for the Rust solution which will take longer time.

There not such "cgminer porting in Rust", cgminer is heavyly dependant on C. The best I can do, is to use cgminer driver for BM1397 based HW, to understand the low level (undocumented) protocol. Then code a (Rust) driver for BM13xx (based on Rust Embedded-Hal abstraction).

To update on my progress doing so, I received the broken T17 I brought on ebay (2 hashboard seems to be functional enough to be communicating) with stock FW, so I was able to log serial/i2c communication between ControlBoard and HashBoard using Saleae Logic2 (logic analyzer) and code a High Level Analyzer to parse the Serial Protocol (communication with BM13xx), it is available on https://github.com/GPTechinno/bm13xx-hla. Basic communication protocol is covered, I am into understanting the registers and their fields now. For this I do cross comparaison with S9k log (BM1393) with stock FW I also have on hand. I will also try different custom FW for the T17 (including BraiinsOS+) to learn how these differents flavor handle the same HW. I would be also very interested to have more log from other miner (S17...). So a lot of work need to be done in this direction...

For the ESP32-S3 selection, it is the most ESP32 capable chip, that's why I guess Skot selected it. Its exotic architecture (Xtensa) make it less compatible with existing project. Nevertheless, esp-rs, which is the Rust support for ESP32 family seems to have active community and good result. Basically, there is 2 flavors :
- one based on IDF (the framework supplied by Espressif, based on FreeRTOS, so a low level OS in C, that can handle all wifi/network layers) where Rust application can be run on top (so a king of mix C/Rust embedded). To my personal point of view, considering this approach, it is better to have a full IDF FW with existing cgminer C cross compiled to it, no need for Rust here, this is the "standard C FW" I was refering to earlier.
- one based on plain Rust, but no wifi/network is available yet.

IMHO wifi is not reliable enought for 24/7 mining device, copper wire (Ethernet) is much more prefered here. That's why I have close look also into W5500 SPI/Ethernet bridge from Wiznet (I used them a lot in many other project), that has a very good support in Rust Embedded enviroment (https://github.com/newAM/w5500-rs).

For the Rust embedded framework, there is mainly 2 solutions :
- RTIC : Real Time Interrupt-driven Concurrency which I am not yet fully documented. Community seems very active. Alex (from w5500-rs) has a project example with it (https://github.com/newAM/ambientsensor-rs).
- Embassy : EMBedded ASYnc, which I start to love more and more. It has great support for STM32 and RP2040 (RPi PICO chip) but no ESP32 yet. w5500-embassy is not finish eyt, but Alex gave me access to its private repo where job is ongoing there. I will try to make progress on it. I tink a great HW for this, is the W5500-EVB-PICO, basically a RP2040 with a W5500 on a stick (brought 2 of them). RP2040 is a dual core Cortex-M0+ at 133MHz. Having a dual core look promising to have one core for the Network (Ethernet/W5500/StratumV2), and the second one for the BM13xx serial handling. Embassy seems to be able to deal with these 2 differents contexts (not tried yet).

Finally, why I think Rust is way to go for a embedded miner, it is mainly because Stratum V2 Reference Implementation is done in Rust (https://github.com/stratum-mining/stratum), I recently joined their weekly dev meeting and they seems to be interesting into a first embedded implementation. It can be done on the ESP32-S3 on top of IDF without the need to have actual BM13xx I think.


And about others Bitaxe's chip driver, I have well debugged my EMC2101 rust driver, but it is not finished yet.