kfricke wrote:Then you know how to deal with them. One of my intentions is to make it clear for new MicroPython-ists hat only the official boards will be supported by the MicroPython core team. This does mean that any other taste of a ESP "board" (from the bare-metal MoC to the self-etched 3D-printer board) does need some care and patience in the C code of MicroPythonto be reasonably supported. There are different pins available or assigned to different functionalities and so on.
Hopefully we can point to these differences and drag in people who take care of their board. Maybe some kind of maintainers for each board? This can not be dumped onto the core team!!!
We'd like to support generic "ESP8266 port", and as many as possible specific modules tested, but the official test target is Adafruit Huzzah board. And while high-level schematic variability of ESP8266 modules isn't big (usual difference is number of pins broken out), let's face it - some of them (well, "many" if speaking of first-generation modules) differed in such things as presence/capacity of decoupling capacitors, which affected their stability.
So, we'll see how to support generic modules better and will need community feedback (for example, our current idea is to use native chip GPIO numbering and avoid adhoc board-specific numbering). And we'll also need help and participation to test various modules, report back the results, and search for solutions for issues (especially "weird" ones which aren't reproducible with other modules - we know such will pop up). From our side, you may expect the same level of hardware docs as for PyBoard - overview with pointers to official datasheets.
The bare ESP boards are intentionally skipped, because usually those can be handled as an active component only.
Officially Supported