nosdk8266

First of all, I want to make it clear that even though this project is a fork of nosdk8266, my goal is not to make small images, my goal is to get the maximum speed out of the ESP8266.

There is an awesome little $2 processor called an "ESP8266." It's the definitive chip that is bringing the internet of things to life. Ever wonder what the ESP8266 can do without wifi? Well, this project is it! No longer shackled by an SDK that takes up 200 kB of flash, and tons of RAM, you're free to experiment and do so quickly. Little did we realize how limited the clocks were and just how fast this chip can be once unleashed.

This is a working ESP8266/ESP8285 minimial, non-SDK application. It can optionally use the ROM functions to deal with I/O, interrupts, printf'ing, etc.

If you don't need to access FLASH at all after booting, that frees up some of those GPIOs attached to the flash chip, provided you disable its CS line.

Interestingly, you might notice that the way this works is with a 1040 MHz high speed PLL clock and divides from that. When the clock rate is very high, i.e. 189/378 MHz, the PLL may or may not lock if the processor boots at all. I found that my clock was wandering around when operating up there.

PLL Valid Values

This table represents each possible value for the function rom_i2c_writeReg (103, 4, 1, 0xVAL), (you need replace "VAL" with the desired register, for example if in "VAL" you put 0xF9, you should expect the PLL running at 52 MHz) "ERR" means that the ESP8266 won't boot All frequencies are in MHz.

Benchmark

To perform this benchmark I used this function, basically what I wanted to measure was the time that the ESP8266 took to define what numbers if the numbers from 0 to 100000 are prime.

I use this function on a for loop:

int is_prime(unsigned int n) {
   	if (n <= 1) {
   		return 0; // zero and one are not prime
   	}
   	unsigned int i = 0;
   	for (i = 2; i * i <= n; i++) {
       	if (n % i == 0) {
       		return 0;
       	}
    }
    return 1;
} 

(ofc all the other code was commented and we was just running this function)

The result of calculate 100k prime numbers was:

Prerequisites and Building

You'll need the xtensa compiler and a copy of esptool.py.

See https://github.com/espressif/esptool/releases/ for the last release of esptool.py and https://docs.espressif.com/projects/esp8266-rtos-sdk/en/latest/get-started/linux-setup.html for xtensa-lx106 compiler (Remember that you just need the compiler, so just download and uncompress the compressed file depending on your system and edit the makefile)

I strongly recommend using a Linux system. Follow the information on Espressif docs site for more details and lists of Linux package prerequisites.

Altering the Makefile

The makefile has some defaults, however, you will likely need to modify the ESP_OPEN_SDK parameter to compile on your system, so they point to your esp open sdk.

ESPTOOL:=/.../esptool.py
GCC_FOLDER:=/.../xtensa-lx106-elf

Once done, save your Makefile and type:

make clean all burn

Cleaning, building and burning should only take about two seconds. Yes, that means you can comfortably run through about 10 development cycles per minute. Let's call this your DCPM rate. Remember kids, always find ways of maximizing your DCPM rate.

Additional Remarks

All PLL settings are hard-coded for a 26 MHz external crystal. This is probaly okay because almost everyone uses this. However, it does mean you cannot use this project with any other crystals that are compatible with the ESP (i.e. 40 MHz crystals).

Credits

A large portion of figuring out what's what was done by @pvvx, over at his esp8266web repository. Additionally, some of the header files are still licensed Espressif. So, don't let the MIT license on the overarching project confuse you.

Tips I Learned

1. GCC Xtensa will create smaller code if you have volatile pointers to arrays, rather than setting absolute memory addresses. Indirect accessing isn't slower, and it makes smaller code. Additionally, if you just store the pointer to the base of an array, like the IO MUX register, and you index into it multiple times, it doesn't need to take up prescious space holding that.

2. Avoid using macro's to do pointer arithmatic. Also, try to find out where you are or'ing masks, etc. where you don't need to be.

3. Always make sure to have your function declarations available when used. Failure to do this gimps -flto's ability to inline functions.

4. Compile with -g to make the assembly listing much easier to read.

I'm sure there's more...

Todo

• Figure out how to get rid of the prologue to main(). Even though it's marked as noreturn, GCC is doing stuff with the stack, etc.

• Add Sleep feature.

• Figure out why power consumption is higher than I would expect.