Crash_Override/OVMS3-idf
1
0
Fork 0
Code Issues Pull requests Projects Releases Wiki Activity
Espressif IoT Development Framework. Official development framework for ESP32.
370 commits 10 branches 75 tags 114 MiB
C 91.5%
Python 3.7%
C++ 2.7%
CMake 0.7%
Assembly 0.5%
Other 0.7%
Go to file
Ivan Grokhotkov da69d6ad3c Merge branch 'master' into feature/menuconfig_cpu_frequency_option 
* master: (57 commits)
  components/lwip: fix grammar
  components/lwip: make SO_REUSE configurable via menuconfig
  bootloader: remove trailing newlines from log messages
  components/freertos: override per-task __cleanup handler to close stdin, stdout, stderr
  components/esp32: move peripheral symbols to separate ld script
  components/log: regroup macros for better readability
  gitlab-ci: allow running tests for branches, triggered via API
  components/log: fix timestamp calculation
  components/log: set default runtime log level to ESP_LOG_VERBOSE
  components/log: fix error when using ESP_LOGx from C++ code
  components/log: fix bugs, add options to override log level for files, components, and bootloader
  fix ledc and spi typo
  remove prefix and postfix
  Enable SO_REUSEADDR in LWIP
  freertos: fix memory debug macro issue Define configENABLE_MEMORY_DEBUG according to CONFIG_ENABLE_MEMORY_DEBUG
  peripheral structure headers: move volatile keyword from members to typedef
  Adding -fstrict-volatile-bitfields to the CFLAGS/CXXFLAGS. Without this, gcc tries to access bitfields using the smallest possible methods (eg l8i to grab an 8-bit field from a 32-bit). Our hardware does not like that. This flag tells gcc that if a bitfield is volatile, it should always use the type the field is defined at (uint32_t in our case) to size its access to the field. This fixes accessing the hardware through the xxx_struct.h headers.
  add peripheral  module struct headers
  build system docs: Add note about no spaces in component names
  Docs: Add note about unusual submodule messages when cloning on Windows
  ...

# Conflicts:
#	components/esp32/cpu_start.c
#	components/esp32/include/soc/cpu.h
2016-09-20 17:22:18 +08:00
components Merge branch 'master' into feature/menuconfig_cpu_frequency_option 2016-09-20 17:22:18 +08:00
docs build system docs: Add note about no spaces in component names 2016-09-16 18:22:16 +10:00
make Merge branch 'driver_merge_tmp/merge_struct_header' into 'master' 2016-09-19 15:34:37 +08:00
tools config system: Support Windows when CRLFs used for eol markers 2016-09-16 18:07:58 +10:00
.gitignore Initial public version 2016-08-17 23:08:22 +08:00
.gitlab-ci.yml gitlab-ci: allow running tests for branches, triggered via API 2016-09-18 23:12:50 +08:00
.gitmodules Load esptool.py from submodule, currently WIP esptool.py v2.0 2016-09-01 18:45:10 +10:00
add_path.sh add_path.sh: Use non-bash-specific instructions 2016-09-12 18:39:20 +10:00
Kconfig Standardise remaining uses of SDK to ESP-IDF 2016-08-19 15:01:15 +08:00
LICENSE Initial public version 2016-08-17 23:08:22 +08:00
README.md README: Add Resources section with some links 2016-09-08 13:41:19 +10:00

README.md

Using Espressif IoT Development Framework with the ESP32

Prerequisites

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.

Resources