Is this library ready for use?

[geniusC]

I found your st7789 related submission in ucglib. and I transplanted it to the nodemcu board. But I found that there is no image-related api, this library is to add related features?

[fornellas]

@geniusC I've been hitting the limits of ucglib's architecture / features several times (see my recent PRs there), and the author was clear he's not actively maintaining it. ucglib's graphics primitives are awesome, but it seems its internals didn't age well, and could use an overhaul. So, I'm experimenting here with eglib.

I just pushed the first working example: if you want to poke at https://github.com/fornellas/eglib/tree/master/examples/libopencm3/stm32f4_st7789. It is already working faster than ucglib (see this issue).

The initial POC works. The current HAL / display driver interface is defined here https://github.com/fornellas/eglib/blob/master/src/eglib.h. Note how both the HAL / Display driver can have configuration attached to them, so one can give the pins for the HAL or the display dimensions, and things work, without requiring to copy / pasta driver for each project.

I managed to write a small unit test for the graphic primitive as well: https://github.com/fornellas/eglib/tree/master/tests/drawing. I want to do the same for display drivers, so the codebase can grow sustainably.

There are some things I still want to improve at the architecure:

• Have specific HAL interfaces for each interface type:
  • 4-wire SPI
  • 3-wire SPI
  • I2C
  • 6800 Parallel
  • 8080 Parallel
• Have specific display driver interface for usage with each HAL interface
  • Display drivers can share most code among them, but only have shallow layers to deal with differences between HALs.
  • Eg: SSD1306 encodes data/command information at some I2C bits, but uses the DC line with SPI.
  • Have relevant bus information to be shared with HAL (clock timing, SPI characteristics).
• Define interface for frame buffer.
  • This interface should support transfers with DMA as well.
    • This requires the display driver to control exactly the bits in memory and how to ask the HAL to DMA them out.
  • The hacky frame buffer I did for ucglib keeps an RGB frame buffer, which the display driver can't see, so no DMA. Also, if the display driver is 12bit color, no point in storing 24bit in memory.
• Support multiple color bit depths
  • While the lib core can deal with RGB, the display drivers should be able to use different depths, including those black-white-red from e-ink displays.
• Import graphics functions from ucglib.

If you feel like collaborating on this next-gen lib let me know, there's plenty of work to do and support is very much welcome!

[geniusC]

that's so cool, i'm looking forward to this library work well.I also want to make some contributions, but my work is too busy.

[fornellas]

@geniusC I think I wrapped up the API for both HAL & display:

https://github.com/fornellas/eglib/blob/master/examples/libopencm3/stm32f4_st7789/main.c

Both HAL & Display drivers accept configurations, enabling both to share code for different configs, and avoid some copy / pasta that's needed with ucglib. Eg: the same display controller can be used with physical screens of different resolutions, the ST7789 driver accepts this resolution as a configuration.

I also embedded the BUS configuration (eg: SPI mode, timings etc) as part of the display driver definition, but keeping both 100% decoupled.

I appreciate if you can have a look in general, and give feedback if you think this is sound. Thanks in advance!