This is the SPI client chip in the LCD displays on ESP32 WROVER-KIT and S2
Kaluga.
Adapt it to allocate using DMA-able allocators and to use the new blit op
conventions for update sequencing
This provides an alternative esp32-specific SPI driver with ops that can be
swapped in place of the gpio bitbang one.
The pinmux info and lws gpio driver and other data in the spi bitbang
struct are used as-is by the DMA one.
New ops are provided which are able to allocate and free DMA-able memory so
the device drivers can prepare directly usable buffers. Bounce through to
DMA-able buffers is also transparently supported.
This adds optional display list support to lws_display, using DLOs (Display
List Objects). DLOs for rectangle / rounded rectangle (with circle as the
degenerate case), PNGs, JPEG and compressed, antialiased bitmapped fonts
and text primitives are provided.
Logical DLOs are instantiated on heap and listed into an lws_display_list
owner, DLOs handle attributes like position, bounding box, colour +
opacity, and local error diffusion backing buffer.
When the display list is complete, it can be rasterized a line at a time,
with scoped error diffusion resolved, such that no allocation for the
framebuffer is required at any point. DLOs are freed as the rasterization
moves beyond their bounding box.
Adds a platform registry binding names and other metadata to lws_display
fonts / PNGs / JPEGs. Provides registration, destruction and best match
selection apis.
Before this commit, line 84 read 'u' before it had a value, on 1st for-loop iteration. See comment on line 84 below:
82 for (n = 0; n < 8; n++) {
83 ctx->gpio->set(ctx->clk, inv);
84 u = (u << 1) | !!ctx->gpio->read(ctx->miso); /* <-- u is used uninitialized here */
85 ctx->gpio->set(ctx->mosi, !!(u & 0x80));
86 ctx->gpio->set(ctx->clk, !inv);
87 }
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.
Now there's an abstract button class regardless of the underlying
connection, we can add more sophicsticated analysis on top of it
for processing its usually noisy events and classifying them into
smd-ready click, long-click or double-click events.
A "regime" defines the timing limits for different press recognition
and can be specified per-button, if not given a default regime is
applied.
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.
