README: Add new section defining port Tier levels.

[dpgeorge]

Summary

MicroPython has quite a few ports now (20 of them), but not all are in the same stage of development. This PR attempts to define port Tier levels and assign a Tier to each of the existing ports.

The main aim here is to set expectations for the level of support and development each port gets. And also lower the bar of entry for new ports (eg PSOC #16705) so they can enter at a low Tier and gradually rise up to Tier 1.

The Tiers are defined in terms of properties like "stable API" and "tested on hardware for a release". I wanted to be able to distinguish between ports like the following:

• stm32: very mature and still actively developed
• alif: new and upcoming and well maintained
• esp8266: old and still going strong, but not many new features
• qemu: primarily a testing port

I think there's still a lot of room for defining the Tier levels, and which port goes under which Tier, so please provide feedback!

See prior art here:

• https://peps.python.org/pep-0011/
• https://doc.rust-lang.org/rustc/target-tier-policy.html

Trade-offs and Alternatives

This is quite a subjective set of Tiers, but I tried to make it somewhat concrete by having a table showing the properties for each Tier. Still, we need to choose reasonable properties and assign them well.

I'm not sure if this belongs in the top-level README or the docs, or maybe both.

We could call it "Class" or "Group". But I think "Tier" is better and is more widely used.

[dlech]

It might be easier to make a comparison if we sort this from most stars to least.

[dpgeorge]

Updated.

[Josverl]

I think there may be a few other points to consider mentioning or linking;

• MicroPython version lifecycle
  • is there any tier that warrants a backport of a critical fix ?
  • how do these tiers apply to a major version such as MicroPython V2.x.x ?
• Toolchain lifecycle , is there any differentiation between T1, T2 and T3 in the (range of) supported toolchain versions ?

[robert-hh]

In all respect I'm not sure about the renesas-ra being actively maintained. There seems little usage in the wider MicroPython community, very few boards from third parties (WeACT, Arduino, Seeed with RA4M1 only), and rare activities from Renesas. I have the impression, that only Matt and me are doing some updates to the port to keep it in sync.
The nrf port is a different topic. It is very different from structure and build system to the other ports on one hand, and there seems to be a good Zephyr support otherwise. That may make it a candidate for Tier M.

[dpgeorge]

In all respect I'm not sure about the renesas-ra being actively maintained.

Yes, I know, it's hard to classify all ports in a single dimension. Maybe we need two dimensions, like "established level" and "maintained level"? Or even remove the Tiers altogether and just have a table of properties vs ports, with a check-mark for each property that a port has?

The nrf port is a different topic

Agreed again. I'm not sure how to treat this port in a ranking system...

[robert-hh]

Zephyr with it#s support for various hardware is more a sub-system than a single port. Something between a pure hardware port like RP2 and a software only like unix.

[dpgeorge]

Yes, zephyr is still a port (from MicroPython's point of view).

[robert-hh]

Off topic: The STM32 port with it's long history and multitude of Chip architectures seems pretty chaotic and need a cleanup, a herculean task.

[dpgeorge]

It does have a lot of legacy. In a different classification system we would have alif, mimxrt, samd and rp2 as "modern ports", and then esp8266, stm32 as "legacy ports". But stm32 is still well maintained. And esp32 is somewhere in the middle.

It's difficult!

[AJMansfield]

The situation with Zephyr-based support is one thing, but I'd also suggest that Zephyr's Hardware Support Tiers are probably a better reference to emulate than CPython's or Rust's given their similar targeting --- and in fact, if it's possible to align our tiers to roughly correspond to theirs, that might be helpful next time someone's trying to explain the tradeoffs to their company's suits.

[dpgeorge]

@robert-hh apologies that I put mimxrt and samd initially in "Tier 2". I know you put a lot of effort into both these ports, and they should definitely be considered alongside esp32, rp2 and stm32 as "major ports". I've now fixed that up.

As I mention above, it's really hard to classify the ports along one dimension. That's why I added Tier T (testing) and Tier M (maintenance), but even with those there is still a lot of nuance which is lost. Eg alif is a "new modern port" but not yet mature or stable, yet nrf is quite old but not really considered mature because it's so different to all the other ports in the way it's organized (and it's machine API is lacking, and it's Bluetooth is different).

Maybe classifying the ports like this is not a good idea in the end? My original motivation was to set expectations (for users and developers) and lower the bar to entry for new ports like PSOC, and give them a path to mature. But maybe that can be achieved in a different way.

[robert-hh]

apologies that I put mimxrt and samd initially in "Tier 2". I know you put a lot of effort into both these ports, and they should definitely be considered alongside esp32, rp2 and stm32 as "major ports". I've now fixed that up.

Thanks, no need for apologies. Looking at the discussion and questions it seems that ESP32 and RP2 are the ones used most, followed by STM32. You should be able to tell that from firmware download statistics. And both MIMXRT and SAMD port are maintained by other people as well, which is good, but not as intense as RP2 and ESP32.

All classifications fail somehow, because they have to simplify. But it still helps users to know, which ports are better maintained and get fast updates, wand which one may lag. The feature set is something else people look for. The cleanest port in ATM is the RP2 port, being developed in a short time with all the knowledge aout the STM32 and ESP32 development and just two device types. I hope it stays straight.

[dpgeorge]

The cleanest port in ATM is the RP2 port, being developed in a short time with all the knowledge aout the STM32 and ESP32 development and just two device types. I hope it stays straight.

We should definitely keep the rp2 port clean, and have aspirations to make the other ports similar to it. IMO the alif port is quite clean as well, since it was based a lot of the rp2 port.

---

The situation with Zephyr-based support is one thing, but I'd also suggest that Zephyr's Hardware Support Tiers are probably a better reference to emulate than CPython's or Rust's given their similar targeting

Thanks @AJMansfield for linking to that, I wasn't aware of it.

I've now added a commit to this PR to change the Tier T to Tier 0, following Zephyr. That does make good sense, and means the unix port can move into Tier 0.

[dpgeorge]

Based on additional feedback from @projectgus I've updated this PR:

• The main README is now simplified and lists the ports in a section for each Tier. This makes it more approachable for beginners, and much easier to see at a glance which ports have the best support.
• The actual table of properties defining each port is moved into the docs.