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
# OLED Display
- **Display Name**: oled
- **Priority**: 200
- **Stack Size**: 64 (256 bytes)
Controls and updates the 128x32 pixel mono OLED display based on incoming
events.
## Overview
This task controls the HW refresh of the 128x32 pixel monochrome OLED display.
It will update the display contents based on a series of events that can be
passed in to the internal message queue, such as updating the displayed RSSI
level, battery level, or updating the 128x24 pixel user portion of the screen.
### Display Sections
The display is divided into two sections:
The **status bar section** is 128x8 pixels. This section can not be edited
directly outside this task handler, and is updated via incoming events.
The **user section** is 128x24 pixels, and can be updated by other tasks or
code in the system. The raw pixels are accessed as a 384 byte buffer (128*24/8)
that can be updated externally, followed by a display refresh request once the
buffer contents have been modified.
## Dependencies
### Related Tasks
- sysevents
### Related Packages
- hw/drivers/display/ssd1306
- lib/monogfx
## Events
### Input Event Queues
The following event queues are executed in this task's context, and can be used
to pass events into the task handler:
#### g_display_evq
This event queue is used to store and parse events related to the display, such
as updating the status bar, or refreshing the user section of the display.
The following callbacks are available as part of this task handler:
##### display_refresh_cb
This callback is used to refresh the display contents after the user section's
buffer has been updated.
No parameters are required to use this callback.
##### display_status_update_cb
This callback is used to refresh the status bar when a specific event takes
place, such as the RSSI level changing, the battery level being updated, etc.
###### Arg Format
```
struct display_status_update_event_arg {
enum display_status_update_ev_code code;
union {
int32_t i;
int16_t i1;
int16_t i2;
uint32_t u;
uint16_t u1;
uint16_t u2;
float f;
uint8_t a[4];
};
};
```
###### Code Values
```
enum display_status_update_ev_code {
DISPLAY_STATUS_UPDATE_RSSI = 0,
DISPLAY_STATUS_UPDATE_BATTERY_LEVEL,
DISPLAY_STATUS_UPDATE_CONNECTED,
DISPLAY_STATUS_UPDATE_TX,
DISPLAY_STATUS_UPDATE_RX
};
```
The `code` values accepted by this event handler have the following meaning:
- `DISPLAY_STATUS_UPDATE_RSSI`: Indicates an update to the RSSI level between
this device and the device on the other end of the connection. This event
uses the `u1` and `i2` values to receive the integer RSSI level, where `u1`
indicates the connection number, and `i2` contains the RSSI level.
- `DISPLAY_STATUS_UPDATE_BATTERY_LEVEL`: Indicates that the battery level has
changed. This events uses the `u` value to receive the battery level in
millivolts.
- `DISPLAY_STATUS_UPDATE_CONNECTED`: Indicates that the connection state of
the device has changed. This event uses the `u` value to receive the current
connection state, where 0 means no connection and a positive value indicate
the number of currently connected devices.
- `DISPLAY_STATUS_UPDATE_TX`: Indicates that some TX activity has taken place
on the device. This event uses the `u1` and `i2` values to receive the
number of bytes transmitted, where `u1` indicates the connection number, and
`i2` contains the number of bytes transmitted.
- `DISPLAY_STATUS_UPDATE_RX`: Indicates that some RX activity has taken place
on the device. This event uses the `u1` and `i2` values to receive the
number of bytes received, where `u1` indicates the connection number, and
`i2` contains the number of bytes received.
## Semaphores and Mutexes
Any semaphores or mutexes used by this task.
## Notes
Any additional notes about this task.
