Gripes on ESP32/ESP-IDF

[michprev]

Again and again...

Not only that your hardware is badly designed. You don't even know how to test it and how to write drivers for it. (And your docs are incomplete too)

2 years on the market and your SPI drivers are still not working.
2 years on the market and you still don't know about all HW issues in SPI.

I don't think there is an excuse for it. As I said in the first post I strongly believe that ESP32 is not ready for production.

[Vader_Mester]

Again and again...

Not only that your hardware is badly designed. You don't even know how to test it and how to write drivers for it. (And your docs are incomplete too)

2 years on the market and your SPI drivers are still not working.
2 years on the market and you still don't know about all HW issues in SPI.

I don't think there is an excuse for it. As I said in the first post I strongly believe that ESP32 is not ready for production.

I think the ESP32 was the labrat or testbech for Espressif, to test FreeRTOS, dual cores, and external RAM, as well as new preripherals.

There is a funny/ironic analogy between Espressif products and Windows versios:

8266 -> Windows 7: This actually worked, and kind of still used in many many places, and some still do not want to updgrade it.
ESP32 -> Windows 8: Too much new stuff, great new ideas, but not put together very well full of bugs, not quite there.
Next ESP -> Win 10 - This is at least should work, learning from previous mistakes, and should evolve constantly.

[michprev]

I think the ESP32 was the labrat or testbech for Espressif, to test FreeRTOS, dual cores, and external RAM, as well as new preripherals.

There is a funny/ironic analogy between Espressif products and Windows versios:

8266 -> Windows 7: This actually worked, and kind of still used in many many places, and some still do not want to updgrade it.
ESP32 -> Windows 8: Too much new stuff, great new ideas, but not put together very well full of bugs, not quite there.
Next ESP -> Win 10 - This is at least should work, learning from previous mistakes, and should evolve constantly.

I guess we can only hope that the next ESP will not be that buggy. But I am afraid that nothing will change from software / documentation side. IMHO ESP-IDF is just terribly written. There are so many bugs (not matter in release or master branch) that you should never ever make a commercial product based on ESP32 (or at least not while using ESP-IDF). If you really want to use ESP32 you have to write your own SDK. There are 2 problems:

• you have to use WiFi driver from Espressif that will be very probably buggy
• the docs are very incomplete, some hardware bugs are not even mentioned there

So for me this is not only a hardware problem.

[username]

I was reading through this today. I have to say I have never used the 8266. I started out with the ESP32 about 6 months ago.
I have prototyped many things with it over this time, using uSD, SPI (peripherals and 5" TFT LCD's) & I2C extensively. Even adding Ethernet capability to it. I have not run into one issue with it. It has been extremely helpful for them to have so meany examples to help one get the ball rolling when you are a bit confused with the docs.

I currently have 3 products that have been running 24/7 for 4 months now, and all of them have not had one hiccup or customer complaint. Sure, there are things that need to be addressed, but what chip manufacturer doesn't have an errata sheet?

I think most of the issues people have are due to a lack of understanding how to get their code to work in a RTOS environment.
About 10 years ago I was introduced to FreeRTOS, and yes it took some time to learn the proper way to get your code to work in that environment. There are allot of so and don't that one needs to learn about, and tricks to get around certain things. But once you take the time to lean it, I cannot see anyone ever going back to a non RTOS environment.

[loboris]

... If you really want to use ESP32 you have to write your own SDK...

Have you considered the possibility that the problem is at your side?

There are certainly bugs in esp-idf (as in any software), but from your posting one could conclude that it is completely unusable, something most users could not agree on.

[michprev]

Have you considered the possibility that the problem is at your side?

Sure, I have. But then I looked at other manufacturers solution and I can clearly say that the problem is not only me.

There are certainly bugs in esp-idf (as in any software), but from your posting one could conclude that it is completely unusable, something most users could not agree on.

It is unusable for me. I expect hardware drivers to be 100 % working. Have you looked into ESP-IDF code? This is how software really should not be written. Have you ever been working with different manufacturers SDK? Don't you see the difference?

[michprev]

I have prototyped many things with it over this time, using uSD, SPI (peripherals and 5" TFT LCD's) & I2C extensively. Even adding Ethernet capability to it. I have not run into one issue with it.

Then you are really a lucky man. While writing my own driver for SPI I have found several issues in ESP-IDF SPI driver. From github it seems that there are still issues with I2C.

Sure, there are things that need to be addressed, but what chip manufacturer doesn't have an errata sheet?

You are right. But this manufacturer does not put all hardware issues into the errata sheet. They know about them (from comments in ESP-IDF code) but still don't want to include them into errata.

I think most of the issues people have are due to a lack of understanding how to get their code to work in a RTOS environment.
About 10 years ago I was introduced to FreeRTOS, and yes it took some time to learn the proper way to get your code to work in that environment. There are allot of so and don't that one needs to learn about, and tricks to get around certain things. But once you take the time to lean it, I cannot see anyone ever going back to a non RTOS environment.

You are right, again. But what if RTOS does not work (https://github.com/espressif/esp-idf/issues/2233)?

[username]

Then you are really a lucky man. While writing my own driver for SPI I have found several issues in ESP-IDF SPI driver. From github it seems that there are still issues with I2C.

All i can say is that I am presently using 3 different I2C devices and I have not had one issue with communication using ESP-IDF. On the otherhand when I tried Arduino-IDF I did run into some problems using their driver.

You are right, again. But what if RTOS does not work (https://github.com/espressif/esp-idf/issues/2233)?

I have not had any issues wifi driver initialization, and I have not seen anyone else here have that issue.

I looked a little into your link and you code. I notice that in your UDP example is binding 2x which it should not.
You also do not have anything in you event handler, how are you to handle things without that ?
You also seem to love "assert" everything, why I am not sure.

I think you need to start with their examples and go from there. Your heavily modified changes seem to be more of the culprit in my opinion anyways. Start with the example "C:\msys32\home\Micono\esp\esp-idf\examples\protocols\sockets\udp_server\main" and see how things work.

[michprev]

You don't seem to understand the core of this issue but that is OK, I just wanted to illustrate that even Espressif FreeRTOS implementation is not correct (in fact I am quite curious where the issue excatly is).

I looked a little into your link and you code. I notice that in your UDP example is binding 2x which it should not.

One call for UDP binding, one for TCP binding.

You also do not have anything in you event handler, how are you to handle things without that ?

I don't need it. The example should show that higher priority task can get preempted by lower priority task (which is not correct) while using TCP/UDP connection.

You also seem to love "assert" everything, why I am not sure.

Why shouldn't I use it, especially in this case? We are observing here an issue (wrong preemption of tasks). We want everything other to work correctly.

I think you need to start with their examples and go from there. Your heavily modified changes seem to be more of the culprit in my opinion anyways. Start with the example "C:\msys32\home\Micono\esp\esp-idf\examples\protocols\sockets\udp_server\main" and see how things work.

Thank you, I've been working with ESP32 quite a while so I think that I usually know what I am doing. However if you see an issue in my code you can let me know.

[username]

One call for UDP binding, one for TCP binding.

I read the code to fast, my bad.

You don't seem to understand the core of this issue but that is OK, I just wanted to illustrate that even Espressif FreeRTOS implementation is not correct (in fact I am quite curious where the issue excatly is).

Quite possible. I just was amazed reading through this whole post and the complaints of it. One project I have 15 threads running. 2 of which are an AP to serve up a 1.2meg dynamic web site showing real time servo positions and sensor data, and the other is a Telnet server which updates to the user info 6x a second. With all these tasks doing their things talking to 4 I2C chips and 2 SPI chips without ever missing a beat I just find it weird that there is a serious problem with the RTOS.