Gripes on ESP32/ESP-IDF

[michprev]

https://github.com/espressif/esp-idf/issues/2738

Now take a look at this issue. It is present in v3.1 release even in master branch at the moment.
Because of that assert SPI driver fails whenever trying to use it in DIO/QIO mode. Does it seem like a minor issue to you? This bug exists there over the year now.

[p-rimes]

I can't speak to the hardware (I'll be honest -- I've had some flakiness with the radio, and I2C), but if you don't like esp-idf FreeRTOS, there is Amazon FreeRTOS (the current maintainer of the official FreeRTOS project), with ESP32 Espressif DevKit as a primary target they have selected.

Support for a Bluetooth-only access to AWS resources (via a ESP32<->mobile app) was one of the headline announcements of the recent AWS re:Invent 2018 conference:
https://aws.amazon.com/about-aws/whats- ... e-in-beta/
https://aws.amazon.com/blogs/iot/using- ... sif-esp32/

Do note that, without the espressif patches for multi-core, this will only use a single ESP32 core for the RTOS.

Sincerely interested in your thoughts, if this changes your perception of the reliability of the ESP32.

[PeterR]

Hey,
Would you attach a list of GitHub 'unreliable ESP hardware' issues, such that we may all look for solutions?
I am not aware of any HW bugs. Some SW bugs but no show stoppers for me yet (firmly grasps wooden desk).
I am only prototyping but I soak test each driver.
So far I have BLE, Wifi, V/HSPI and PSRAM/FLASH, SD(HSPI), Ethernet playing nice from 0 in 4 months. I'm happy.
My only 'complaint' would be a clear race error in 3.1 SPI driver (seems fixed in 3.2 beta).
I have used PIC, ARM, AVR in last 4 years and debugged each library so I think any bugs are par for the course.
For me the key point is that all this stuff (unlike many) is Apache open source - dive in, if it does not work for ya then you can jump ship!

[Bhanuka92]

There industrial controllers designed with ESP32 as the processor and making its GPIO and functions ready for industrial conditions. It is programmable with arduino IDE and has mini usb connectivity. You can check details at www.norvi.lk
I have used NORVI IIOT ESP32 for many industrial applications.

[username]

There industrial controllers designed with ESP32 as the processor and making its GPIO and functions ready for industrial conditions. It is programmable with arduino IDE and has mini usb connectivity. You can check details at www.norvi.lk
I have used NORVI IIOT ESP32 for many industrial applications.

Is this a gripe?

[aknabi]

The chip and firmware may be "fine", but even now in 2021 the ESP-IDF and software eco-system has to be the biggest pile of crap I've encountered in 40+ years of software engineering... projects more than a few weeks old run the risk of not building anymore... tools just don't work... a project that builds fine on the latest with VS-Code doesn't build with idf.py... on and on... I've done 5 serious projects on the ESP32 and in each case about 90% of the effort is trying to figure out how esp-idf has changed or screwed up or is buggy... use another library? Expect to do as much work to get it running as having written it yourself.

Examples... I have perfectly valid code that compiles and runs great on PlatformIO... but for CI need esp-idf... same code barfs on some structs and need to use useless indirection and refactored with complexity and potential defects to make esp-idf happy... don't even get me started on app_main not found. Basically every project is a bunch of duct tape that only the developer who did it can maintain... when a new developer comes in you'll end up with another layer of crap on your crap lasagna project.

In the end a consumer products company I work with decided to abandon the effort to move to ESP32... yes the chips were cheaper... but the software quality would have been crap, and the cost of development increased by 5-10x making the actual ESP32 cost around 4x a Nordic/Dialog/NXP solution (and they're expensive solutions).

Frankly the ESP32 is not only NOT for production products, it's not even for hackers... it's for masochists that want to be whipped by their tools and platforms vs. actually building anything (beyond throw away blinking LED projects)... or for folks that just look at hardware component costs for a product and hire cheap coders to bang on keyboards until it builds and runs regardless of quality.

This may sound harsh, but if Espressif is serious they'll clean up their software mess... frankly they need to basically start from the ground up with ESP-IDF... no top-tier developer would consider this any sort of foundation

[ESP_Angus]

Hi aknabi,

I'm sorry you've had such a frustrating experience with ESP-IDF so far. I'm hoping we can help resolve some of these problems.

projects more than a few weeks old run the risk of not building anymore... tools just don't work... a project that builds fine on the latest with VS-Code doesn't build with idf.py... on and on... I've done 5 serious projects on the ESP32 and in each case about 90% of the effort is trying to figure out how esp-idf has changed or screwed up or is buggy...

Do you mean things break when you update ESP-IDF, or are you finding code in your project breaks without updating ESP-IDF? For low risk updates of ESP-IDF, we recommend working with stable releases instead of the ESP-IDF master branch. We try very hard not to break compatibility between releases (following Semantic Versioning, and if there are unavoidable breaking changes we note them in the release notes). We try also not to break things on master branch, but there are occasional regressions. There is a trade-off between updating fast (bleeding edge, master branch) and updating slow (stable releases). The link to the docs above has some more info about it.

If you find something breaks on ESP-IDF master branch and it looks like a breaking change in ESP-IDF, please open a GitHub issue to let us know about it.

Examples... I have perfectly valid code that compiles and runs great on PlatformIO... but for CI need esp-idf...

I took a quick look at what I'm guessing is the project you're referring to (looks like a really neat project, BTW!) The build is failing here with:

Code: Select all

CMake Error at /opt/esp/idf/tools/cmake/component.cmake:305 (message):
  Include directory '/github/workspace/components/wifi/include' is not a
  directory.

The project has a "wifi" component that tells the build system to add an "include" directory, but the "include" directory is not in the repo so it's not found when CMake goes to build it in CI:
https://github.com/aknabi/smalltalkje/b ... sts.txt#L5

I'm guessing this directory exists on your local computer, which is why the build is happy there.

One way to fix this is to remove the "placeholder" CMakeLists.txt file from this otherwise empty component, and re-add it when adding this functionality back.

same code barfs on some structs and need to use useless indirection and refactored with complexity and potential defects to make esp-idf happy... don't even get me started on app_main not found.

I'm not sure what this is, but I'd like to help you fix it - and to also fix any regression in ESP-IDF if that's what has caused it. If you want to start another thread with more details, then very happy to take a look.

EDIT: One thing that may be relevant, it seems like platform.io encourages using SRC_DIRS in ESP-IDF CMakeLists.txt files. This is discouraged in ESP-IDF (because it's also discouraged in CMake itself), in favour of listing the source file names with SRCS. The ESP-IDF examples and internal components use SRCS not SRC_DIRS for this reason. Using SRC_DIRS, you may find that new source files in the project aren't immediately built by ESP-IDF unless you force a clean build (possibly platform.io has added a workaround for this, I don't know.)

[Vader_Mester]

The chip and firmware may be "fine", but even now in 2021 the ESP-IDF and software eco-system has to be the biggest pile of crap I've encountered in 40+ years of software engineering... projects more than a few weeks old run the risk of not building anymore... tools just don't work... a project that builds fine on the latest with VS-Code doesn't build with idf.py... on and on... I've done 5 serious projects on the ESP32 and in each case about 90% of the effort is trying to figure out how esp-idf has changed or screwed up or is buggy... use another library? Expect to do as much work to get it running as having written it yourself.

Examples... I have perfectly valid code that compiles and runs great on PlatformIO... but for CI need esp-idf... same code barfs on some structs and need to use useless indirection and refactored with complexity and potential defects to make esp-idf happy... don't even get me started on app_main not found. Basically every project is a bunch of duct tape that only the developer who did it can maintain... when a new developer comes in you'll end up with another layer of crap on your crap lasagna project.

In the end a consumer products company I work with decided to abandon the effort to move to ESP32... yes the chips were cheaper... but the software quality would have been crap, and the cost of development increased by 5-10x making the actual ESP32 cost around 4x a Nordic/Dialog/NXP solution (and they're expensive solutions).

Frankly the ESP32 is not only NOT for production products, it's not even for hackers... it's for masochists that want to be whipped by their tools and platforms vs. actually building anything (beyond throw away blinking LED projects)... or for folks that just look at hardware component costs for a product and hire cheap coders to bang on keyboards until it builds and runs regardless of quality.

This may sound harsh, but if Espressif is serious they'll clean up their software mess... frankly they need to basically start from the ground up with ESP-IDF... no top-tier developer would consider this any sort of foundation

I'm sad to read you had such a terrible experience. I think IDF is a great system, it is maintained well, and it is extremelly easy to work with - when it actually works - I remember deving some stuff with IDF back in v3.1 with Eclipse. Now on VSCode I can not imagine ever going back.

That said, I can not complie at the moment, after having the IDF updated, stuff broke and complie stops at some random FreeRTOS stuff, but I'm sure I'll be able to fix it and learn valuable lessons along the way.

[ESP_Angus]

Hi Vader Mester,

I'm sad to read you had such a terrible experience. I think IDF is a great system, it is maintained well, and it is extremelly easy to work with - when it actually works - I remember deving some stuff with IDF back in v3.1 with Eclipse. Now on VSCode I can not imagine ever going back.

Can you make a new thread with the details about this, please? Assuming you didn't update from a very old IDF version, we updated from FreeRTOS 8 to FreeRTOS 10 in ESP-IDF v4.3 but I don't think any breaking changes are expected.

[Vader_Mester]

Hi Vader Mester,

I'm sad to read you had such a terrible experience. I think IDF is a great system, it is maintained well, and it is extremelly easy to work with - when it actually works - I remember deving some stuff with IDF back in v3.1 with Eclipse. Now on VSCode I can not imagine ever going back.

Can you make a new thread with the details about this, please? Assuming you didn't update from a very old IDF version, we updated from FreeRTOS 8 to FreeRTOS 10 in ESP-IDF v4.3 but I don't think any breaking changes are expected.

Yes, I will.