Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
wants to merge 9 commits into
base: master
from

Conversation

@dok-net
Copy link
Contributor

dok-net commented Nov 24, 2019

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?

@dok-net dok-net changed the title If (?) CPU frequency switch is compile-time only Use F_CPU if (?) CPU frequency switch is compile-time only Nov 24, 2019
@TD-er

This comment has been minimized.

Copy link
Contributor

TD-er commented Nov 26, 2019

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

This comment has been minimized.

Copy link
Contributor Author

dok-net commented Nov 26, 2019

@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

This comment has been minimized.

Copy link
Contributor

TD-er commented Nov 26, 2019

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".

@dok-net dok-net force-pushed the dok-net:fastgetcpufreq branch 4 times, most recently from c95df91 to 0336df4 Nov 26, 2019
cores/esp8266/core_esp8266_main.cpp Outdated Show resolved Hide resolved
@dok-net dok-net force-pushed the dok-net:fastgetcpufreq branch 2 times, most recently from a0060a2 to 165e094 Nov 28, 2019
@dok-net dok-net force-pushed the dok-net:fastgetcpufreq branch from 165e094 to 5214d3f Dec 11, 2019
@Tech-TX

This comment has been minimized.

Copy link
Contributor

Tech-TX commented Jan 8, 2020

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.

dok-net added 9 commits Nov 26, 2019
…- need to include Arduino.h further down in mock.h for this to work.
If defined F_CPU, make getCpuFreqMHz() a constexpr
Prepare PolledTimeout for dynamic CPU frequency - would fail to compile if F_CPU is not defined, helps as marker that something needs to be done.
…tCycleCount, using F_CPU:

tests/host/common/mock.h:#define F_CPU 80000000 (!)
@dok-net dok-net force-pushed the dok-net:fastgetcpufreq branch from 5214d3f to 941a9df Jan 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.