Enhance Modularity for Multidevice Support

[tdb3]

Currently, ESP-Miner is very focused on Bitaxe hardware. It would be great to implement a set of refactors to ease the integration of other hardware (e.g. non-Bitaxe, Bitaxe-custom hardware, etc.). This could also have the added benefit of scoping functionality in a way that bugs for one type of board are less likely to impact other types (i.e. more scalable support).

These comments are from an OSMU Discord user:

Since clearly the direction this is heading is "centralized" bitaxe-ONLY multi-board support, how does custom boards gets included in the firmware?
Do we need to put up our ADC and other gizmos' libraries and contribute conditional code to the master branch?

Wanted to open this as an Issue first to garner discussion before submitting PRs on this. I'm thinking something along the lines of:

• Implement hardware abstraction through well-defined interfaces (e.g. C++ style classes that provide interface methods to purposefully abstract hardware specifics)
• Enable developers of other hardware to implement these interfaces for the specific hardware they would like supported
• Restructure directories to facilitate the integration of other hardware devices while minimizing the changing of existing/adjacent files

Here's a simple example discussing displays: Currently, the i2c SSD1306 OLED display is supported, and calls in system.c use it. https://github.com/skot/ESP-Miner/blob/08b7ad54092c59ba17b88ed4d64a4eac363ebe36/main/system.c#L129-L140 This could be abstracted out to support other displays in general, providing a few simplified well-defined interface methods. For example:

This is just a straightforward application of object-oriented approaches (e.g. inheritance/polymorphism).

system.c could be made agnostic of specific display type (i.e. just call the interface methods on a Display* that is pointing to an SSD1306Display object, which is required to implement or inherit Display's interface). Someone comes along and decides to implement support for a cool eInk display. No problem, create a new child class eInkABC123Display.

More complicated examples would include things like:

• An abstraction for NVS
• A "Board" or "Miner" base class and child classes that initialize and manage specifics of the board/hardware being used, rather than have switch statements on board type throughout the code.
• Factory pattern implementation for instantiating the appropriate "Board" (e.g. from NVS data on startup)

We could roll this out gradually in pieces over multiple PRs.

[tdb3]

We could modularize everything, but we should figure out where to draw the line based on what's reasonable. The repo is named "ESP-Miner". I'm going to assume that for now we want to have the base assumption that we're supporting the ESP32 family of microcontrollers (although currently we're just S3?).

Longer term (over years and beyond), it would be cool to have open source mining software runnable on a plethora of devices. Do this right and we can be the "Linux" of open source mining devices. Base software that enables a diverse world of open source mining devices, and enables products to come to market faster/easier/cheaper (distributing/decentralizing hashrate). One day my heated blanket will keep me warm while mining sats (kidding about this part).

[skot]

I am 100% into this. We are getting outside the "let's just see if this will work" stage and rapidly approaching an unmanageable number of variants, on the Bitaxe alone.

Supporting other Bitcoin mining projects is how we win.