Module mnemos_d1_core::drivers::sharp_display

Sharp display driver

This is an early attempt at a “frame buffer” style display driver. It provides a emb_display service server, and uses the d1-core specific SpiSender service as an SPI “backend” for rendering.

This implementation is sort of a work in progress, it isn’t really a great long-term solution, but rather “okay for now”.

A framebuffer of pixels is allocated for the entire display on registration. This could be, for example, 400x240 pixels.

The driver will then allow for a certain number of “sub frames” to be requested.

These sub frames could be for the entire display (400x240), or a portion of it, for example 200x120 pixels.

Clients of the driver can draw into the sub-frames that they receive, then send them back to be rendered into the total frame. Any data in the client’s sub-frame will replace the current contents of the whole frame buffer.

Wire format

Reference: https://www.sharpsde.com/fileadmin/products/Displays/2016_SDE_App_Note_for_Memory_LCD_programming_V1.3.pdf

Modules

• commands 🔒

Structs

• CommanderTask 🔒
  This task is spawned by the call to SharpDisplay::register. It is a single async function that will process requests, and periodically redraw the framebuffer.
• Context 🔒
  Shared state between tasks
• Draw 🔒
  Drawing task
• FullFrame 🔒
  One entire frame, stored one bit per pixel
• SharpDisplay
  Implements the EmbDisplayService service interface
• VCom 🔒
  VCom - Once a second, update the vcom flag which is sent in every message.

Enums

• RegistrationError

Constants

• FRAME_BYTES 🔒
• FRAME_COMMAND_BYTES 🔒
• FRAME_DATA_BYTES 🔒
• FRAME_DUMMY_BYTES 🔒
• HEIGHT 🔒
• LINE_BYTES 🔒
• LINE_COMMAND_BYTES 🔒
• LINE_DATA_BYTES 🔒
• LINE_DUMMY_BYTES 🔒
• WIDTH 🔒
• WIDTH_BYTES 🔒

Statics

• DIRTY 🔒
  Waiter for “changes have been made to the working frame buffer”

Functions

• draw_to 🔒