[ESP-IDF RELEASE] esp-idf v0.9 for ESP32 development

[ESP_Sprite]

Hi all,

As you probably have seen, with the development of esp-idf we have changed over to pushing changes to our internal development tree out to the public as soon as possible. This means everyone using esp-idf can get all the latest features and bugfixes using a single 'git pull'. This, however, also means everyone can get all potential new bugs, code-breaking API changes etc via one single 'git pull'.

We understand that for production, there is a requirement for stability. That is why we will periodically have releases. These releases will have a stable API and feature set; we will backport bugfixes to them if we find any.

The release notes for the first release, v0.9, can now be found at:
https://github.com/espressif/esp-idf/releases

Two words of warning:
-First of all, as you may have seen, this is not version 1.0 yet. We reserve the right to change some of the APIs present in v0.9 drastically, without a fallback. (We do not have concrete plans to do this with any of the APIs at this point in time, but that may change.)
- Second of all, please do not be tempted by the downloads listed on the release page: due to our use of Git submodules, they do not work. The way to get this release is:

Code: Select all

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


[MarsWarrior]

Nice!

I had problems compiling some of the examples. Will check if v0.9 solves this problem.

[WiFive]

Eagerly awaiting for ADC/DAC/TOUCH/RTC/LPC code & docs.

Maybe the esp31 topics can be moved to esp31 archive folder?

[WiFive]

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.

Any way we could get public tracking on these issues?

[ESP_igrr]

Any way we could get public tracking on these issues?

What are your expectations from public tracking of these? Do you want to have timelines/milestones assigned to these, or do you want to see actual development process (comments, commits, etc.)?

[kolban]

I for one am a loyal Espressif "fan boy" ... however in my fantasy world of ESP-IDF design/development, I'd love to see extreme transparency and the opportunity for the community to be involved at any and all points. I'd publish the approximate timelines and road-maps for the components. I'd publish the "planned content" ... for example, if we are exposing new APIs or libraries, I'd put those forward for review and consideration.

Maybe if we itemize the major components we could create a forum thread for each one to separate, capture and discuss the distinct areas.

Again ... this might be overkill ... but it would be my ideal.

[jimbob]

I can see what you mean -- I'd find it useful to know if it was worth me writing a library, or waiting another couple of months for one which is currently in testing!

I can appreciate it's hard to run a project like this and expose that information -- and not have people complain when the project invariably slips/changes!

[WiFive]

Any way we could get public tracking on these issues?

What are your expectations from public tracking of these? Do you want to have timelines/milestones assigned to these, or do you want to see actual development process (comments, commits, etc.)?

Yes timelines/milestones/priorities would be nice, but really just to be aware of all of them and when they are resolved, in one place. It is ok if some/most of the development and discussion is done privately, as long as they are updated with relevant public commits/merges.

A lot of these issues are relatively minor, but others have major impact on product use cases and implementations. Some issues are not listed such as spiram cache support.

Also it will allow users to comment on which issues are important to them, share temporary workarounds, or make contributions. And that can in turn motivate the development team.

[ESP_igrr]

Thanks to everyone for input.

I have to say that synchronizing our internal issue tracking and code review tools with github would add quite a bit of complexity to the workflow. If we have two comment threads for any given issue (one internal, one at github), it will be pretty hard to keep track and update both. Same goes for code review — using both our internal tool and github PRs can be complicated for any non-trivial change. The fact that github is not always accessible from China also doesn't help.

On the other hand i do agree that we need some degree of transparency with regards to features, roadmaps, proposed APIs, and so on. I will discuss this with the team after the holidays. Maybe we can improve the situation by maintaining a kanban board for major features, and creating PRs for public review of new APIs.