Monochrome Display OS Device

[Kevin Townsend <ke...@adafruit.com>]

tl;dr: Is there bandwidth and interest to collaborate on stubs for an 
os_dev based mono display driver, monogfx drawing package, and basic 
simulator/test-code, if I'm willing to fill some of the stubs and driver 
details in since I've written a lot of display drivers over the years?

Bloated version follows ...

Has anyone here made any effort to implement mono or RGB displays as a 
generic os_dev?

I've started working on a reference Mynewt app where I will use an 
inexpensive 128x32 pixel OLED display where the top 128x8 pixels are a 
status area controlled by the display task, containing info like the 
RSSI level, battery level, connection status, etc. The bottom 128x24 
pixels are accessible as a buffer that can be update in any other task 
handler to display context-specific information. I've attached a .md 
file with my initial thoughts on the display management task, just as a 
FYI. I'm writing it as a reference of how to handle pass events around 
between tasks, and how to organize tasks by priority level.

I'm happy to contribute a driver for the SSD1306 to Mynewt since the 
OLED displays that are it are affordable, compact, can be reliable 
sourced, and most of all are appropriate for small individual sensor 
nodes due to their size and readability.

This would be much better as an os_dev, though, based on a generic 
monochrome display, with a generic monogfx drawing library that can be 
used with it to handle basic drawing, rendering text, etc.

Monochrome displays should be separate devices from RGB displays, in my 
opinion, because they behave very differently:

Mono displays tend to be buffer based, where you have 1 bit per pixel in 
an appropriately sized buffer, and all drawing happens on that buffer. 
When you want to refresh the display, you read the buffer and dump the 
pixels to the display.

Inexpensive RGB displays tend to have internal memory buffers, and 
variable pixel color widths and structures (RGB16, RGB18, RGB24, 8-bit 
lookup tables). The R/G/B components can also change order depending on 
the display and controller. Different controllers also have different HW 
accelerated functions for drawing, and you need to design in the option 
to take advantage of these accelerated function, OR fallback to a purely 
SW based alternative when no HW option is present (fill screen, draw 
basic shapes, invert the display, etc.). The drawing library would be 
different enough that I think this should be a separate device type with 
a seperate drawing library ('rgbgfx'?)

Monochrome is a better place to start, though, since these are far more 
common in embedded systems, have faster updates, and are less expensive.

Is there any bandwidth at present for other Mynewt participants to scope 
out an os_dev based display and monogfx library following the ADC and 
sensor design pattern?

I can contribute some HW drivers (starting with the SSD1306), some basic 
monogfx drawing code (lines, shapes, text) and a socket-based display 
simulator, but I would prefer the generic os_dev API to be a 
collaborative effort since it would need to be maintained longer term.

For the simulator, this can be either based on writing timestamped image 
files directly to disk every time the display is refreshed, or I can 
make a socket based visual simulator that potentially also includes user 
feedback like simulating buttons or a touch screen, with the ability to 
export screen shots. I think having a simulator is worth the work since 
UI develop is an endless cycle of code, build, test, tweak, repeat, and 
being able to send screen shots around at an early stage where not 
everyone has access to HW is very useful.

If there isn't the bandwidth for this, I'll just put together a 
stand-alone SSD1306 driver and talk directly to that, though, and we can 
come back to an os_dev based version at a later date. It isn't something 
I think I'd want to design (as a dev) in a corner since it likely isn't 
to be useful longer term designed in isolation.

K.

PS: The displays I intend to use are the following, which can be 
reliably sourced and are relatively inexpensive in volume, and 
appropriate for real world use in small sensor nodes:

- https://www.adafruit.com/product/2900
- https://www.adafruit.com/products/938
- https://www.adafruit.com/products/326
- https://www.adafruit.com/products/931