Use F_CPU if (?) CPU frequency switch is compile-time only

[dok-net]

Then ESP.getCpuFreqMHz() can be optimized to use F_CPU and be constexpr.
polledTimeout using F_CPU instead of the dynamic system_get_cpu_freq() anyway, I see no issue.

On review, please consider this, in core_esp8266_main.cpp:

void preloop_update_frequency() __attribute__((weak));
void preloop_update_frequency() {
#if defined(F_CPU) && (F_CPU == 160000000L)
    REG_SET_BIT(0x3ff00014, BIT(0));
    ets_update_cpu_frequency(160);
#endif

Could this be turned into dynamic frequency switching?

[TD-er]

Could this be turned into dynamic frequency switching?

That would be nice.
My first concern is what this would do with WiFi stability.

[dok-net]

@TD-er That left to future considerations, do you have any issues with the merit of this PR alone? It's about constexpr (latest addition) for getCpuFreqMHz().

[TD-er]

Nope, PR looks good.
I was merely reacting to your own question on dynamic switching.
As we don't know anything about the WiFi code, it may be hard to predict whether it does rely on register values or internal stored copies (or derived values) of the actual frequency at some moment during initialization.
If your wondering was with the intent to have it "dynamic at boot", then I don't see any issue and would be glad to see this as a "run time" feature and not "compile time".

[Tech-TX]

Based on what cnlohr got when he changed the baseband PLL, the rfpll is tied to bbpll somehow and the WiFi spectrum narrowed when he slowed the CPU down. You might be able to dynamically switch, but you'd need to reprogram the WiFi as well.

edit: Nope, I'm wrong. The center frequency of Charles' tests stayed the same as did the RF envelope, so the only thing that changed was the data rate (slower CPU clock = slower data rate = narrower spectrum). Looks like you might be able to dynamically switch the CPU without regard to the WiFi programming, but SYS would need to know the CPU changed to adjust various timings.