makefiles, treewide: Remove MCU variable

[chrysn]

Contribution description

The MCU variable, which appears to historically be a place where a CPU (which defines which cpu/... directory gets included) can be refined, is not in use as advertised (its documentation said that it is "set by the board's Makefile.include, or defaulted to the same value as CPU", but grepping for MCU in boards/*/Makefile.include just mentions the term in prose). CPU is always equal to MCU as we use it now. In its place, we nowadays use the CPU_FAM and the CPU_MODEL variables.

This PR removes MCU from the Makefiles, and changes all the places where MCU is used (mainly esp_common and some drivers, [edit] as well as some examples) into the equivalent CPU checks.

Testing procedure

• Green CI is all the testing that makes sense. If we could assert that the compiled binaries (or even the C code after preprocessor) is the same, that'd be great, but we don't have those tools. [edit: Some binaries changed b/c they reported "the MCU" and now report "the CPU", and one example reported both CPU and MCU, thus shrank.]

[chrysn]

I'm flagging this as an "API change", not only because it's the right thing to do, but also because it will earn it a place around "changes possibly necessary in applications" section of the next release notes.

[riot-ci]

Murdock results

✔️ PASSED

9716510 pkg/micropython: Adjust to removed RIOT_MCU

Success	Failures	Total	Runtime
10011	0	10011	11m:46s

Artifacts

• Documentation preview

[chrysn]

One late addition is adding a RIOT_MCU variable to micropython because unlike for other packages, the RIOT specific code there is not in-tree but in a fork of upstream code; PR there incoming[edit: here -- in kaspar030/micropython#5]

[kaspar030]

ACK.

[chrysn]

Updated once more because the micropython RIOT port now doesn't need a workaround any more (kaspar030/micropython#5 was merged); updating micropython in a separate commit instead.

There has been some flakiness in unrelated tests, let's see whether we're lucky this time.

[chrysn]

... and a few occurrences of (MCU) or {MCU} have been missing before (which were used in Makefiles, and have now been grepped for exhaustively).

[benpicco]

This broke esp8266 😕

[miri64]

Why wasn't this deprecated first? This also broke some external repos, such as https://github.com/netd-tud/riot-exercises/ (luckily we are currently still in the progress of deploying it still).

[chrysn]

The discrepancies between documentation of the MCU makefile variable and the actual mechansims use by CPU implementations indicated that the mechanism was not used.

The removal of the RIOT_MCU define was a detail I didn't individually consider for whether or not it should have been deprecated (it could still have been set to indicate RIOT_CPU). I'd have no objections to re-introducing a RIOT_MCU define under a deprecation. However, given that compiler constants can not be annotated with deprecation warnings, I doubt doing a deprecation there would have any effect other than delaying when people notice that their builds are failing.

[maribu]

To be honest, I did not consider RIOT_MCU as part of any public API, but rather an internal implementation detail. There was no doc for it (and there is no doc for the new RIOT_CPU, either).

I think it would be possible to add a proper deprecation if our mechanism to generate riotbuild.h would be a bit more sophisticated. But someone(tm) would have to do that.

Note that in doc/doxygen/riot.doxyfile a number of predefined macros are given, e.g. RIOT_FILE_RELATIVE. But neither RIOT_CPU nor RIOT_MCU made it there.