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.
first off, I am honored, impressed and excited that you are putting so much time into this! Thank you! I am slowly working on the C (esp-idf/FreeRTOS) based FW. Once I get this bitaxeMax_v2 board design wrapped up and ordered, I'll dig into it some more.
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).
yes, exactly. Even the C version of the firmware isn't really a port. cgminer relies on too many OS APIs to really be ported to embedded. Nonetheless, cgminer is a great example of the main concepts in miner software and ck, sidehack and kano have done a great job with this. Thanks guys!
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...
this is awesome. Anything we can do to better understand the BM1397 is great. I started a GitHub repo to dump everything I am learning about the BM1397 here
https://github.com/skot/BM1397. Sidehack and Kano are obviously way ahead on this. The new cgminer is a treasure trove of BM1397 learning;
https://github.com/kanoi/cgminerFor 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 kind of a mixed 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.
I was lured into the ESP32 world because of their RISC-V core in the ESP32-C3 and the fact that it's available (you can't say that for many 32bit MCUs these days). For those who don't know, RISC-V is a relatively new ISA (processor core) that is free and open -- a welcome change from the fiercely closed incumbents like ARM and x86. The RISC-V core ESP32 isn't quite ready for this project yet, so the ESP32-S3 with the Xtensa core will work nicely until it is.
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).
I feel like WiFi itself should be reliable enough for mining. Is the ESP32 WiFi implementation the problem? Maybe the antenna isn't good enough? I'd really like to have these miners be wireless. I dream of attaching one to a solar panel and putting it out in my yard to mine whenever the sun's out.
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).
Embassy does look cool. It's frustrating though that it's only really available for STM32 and nRF -- both MCUs that are extremely affected by the chip shortage. It looks like the RP2040 is somewhat available?
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.
Great! I'm pretty close on the bitaxeMax v2 design, hopefully we can get you some HW soon!