The old esp32 -factory stuff along with the lws support doesn't have a
future in its old form. It has users but the ratio of effort to
contribution is really especially bad. I haven't updated it for more
than a year since esp-idf changes broke the original stuff.
Freertos plat is alive and well and getting a lot of new use, ESP-32 is
supported both there and by modern lws_drivers pieces, including in CI
on real hardware, any further effort will be invested in that direction
instead of more vendor api-specific code (outside of wrapper
implementation).
lws_drivers wraps any SDK apis in generic lws apis such that your code
just uses those, enabling it to become SDK / SoC / vendor independent.
Its first implementation is on esp-idf, the low and mid-level features
that were in the old -factory are already available using that and
new technologies like lws_struct and Secure Streams.
Add lws_display and minimal example support for esp32-wrover to match wsp32-heltec-wb32
Since no usable buttons that don't affect something else on wrover kit, assumes
a button to 0V on GPIO14.
Make a start on generic peripheral and bus drivers to provide
meta-functionality regardless of platform.
On the one hand this simply provides...
- bitbang i2c on top of esp-idf gpio apis
- ssd1306 oled chip driver as found on Heltec WB32
- modifications to the minimal example test for esp32 to use that
... on the other hand, those capabilities are provided by creating:
- an abstract i2c class object
- an abstract gpio class object
- i2c class implementation using the abstract gpio for bitbang
- an abstract display class object
- an abstract display state (brightness, animated change,
on/off/init tracking, autodim after inactive, auto-off /
blanking after inactive)
... with the intention, eg, you only have to add a platform
implementation for the gpio to be able to use the i2c-based
display drivers and state handling, and i2c bitbang, without
any other modifications.
