making stable/unstable board status more obvious

[stevegt]

See tinygo-org/tinygo#2732, tinygo-org/tinygo#2389, and tinygo-org/drivers#328 for background. Right now the package support list says fmt works, and the microcontrollers list includes the Uno -- what's not obvious is that the intersection of those two attributes is not a working combination. I just now spotted the "may encounter bugs" note on the Uno page myself -- that doesn't jump out at readers as much as it probably should. The result is that we're seeing a higher workload and more frustration for both adopters and maintainers -- dup issues, uncertainty, etc.

Possible solutions:

1. Say something like "not recommended" instead of "may encounter bugs" when a board's support is unstable.
2. Split the board list at https://tinygo.org/docs/reference/microcontrollers/ into "stable" and "unstable" sections -- that would help adopters pick a board more easily without having to look at each individual board's page. This is probably the least amount of work.
3. Go whole-hog and combine the board list and the packages list (https://tinygo.org/docs/reference/lang-support/stdlib/) into a matrix, showing which boards are known to work with which packages. This would be useful, but a lot of work to build and maintain.

I'm leaning towards (2) -- any objections to a PR, and does anyone know if the the current "experimental" notes on existing individual board pages would provide accurate information for making the split?

[dkegel-fastly]

Maybe make the board list have columns:

• 1st column board name
• 2nd column architecture
• 3rd column whether that architecture is tested by main_test.go (AVR is disabled because it was too flaky, main (test): skip AVR tests tinygo#2523 )

Might be able to automate that fairly easily?
(And I hope we land #110 soon, too; that adds std library status per OS. )

[stevegt]

Wow. Okay, I hadn't even seen tinygo-org/tinygo#2523 myself and spent a week learning the hard way. Yeah, we need to surface these things better in the docs.

Would be ideal if we showed live CI/CD test results for both dev and release, broken out by library and hardware platform. Still trying to get my head wrapped around how per-hardware testing works -- are we only testing build of tinygo itself, or of example binaries, or are we somehow testing execution of those binaries on emulated or real target hardware? Or some combination?

E.g. Do we already have in place something that would automatically detect when fmt.Println() isn't actually producing USB output on a particular hardware target? (That's the first clue I had that something was wrong with AVR during my first test-drive of tinygo a couple weeks ago.)

[dkegel-fastly]

Build-only tests for all small targets:
The "make smoketest" at the end of .github/workflows/linux.yml make sure that at least one example compiles for each target.

Emulated tests for small targets:
The "make tinygo-baremetal" at the end of .github/workflows/linux.yml makes sure that very small set of tests (currently just encoding/hex) passes on a very small set of emulated targets (currently cortex-m-qemu).

Real hardware tests for small targets:
Look at the test results for the tip of dev and release.
The "TinyHCI" test results are from https://github.com/tinygo-org/tinyhci, which runs on real hardware.
I haven't looked at that at all, but I think it only tests hardware functions.

All of the above could probably stand some expansion. In particular, tinygo-baremetal could make sure a simple smoke test of fmt passes. ( Once reflect improves, perhaps after tinygo-org/tinygo#2640 lands, we could even make sure "tinygo test fmt" passes.)