Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

nit: There are 6 different espressif microcontrollers in that table, not "dozens".

Espressif also went many years with only the ESP8266, then many years more after introducing the ESP32 before this recent binge of releasing a new series every time they blink. ESP-IDF is really suffering for it, so I hope Raspberry avoid this fate or at least find a better way to support them all.



https://products.espressif.com/#/product-selector?language=e...

This is the official Espressif "ESP Product Selector". I checked everything in the ESP series, and limited to "Mass Production" status, and then it showed me a list of 175 products.

I'm sure some of those are doubled up, or just the same chip with different packaging options or whatever, but as a potential customer I'm still presented with 175 things and told to pick one.


Most of that are not bare microcontrollers (or “SoC”s as Espressif calls it), but entire modules with different combinations of SoC, Flash, PSRAM, antenna configuration and packaging. If you filter only SoCs, you get 39 products, which in fact are 9 different chips and rest are packaging variants and versions with package-on-package Flash.


Many of the variants listed are the same chip but with different amounts of storage, oboard vs external (vs both) options, etc.


Considering how many different Raspberry Pis are out there now, I wouldn't be surprised if the Raspberry Foundation makes a plethora of newer microcontrollers.


How is ESP-IDF "suffering for it"?


Complexity. It's now playing catch up trying to support all of these different chips with all of these different peripherals, capabilities, and errata in quick succession.

As a developer, it's much more difficult to navigate when there are 8 files with the same name, 5 registers with the same name defined in different files, etc. A lot of code is heavily punctuated by ifdefs to selectively include and exclude lines for different targets, making it more difficult to follow. Intellisense struggles, no matter how well it's configured.

I could deal with all that but it's the runtime cost that is the worst. ESP-IDF is constantly getting bigger and slower. All of these abstractions, structs half-full of pointers being handed about at runtime, dead code being linked in for features the chip doesn't even support, it all has a cost.

This is even worse in binary blobs where conditional compilation is more difficult to do. I'm not convinced they're even trying though. A single commit that only mentioned WiFi 6 changes increased my binary size by over 10kB. On a chip that doesn't support WiFi 6.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: