Work project has involved deep work within the ESP-IDF and a lot of C++ extensions, and alongside the code i'm developing... feelings.
ESP-IDF started out "hey, this isn't so bad" and "wow, they've done some clever things in here", but I think the honeymoon phase is over. We've run into SEVERAL nasty, fresh bugs in peripheral drivers. This chipset has been out a long time, how are they not really getting I2C right?!? Disconcertingly unstable given how much seems to be increasingly built on it.
And C++ extensions (C++20 and later)... This has been my first exposure to a lot of the stuff they've been adding to the C++ STL. Not sure i'm a fan of a lot of these design patterns. Probably half of what i'm butting heads against is probably my own resistance to change, but I really find the readability going out the window.
Pretty wild that i'm often needing to static_cast<std::underlying_type<ENUM>>(ENUM:VALUE). This, uh, used to be much simpler.
Also, for this example of a templated i2c register write function that works on scoped enums - I guess the most valid question here would be "why are we forcing scoped enums in the first place?" But also - why is the validation on whether or not the input enum is scoped occurring in the type signature of the return? That's weird, right?
I'm also torn because "auto" is both a convenience and a goddamn plague
@tobyjaffey Yeah, i'm also a Nordic fanboy, I have a soft spot for the design of that SDK (not Zephyr though, but that's a whole other pandoras box).
So far we've been able to work through each of our ESP-IDF issues, they haven't been silicon but driver bugs. Honestly the drivers seem much more complex then they need to be... We're also using their esp_modem stack which is... fun.
For some projects, if this is the pain i'll need to endure to keep the BOM cost low, I might still go through it.
Andrew Tergis
Toby Jaffey