Convert Figma logo to code with AI

pfalcon logoesp-open-sdk

Free and open (as much as possible) integrated SDK for ESP8266/ESP8285 chips

1,968
623
1,968
138

Top Related Projects

Latest ESP8266 SDK based on FreeRTOS, esp-idf style.

Arduino core for the ESP32

Lua based interactive firmware for ESP8266, ESP8285 and ESP32

13,291

Espressif IoT Development Framework. Official development framework for Espressif SoCs.

Quick Overview

The esp-open-sdk is an open-source project that provides a complete and self-contained SDK (Software Development Kit) for ESP8266 Wi-Fi modules. It combines the Espressif IoT SDK with GCC toolchain and other essential tools, making it easier for developers to build and flash firmware for ESP8266 devices.

Pros

  • All-in-one solution for ESP8266 development
  • Includes the latest Espressif IoT SDK and necessary tools
  • Supports both 32-bit and 64-bit Linux systems
  • Regularly updated to incorporate the latest improvements and bug fixes

Cons

  • Large download size due to the inclusion of multiple components
  • Compilation process can be time-consuming, especially on slower machines
  • Limited support for Windows operating systems
  • May require additional setup steps for some specific development environments

Getting Started

To get started with esp-open-sdk, follow these steps:

  1. Clone the repository:

    git clone --recursive https://github.com/pfalcon/esp-open-sdk.git
    
  2. Install required dependencies (example for Ubuntu/Debian):

    sudo apt-get install make unrar-free autoconf automake libtool gcc g++ gperf \
        flex bison texinfo gawk ncurses-dev libexpat-dev python-dev python python-serial \
        sed git unzip bash help2man wget bzip2 libtool-bin
    
  3. Build the SDK:

    cd esp-open-sdk
    make STANDALONE=y
    
  4. Add the toolchain to your PATH:

    export PATH=/path/to/esp-open-sdk/xtensa-lx106-elf/bin:$PATH
    

Now you can use the SDK to compile and flash firmware for your ESP8266 devices.

Competitor Comparisons

Latest ESP8266 SDK based on FreeRTOS, esp-idf style.

Pros of ESP8266_RTOS_SDK

  • Official SDK from Espressif, ensuring better compatibility and support
  • Includes FreeRTOS, providing a robust real-time operating system
  • More frequent updates and active development

Cons of ESP8266_RTOS_SDK

  • Steeper learning curve due to RTOS complexity
  • Potentially higher resource usage compared to bare-metal programming

Code Comparison

ESP8266_RTOS_SDK:

#include "freertos/FreeRTOS.h"
#include "freertos/task.h"

void app_main()
{
    xTaskCreate(&my_task, "my_task", 2048, NULL, 5, NULL);
}

esp-open-sdk:

#include "ets_sys.h"
#include "osapi.h"

void user_init()
{
    // Your initialization code here
}

The ESP8266_RTOS_SDK uses FreeRTOS tasks and functions, while esp-open-sdk uses a simpler bare-metal approach. ESP8266_RTOS_SDK offers more advanced features and better multitasking capabilities, but esp-open-sdk provides a lighter-weight solution for simpler projects.

ESP8266_RTOS_SDK is ideal for complex applications requiring real-time scheduling and advanced features, while esp-open-sdk is better suited for smaller projects or when resource constraints are a concern. The choice between the two depends on project requirements, developer expertise, and desired level of control over the system.

Arduino core for the ESP32

Pros of arduino-esp32

  • Easier integration with Arduino ecosystem and libraries
  • More user-friendly for beginners and hobbyists
  • Regular updates and active community support

Cons of arduino-esp32

  • Less flexibility for low-level programming and customization
  • Potentially larger code size due to Arduino abstraction layer
  • May not be suitable for highly optimized or resource-constrained projects

Code Comparison

esp-open-sdk:

#include "esp_common.h"

void user_init(void)
{
    // Low-level initialization code
}

arduino-esp32:

#include <Arduino.h>

void setup() {
    // Arduino-style setup code
}

void loop() {
    // Arduino-style main loop
}

Summary

esp-open-sdk provides a more low-level approach to ESP8266 development, offering greater control and potential for optimization. It's better suited for experienced developers working on resource-constrained or highly customized projects.

arduino-esp32, on the other hand, simplifies ESP32 development by leveraging the Arduino framework. It's more accessible to beginners and allows for rapid prototyping, but may sacrifice some performance and flexibility compared to esp-open-sdk.

The choice between these repositories depends on the developer's experience level, project requirements, and desired development workflow.

Lua based interactive firmware for ESP8266, ESP8285 and ESP32

Pros of nodemcu-firmware

  • Built-in Lua interpreter for easier scripting and rapid development
  • Extensive library support for various IoT protocols and sensors
  • Active community with frequent updates and contributions

Cons of nodemcu-firmware

  • Higher resource consumption due to Lua interpreter overhead
  • Limited low-level hardware access compared to esp-open-sdk
  • Potential performance limitations for complex applications

Code Comparison

esp-open-sdk (C code):

#include "esp_common.h"

void user_init(void) {
    gpio_init();
    gpio_output_set(BIT2, 0, BIT2, 0);
}

nodemcu-firmware (Lua code):

gpio.mode(2, gpio.OUTPUT)
gpio.write(2, gpio.HIGH)

The esp-open-sdk example demonstrates low-level C code for GPIO initialization, while nodemcu-firmware showcases the simplicity of Lua for the same task. esp-open-sdk offers more control but requires more expertise, whereas nodemcu-firmware provides an easier entry point for IoT development at the cost of some performance and flexibility.

13,291

Espressif IoT Development Framework. Official development framework for Espressif SoCs.

Pros of esp-idf

  • Official SDK from Espressif, ensuring better compatibility and support
  • More comprehensive documentation and examples
  • Regular updates and active development

Cons of esp-idf

  • Steeper learning curve for beginners
  • Larger codebase and more complex project structure

Code Comparison

esp-open-sdk:

#include "ets_sys.h"
#include "osapi.h"
#include "gpio.h"
#include "os_type.h"

void user_init(void)
{
    // Simple GPIO initialization
    gpio_init();
}

esp-idf:

#include "freertos/FreeRTOS.h"
#include "freertos/task.h"
#include "driver/gpio.h"
#include "esp_system.h"

void app_main(void)
{
    // More advanced GPIO configuration
    gpio_config_t io_conf = {
        .pin_bit_mask = (1ULL << GPIO_NUM_2),
        .mode = GPIO_MODE_OUTPUT,
        .pull_up_en = 0,
        .pull_down_en = 0,
        .intr_type = GPIO_INTR_DISABLE,
    };
    gpio_config(&io_conf);
}

The esp-idf code demonstrates a more structured and feature-rich approach, utilizing FreeRTOS and providing more detailed GPIO configuration options. In contrast, esp-open-sdk offers a simpler, more straightforward implementation, which may be easier for beginners to understand but provides less flexibility and advanced features.

Convert Figma logo designs to code with AI

Visual Copilot

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

esp-open-sdk

This repository provides the integration scripts to build a complete standalone SDK (with toolchain) for software development with the Espressif ESP8266 and ESP8266EX chips.

The complete SDK consists of:

  1. Xtensa lx106 architecture toolchain (100% OpenSource), based on following projects:

The source code above originates from work done directly by Tensilica Inc., Cadence Design Systems, Inc, and/or their contractors.

  1. ESP8266 IoT SDK from Espressif Systems. This component is only partially open source, (some libraries are provided as binary blobs).

OpenSource components of the SDK are based on:

Requirements and Dependencies

To build the standalone SDK and toolchain, you need a GNU/POSIX system (Linux, BSD, MacOSX, Windows with Cygwin) with the standard GNU development tools installed: bash, gcc, binutils, flex, bison, etc.

Please make sure that the machine you use to build the toolchain has at least 1G free RAM+swap (or more, which will speed up the build).

Debian/Ubuntu

Ubuntu 14.04:

$ sudo apt-get install make unrar-free autoconf automake libtool gcc g++ gperf \
    flex bison texinfo gawk ncurses-dev libexpat-dev python-dev python python-serial \
    sed git unzip bash help2man wget bzip2

Later Debian/Ubuntu versions may require:

$ sudo apt-get install libtool-bin

MacOS:

$ brew tap homebrew/dupes
$ brew install binutils coreutils automake wget gawk libtool help2man gperf gnu-sed --with-default-names grep
$ export PATH="/usr/local/opt/gnu-sed/libexec/gnubin:$PATH"

In addition to the development tools MacOS needs a case-sensitive filesystem. You might need to create a virtual disk and build esp-open-sdk on it:

$ sudo hdiutil create ~/Documents/case-sensitive.dmg -volname "case-sensitive" -size 10g -fs "Case-sensitive HFS+"
$ sudo hdiutil mount ~/Documents/case-sensitive.dmg
$ cd /Volumes/case-sensitive

Building

Be sure to clone recursively:

$ git clone --recursive https://github.com/pfalcon/esp-open-sdk.git

The project can be built in two modes:

  1. Where the toolchain and tools are kept separate from the vendor IoT SDK which contains binary blobs. This makes licensing more clear, and helps facilitate upgrades to vendor SDK releases.

  2. A completely standalone ESP8266 SDK with the vendor SDK files merged into the toolchain. This mode makes it easier to build software (no additinal -I and -L flags are needed), but redistributability of this build is unclear and upgrades to newer vendor IoT SDK releases are complicated. This mode is default for local builds. Note that if you want to redistribute the binary toolchain built with this mode, you should:

    1. Make it clear to your users that the release is bound to a particular vendor IoT SDK and provide instructions how to upgrade to a newer vendor IoT SDK releases.
    2. Abide by licensing terms of the vendor IoT SDK.

To build the self-contained, standalone toolchain+SDK:

$ make STANDALONE=y

This is the default choice which most people are looking for, so just the following is enough:

$ make

To build the bare Xtensa toolchain and leave ESP8266 SDK separate:

$ make STANDALONE=n

This will download all necessary components and compile them.

Using the toolchain

Once you complete build process as described above, the toolchain (with the Xtensa HAL library) will be available in the xtensa-lx106-elf/ subdirectory. Add xtensa-lx106-elf/bin/ subdirectory to your PATH environment variable to execute xtensa-lx106-elf-gcc and other tools. At the end of build process, the exact command to set PATH correctly for your case will be output. You may want to save it, as you'll need the PATH set correctly each time you compile for Xtensa/ESP.

ESP8266 SDK will be installed in sdk/. If you chose the non-standalone SDK, run the compiler with the corresponding include and lib dir flags:

$ xtensa-lx106-elf-gcc -I$(THISDIR)/sdk/include -L$(THISDIR)/sdk/lib

The extra -I and -L flags are not needed when using the standalone SDK.

Subdirectory examples/ contains some example application(s) which can be built with esp-open-sdk. If you are interested in real-world, full-fledged, advanced example of a project built using esp-open-sdk, check https://github.com/micropython/micropython/tree/master/ports/esp8266.

Pulling updates

The project is updated from time to time, to get updates and prepare to build a new SDK, run:

$ make clean
$ git pull
$ git submodule sync
$ git submodule update --init

If you don't issue make clean (which causes toolchain and SDK to be rebuilt from scratch on next make), you risk getting broken/inconsistent results.

Additional configuration

You can build a statically linked toolchain by uncommenting CT_STATIC_TOOLCHAIN=y in the file crosstool-config-overrides. More fine-tunable options may be available in that file and/or Makefile.

License

esp-open-sdk is in its nature merely a makefile, and is in public domain. However, the toolchain this makefile builds consists of many components, each having its own license. You should study and abide them all.

Quick summary: gcc is under GPL, which means that if you're distributing a toolchain binary you must be ready to provide complete toolchain sources on the first request.

Since version 1.1.0, vendor SDK comes under modified MIT license. Newlib, used as C library comes with variety of BSD-like licenses. libgcc, compiler support library, comes with a linking exception. All the above means that for applications compiled with this toolchain, there are no specific requirements regarding source availability of the application or toolchain. (In other words, you can use it to build closed-source applications). (There're however standard attribution requirements - see licences for details).