ESP8266 Developer Zone

Re: Running at 160MHz

2018-02-23T16:55:16+08:00

Apologies for the necromancy!
Great devices BTW

Apart from increased power requirement, why would I not run at 160Mhz, or conversely, why should I run at 80Mhz?
Other than power consumption, what are the trade-offs?

-----

Regarding UART speed etc. mentioned above.
It would make no sense to have UART speeds change with processor speeds! These are controlled by onboard counters and dividers; and of course you will see a correlation between clock-speeds and available counters & dividers (note the power of 2 increase in speed, so a simple divide by (another) 2 will get things back on course). bit-banged UARTs would of course allow for greater diversity. This is evidenced above by the attempt to use the UART to check processor speed. Consider the mayhem that this would cause if this were not the case.

Kind regards
0

Statistics: Posted by 0AlphaOmega — Fri Feb 23, 2018 4:55 pm

Re: Running at 160MHz

2016-01-17T08:54:10+08:00

I know this is an old thread, but I see an issue with RTOS SDK 1.3.0.

Doing

Code:

system_update_cpu_freq(160);

I see that

Code:

uint32 t = system_get_time();
vTaskDelay(100 / portTICK_RATE_MS);
printf ("%d\n", system_get_time()-t);

now shows only 50ms. It was 100ms (as expected) when running at 80MHz (see example below).

Either vTaskDelay() is wrong or system_get_time() is. Or maybe I need to do more that this to set the CPU speed

Code:

REG_SET_BIT(0x3ff00014, BIT(0));
system_update_cpu_freq(160);

Here is an example from my actual app looping. 'before' is time from loop start, 'after' is time of just the 'vTaskDelay', should show a value around 100000.

Running at 80MHz:

Code:

8 696053 before 
8 99940 after
9 796051 before 
9 99944 after
10 896050 before 
10 100055 after
11 996168 before 
11 99828 after

Running at 160MHz:

Code:

1 3 before 
1 47981 after
2 48030 before 
2 49924 after
3 97982 before 
3 50013 after
4 148027 before 
4 49934 after

Statistics: Posted by eyal — Sun Jan 17, 2016 8:54 am

Re: Running at 160MHz

2015-08-27T18:01:01+08:00

Does anyone know if it's possible to change the RTC and UART speed also, when changing from 80MHz to 160MHz CPU clock frequency.

Statistics: Posted by skywave — Thu Aug 27, 2015 6:01 pm

Re: Running at 160MHz

2015-08-21T04:50:10+08:00

Interesting question, so far it doesn't look like there any drawbacks. Beside the higher power usage of course. I don't think it will double anyway.

Statistics: Posted by eriksl — Fri Aug 21, 2015 4:50 am

Re: Running at 160MHz

2015-08-20T02:33:40+08:00

Are there any drawbacks of using the CPU at 160Mhz instead?

Statistics: Posted by skywave — Thu Aug 20, 2015 2:33 am

Re: Running at 160MHz

2015-08-13T10:30:37+08:00

Hi,

So sorry that UART clock confused you~ we will revise it in next version of SDK.

Thanks for your interest in ESP8266 !

Statistics: Posted by ESP_Faye — Thu Aug 13, 2015 10:30 am

Re: Running at 160MHz

2015-08-09T22:33:51+08:00

Confirming my observations, the v1.3.0 SDK documentation has this note in the description of system_update_cpu_freq():

Note:
System bus frequency is 80MHz, will not be affected by CPU frequency. The
frequency of UART, SPI, or other peripheral devices, are divided from system
bus frequency, so they will not be affected by CPU frequency either.

Statistics: Posted by dkinzer — Sun Aug 09, 2015 10:33 pm

Re: Running at 160MHz

2015-08-09T04:00:00+08:00

That's interesting information, thanks for finding that out.

It's also a mode of operation that's very easy to use that way, with little side-effects, that's nice.

All of this should have been in the documention of the relevant api function of course

Statistics: Posted by eriksl — Sun Aug 09, 2015 4:00 am

Re: Running at 160MHz

2015-08-08T02:42:31+08:00

eriksl wrote:
The defines in the include files suggest the cup clock is directly as uart clock.

I agree that the defines in the include file are misleading. I've done some additional testing and this is what I've found:

Statistics: Posted by dkinzer — Sat Aug 08, 2015 2:42 am

Re: Running at 160MHz

2015-08-05T15:21:34+08:00

The defines in the include files suggest the cup clock is directly as uart clock (which then is divided then of course), so it looks like either one is wrong.

Statistics: Posted by eriksl — Wed Aug 05, 2015 3:21 pm

Re: Running at 160MHz

2015-08-05T13:30:44+08:00

Hi，

CPU changes to 160MHz would not have effect on the clock for UART.

So UART baudrate will not change.

Thanks for your interest in Espressif Systems and ESP8266 !

Statistics: Posted by ESP_Faye — Wed Aug 05, 2015 1:30 pm

Re: Running at 160MHz

2015-08-02T23:07:06+08:00

blubb wrote:
system_update_cpu_freq(160);

Thanks. There is a prototype in the v1.2.0 SDK for that function but still no joy. After setting the frequency to 160MHz a UART divisor of 694 yields 115200 baud rather than 230400 as it should thus indicating the the CPU is still running at 80MHz.

Statistics: Posted by dkinzer — Sun Aug 02, 2015 11:07 pm

Re: Running at 160MHz

2015-08-02T05:34:53+08:00

Try

system_update_cpu_freq(160);

Statistics: Posted by blubb — Sun Aug 02, 2015 5:34 am

Running at 160MHz

2015-08-02T04:01:21+08:00

Various sources indicate that the CPU frequency can be changed from 80MHz to 160MHz by setting bit 0 at 0x3ff00014 with the caveat that os_update_cpu_frequency() must be called to indicate the operating frequency (in MHz). I have tried using this sequence in my user_init(), my post_init() and in the task itself. In all cases, the processor appears to continue to run at 80MHz as evidenced by the resulting UART baud rate and the speed of toggling an output pin, both being half of what they should be. The test app was linked with the v1.2.0 SDK which, by the way, no longer contains the prototype for os_update_cpu_frequency().

Has anyone else been able to get this to work reliably?

Statistics: Posted by dkinzer — Sun Aug 02, 2015 4:01 am