ESP32 Software – Software Development Kit (espressif)
Informatie (ENG):
Setting Up ESP-IDF
In the docs directory you will find per-platform setup guides:
Set up of Toolchain for Windows
Step 1: Quick Steps
- Windows doesn’t have a built-in “make” environment, so as well as installing the toolchain you will need a GNU-compatible environment. We use the MSYS2 environment to provide. You don’t need to use this environment all the time (you can use Eclipse or some other front-end), but it runs behind the scenes.
The quick setup is to download the Windows all-in-one toolchain & MSYS zip file from dl.espressif.com:
https://dl.espressif.com/dl/esp32_win32_msys2_environment_and_toolchain-20160816.zip
Unzip the zip file to C:and it will create an “msys32” directory with a pre-prepared environment.
Alternative Step 1: Configure toolchain & environment from scratch
As an alternative to getting a pre-prepared environment, you can set up the environment from scratch:
- Navigate to the MSYS2 installer page and download the
msys2-i686-xxxxxxx.exe
installer executable (we only support a 32-bit MSYS environment, it works on both 32-bit and 64-bit Windows.) - Run through the installer steps, and accept the “Run MSYS2 now” option at the end. A window will open with a MSYS2 terminal.
- The ESP-IDF repository on github contains a script in the tools directory titled
windows_install_prerequisites.sh
. If you haven’t downloaded the ESP-IDF yet, that’s OK – you can just download that one file in Raw format from here. Save it somewhere on your computer. - Type the path to the shell script into the MSYS2 terminal window. You can type it as a normal Windows path, but use forward-slashes instead of back-slashes. ie:
C:/Users/myuser/Downloads/windows_install_prerequisites.sh
. You can read the script beforehand to check what it does. - If you use the 201602 MSYS2 installer, the first time you run
windows_install_prerequisites.sh
it will update the MSYS2 core system. At the end of this update, you will be prompted to close the MSYS2 terminal and re-open. When you re-open after the update, re-runwindows_install_prerequisites.sh
. The next version of MSYS2 (after 201602) will not need this interim step. - The
windows_install_prerequisites.sh
script will download and install packages for ESP-IDF support, and the ESP32 toolchain.
Note: You may encounter a bug where svchost.exe uses 100% CPU in Windows after setup is finished, resulting in the ESP-IDF building very slowly. Terminating svchost.exe or restarting Windows will solve this problem.
Another Alternative Step 1: Just download a toolchain
If you already have an MSYS2 install or want to do things differently, you can download just the toolchain here:
https://dl.espressif.com/dl/xtensa-esp32-elf-win32-1.22.0-59.zip
If you followed one of the above options for Step 1, you won’t need this download.
Important: Just having this toolchain is not enough to use ESP-IDF on Windows. You will need GNU make, bash, and sed at minimum. The above environments provide all this, plus a host compiler (required for menuconfig support).
Step 2: Getting the esp-idf repository from github
Open an MSYS2 terminal window by running C:\msys32\msys2_shell.cmd
. The environment in this window is a bash shell.
Change to the directory you want to clone the SDK into by typing a command like this one: cd "C:/path/to/dir"
(note the forward-slashes in the path). Then type git clone --recursive https://github.com/espressif/esp-idf.git
If you’d rather use a Windows UI tool to manage your git repositories, this is also possible. A wide range are available.
NOTE: While cloning submodules, the git clone
command may print some output starting ': not a valid identifier...
. This is a known issue but the git clone still succeeds without any problems.
Step 3: Starting a project
ESP-IDF by itself does not build a binary to run on the ESP32. The binary “app” comes from a project in a different directory. Multiple projects can share the same ESP-IDF directory on your computer.
The easiest way to start a project is to download the Getting Started project from github.
The process is the same as for checking out the ESP-IDF from github. Change to the parent directory and run git clone https://github.com/espressif/esp-idf-template.git
.
IMPORTANT: The esp-idf build system does not support spaces in paths to esp-idf or to projects.
Step 4: Configuring the project
Open an MSYS2 terminal window by running C:\msys32\msys2_shell.cmd
. The environment in this window is a bash shell.
Type a command like this to set the path to ESP-IDF directory: export IDF_PATH="C:/path/to/esp-idf"
(note the forward-slashes not back-slashes for the path). If you don’t want to run this command every time you open an MSYS2 window, create a new file in C:/msys32/etc/profile.d/
and paste this line in – then it will be run each time you open an MYS2 terminal.
Use cd
to change to the project directory (not the ESP-IDF directory.) Type make menuconfig
to configure your project, then make
to build it, make clean
to remove built files, and make flash
to flash (use the menuconfig to set the serial port for flashing.)
If you’d like to use the Eclipse IDE instead of running make
, check out the Eclipse setup guide in this directory.
Finding A Project
As well as the esp-idf-template project mentioned in the setup guide, esp-idf comes with some example projects in the examples directory.
Once you’ve found the project you want to work with, change to its directory and you can configure and build it:
Configuring your project
make menuconfig
Compiling your project
make all
… will compile app, bootloader and generate a partition table based on the config.
Flashing your project
When make all
finishes, it will print a command line to use esptool.py to flash the chip. However you can also do this from make by running:
make flash
This will flash the entire project (app, bootloader and partition table) to a new chip. The settings for serial port flashing can be configured with make menuconfig
.
You don’t need to run make all
before running make flash
, make flash
will automatically rebuild anything which needs it.
Compiling & Flashing Just the App
After the initial flash, you may just want to build and flash just your app, not the bootloader and partition table:
make app
– build just the app.make app-flash
– flash just the app.
make app-flash
will automatically rebuild the app if it needs it.
(There’s no downside to reflashing the bootloader and partition table each time, if they haven’t changed.)
The Partition Table
Once you’ve compiled your project, the “build” directory will contain a binary file with a name like “my_app.bin”. This is an ESP32 image binary that can be loaded by the bootloader.
A single ESP32’s flash can contain multiple apps, as well as many different kinds of data (calibration data, filesystems, parameter storage, etc). For this reason a partition table is flashed to offset 0x4000 in the flash.
Each entry in the partition table has a name (label), type (app, data, or something else), subtype and the offset in flash where the partition is loaded.
The simplest way to use the partition table is to make menuconfig
and choose one of the simple predefined partition tables:
- “Single factory app, no OTA”
- “Factory app, two OTA definitions”
In both cases the factory app is flashed at offset 0x10000. If you make partition_table
then it will print a summary of the partition table.
For more details about partition tables and how to create custom variations, view the docs/partition-tables.rst
file.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 |
V1.0 Release notes This release contains many new components and improved functionality: Improved partition APIs, allowing read/write/erase/mmap on a partition Drivers: RMT driver UART driver PulseCounter driver Ethernet driver (beta) Timer Group driver Added in-tree examples for various esp-idf features FreeRTOS: Backported the static allocation feature from v9.0 FreeRTOS: Task unblocking on other CPU now happens instantaneously BLE/WiFi coexistence support Support for deep sleep wakeup stub Added task and interrupt watchdogs Virtual filesystem APIs OTA core APIs Secure Boot support (developer testing mode) WPS support WPA2 Enterprise support DTIM Sleep support Pass WFA 11n\WPS\WPA2 Enterprise certification BLE Host support (beta) Ethernet support LwIP OpenSSL API for MbedTLS Doxygen and ReadTheDocs-style documentation Known issues and missing features Build system and tools ESP-IDF can only be used when cloned as git repository. Downloaded .zip archive is not functional because it doesn't contain submodule dependencies. On Windows, Eclipse may not be able to index the project correctly. Windows installation package (MSYS + toolchain) doesn't provide pre-built OpenOCD. Bootloader, FreeRTOS, and SoC functions System configuration defaults to single core mode. Dual core mode is supported, but is set in the configurartion menu under "Components -> FreeRTOS -> Run FreeRTOS Only On First Core". CPU frequency can only be set at compile time. Changing CPU frequency at runtime requires some changes in FreeRTOS, which are not done yet. All of the following libraries are now placed into IRAM: FreeRTOS, libphy, librtc, libpp, libhal. This causes excessive usage of IRAM. Parts of these libraries may be safely moved into flash. 2nd stage bootloader does not verify MD5 signature of loaded application. Not all flash chips which support QIO can currently be used in QIO mode. This will be fixed either by adding extra logic to the 2nd stage bootloader, or by adding extra flash configuration commands using esptool. As a workaround, select DIO mode in menuconfig. Not all flash chips which support 80M clock can currently be used in 80M clock mode. This will be fixed by adding extra information to 2nd stage bootloader binary and changing SPI Flash library. As a workaround, select 40M clock mode in menuconfig. GDB stub works only in post-mortem mode Using floating point calculations is not compatible with tasks that have no affinity. Tasks without affinity that use the FPU will be automatically pinned to one of the two CPUs. Using floating point calculations in an interrupt handler can lead to a double exception. WiFi and BT WiFi DTIM sleep is not supported in WiFi/BLE coexistence mode WiFi DTIM sleep doesn't reduce the CPU Frequency WiFi throughput is not optimized yet BT host stack is not supported yet Other components SPI flash APIs work only with the main flash chip, and can not work with flash chips connected to other SPI buses. C library functions which read from stdin are not connected to UART yet. LwIP stack uses task local storage to store an extra per-task mutex. Although LwIP does support IPv6, DHCP server and DHCP client don't support IPv6 yet. System_event events related to DHCP also don't support IPv6 yet. v0.9 Release notes New features and components This release contains initial versions of the following components: ESP-IDF makefile system, described in docs/build_system.rst. FreeRTOS 8.2 with SMP support added. Also per-task local storage APIs have been backported. SMP port is described in components/freertos/readme_smp.txt. Second stage bootloader Newlib 2.2.0, parts of which are in ESP32 ROM SPI Flash read/write/erase APIs Partition table generation tool Binary image generation and flashing tool, esptool.py Expat XML parse library, version 2.2.0 cJSON library logging library LwIP stack, version 1.5.0(bf7fc41e) mbedTLS library, version 2.3.0 nghttp library, version 1.14.0(a3d22b6d) Non-volatile storage (NVS) library WiFi stack ESP-TOUCH supported QoS supported TX AMPDU supported RX AMPDU supported HT40 supported Bluetooth controller Bluetooth dual mode Virtual HCI BQB qualified Deep sleep flow Known issues and missing features Build system and tools ESP-IDF can only be used when cloned as git repository. Downloaded .zip archive is not functional because it doesn't contain submodule dependencies. On macOS, menuconfig build system may not be able to detect location of ncurses and gettext. On Windows, Eclipse may not be able to index the project correctly. Windows installation package (MSYS + toolchain) doesn't provide pre-built OpenOCD. Configuration of OTP bits using host tools is not implemented. Bootloader, FreeRTOS, and SoC functions CPU frequency can only be set at compile time. Changing CPU frequency at runtime requires some changes in FreeRTOS, which are not done yet. No mechanism exists to automatically allocate CPU interrupt numbers. Developers should assign CPU interrupt numbers manually based on the table in soc/soc.h. All of the following libraries are now placed into IRAM: FreeRTOS, libphy, librtc, libpp, libhal. This causes excessive usage of IRAM. Parts of these libraries may be safely moved into flash. 2nd stage bootloader does not verify MD5 signature of loaded application. Not all flash chips which support QIO can currently be used in QIO mode. This will be fixed either by adding extra logic to the 2nd stage bootloader, or by adding extra flash configuration commands using esptool. As a workaround, select DIO mode in menuconfig. Not all flash chips which support 80M clock can currently be used in 80M clock mode. This will be fixed by adding extra information to 2nd stage bootloader binary and changing SPI Flash library. As a workaround, select 40M clock mode in menuconfig. GDB stub works only in post-mortem mode Using floating point calculations is not compatible with tasks that have no affinity. Tasks without affinity that use the FPU will be automatically pinned to one of the two CPUs. FreeRTOS is pre-emptive, but not across CPUs yet. If a task on one core wakes up a task on the other CPU (eg by pushing something into an empty queue that the other process is receiving from), it will take until the next FreeRTOS tick until the other process wakes up. (In the default configuration, this means a delay of at max 1ms.) Processes running on the same core will not have this problem. WiFi and BT WiFi DTIM sleep is not supported yet WiFi throughput is not optimized yet WiFi WPA2-Enterprise and WPS are not supported yet WiFi and BT stacks do not coexist yet BT/BLE host stack is not supported yet Other components SPI flash APIs work only with the main flash chip, and can not work with flash chips connected to other SPI buses. Partition table APIs are missing. OTA update APIs are missing. C library functions which read from stdin are not connected to UART yet. API layer for integrating filesystem support into C library is missing. For each FreeRTOS task which uses printf/fprintf family of functions, three FILE structures are created (stdin, stdout, stderr). This causes excessive memory usage. LwIP stack uses task local storage to store an extra per-task mutex. Although LwIP does support IPv6, DHCP server and DHCP client don't support IPv6 yet. System_event events related to DHCP also don't support IPv6 yet. BIGINT locking functions (esp_mpi_acquire_hardware, esp_mpi_release_hardware) are not exposed publicly yet. Drivers (GPIO, LEDC) use custom logging macros instead of log library. Non-volatile storage library (NVS) doesn't get its layout configuration from partition table, instead it uses fixed layout. NVS can not use encrypted flash yet. Secure boot and flash encrypt are not supported yet. OpenSSL APIs upon mbedTLS are missing. Obtaining the v0.9 release As mentioned before, the source files attached to this release wil not work due to our use of git submodules. To get this release, use the following commands: git clone https://github.com/espressif/esp-idf.git esp-idf-v0.9 cd esp-idf-v0.9/ git checkout v0.9 git submodule init git submodule update |
Download ESP32 Espressif SDK @ GitHub
[#/esp/sdk/esp32″ ]