Display Abstraction Layer

"Software never dies", the saying goes. But to help that happen, the software should be as independent as possible from the hardware it uses. Today, we are getting closer to this goal by introducing the Display Abstraction Layer (DAL), a simple framework that allows displaying on any suitable device. The implementation is based on polymorphism: using a virtual class when writing to the display, but instantiating a concrete display class depending on the device being written to. Each device requires its own concrete class that implements a set of functions (defined in the virtual class) used for outputting to the display. Thus every concrete display class becomes a simple “device driver” for the specific display device that was written for.

A class diagram of the DAL framework is shown below.

This is nothing revolutionary, just a simple solution that should have been there (in projects using displays) from the beginning. It provides an easy adaptation between the project functionality and the display, and also reduces the porting effort to just implementing a class for the new display.

The DAL interface consists of a set of function definitions used to output to the display. This set of functions depends on the project. That means that the DAL interface for WiFiChron will be different from the one for WiseClock. For example, in the case of WiFiChron, there are only 4 functions dealing with the display that need to be implemented:

    void setup();

    void writeDisplay (char* displayBuffer);

    void setBrightness(uint8_t brightness);

    void reset();

WiseClock uses a lot more display functions (currently defined in HT1632.h):

  void setup();

  void clear();

  void setBrightness(byte level);

  void snapshot_shadowram();

  byte get_snapshotram   (coord_t x, int8_t y);

  byte get_shadowram     (coord_t x, int8_t y);

  void clearSnapshot     ();

  void clearSnapshot     (int8_t dispNo = 0);

  void copyToVideo       (byte chipNo, char* vbuffer);

  void overlayWithSnapshotHorizontal(int8_t y);

  void overlayWithSnapshotVertical  (coord_t x);

  void plot         (coord_t x, int8_t y, byte color);

  void line         (coord_t x1, int8_t y1, coord_t x2, int8_t y2, byte val);

  void putChar      (coord_t x, int8_t y, char c, byte color);

  void putTinyChar  (coord_t x, int8_t y, char c, byte color);

  coord_t       putLargeChar (coord_t x, int8_t y, char c, byte color);

  void putBigDigit  (coord_t x, int8_t y, int8_t digit, int8_t fontNbr, byte color, int8_t columns);

  void putFullDigit (coord_t x, int8_t y, uint8_t digit, byte color, byte fontNumber=0);

  void putBitmap    (coord_t x, int8_t y, byte indexBmp, byte color=ORANGE);

  void putString    (coord_t x, int8_t y, const char* str, byte color);

  void putTinyString(coord_t x, int8_t y, const char* str, byte color);

  void displayStaticLine  (char* text, int8_t y, byte color);

  void displayStaticLine_P(const char* text, int8_t y, byte color);

Currently, I have implemented and tested a bunch of DAL classes for HDSPwise clock (the simpler version of WiFiChron). These include support for HDSP2534, DL1414, OLED (128x64). The common characteristic of these displays, that makes them suitable for the HDSP clock/WiFiChron, is that all of them can display 8 characters that can then be scrolled horizontally.

DAL for WiseClock would require implementing the above functions for a graphic display with a resolution of at least 32x16 pixels. Also, this graphic display should need no more than 4 control wires (hardware limitation of WiseClock4 board). So, if you wish to replace the 3216 display (not available from Sure Electronics anymore), a suitable candidate would be a TV (through the TV pixel library) or even an 128x64 I2C OLED. Keep in mind that controlling the 16x32 LED displays that use shift registers (either monochrome or RGB) requires more than 4 wires. Their support by Wise Clock 4 would need hardware changes, probably the insertion of a controller (e.g. HT1632, HT16K33 etc).

WiFiChron adapter for DL-1414 displays

WiFiChron has now support for the obsolete (?) DL-1414 displays. I know, the question everybody is probably asking is "why bother?" The immediate answer is because these displays are cheap and easy to find (on ebay or Chinese electronics suppliers), compared to the HDSP-2534. I actually got a few as a gift from Mr. Kin, thank you very much!

DL-1414 is a 4-character 16-segment parallel intelligent display, the grandfather of HDSP-2534: put an ASCII code on the data lines, then flick the WR line, and there you have it, a character displayed at the position specified by A0 and A1 bits. It really does not get any simpler than this. The character set definition, also similar HDSP-2534 (only defines upper case letters though) is stored internally, so there is no need to manipulate any of the 16 segments individually. Although the magnifiers ("bubbles") make them look somehow like QDSP-6064, the DL-1414 display is much smarter, and therefore much easier to interface and program.

Below are some photos of the prototype adapter for the HDSP clock horizontal mod (more of them shown here).

The adapter PCB I designed is available from oshpark (not tested though).

Note that the DL-1414 display is higher, so it won't fit in the Serpac A20 enclosure, but it will fit in the Serpac A21.

Adapting the HDSP/WiFiChron code was super easy. The only functions requiring change are writeChar(...) and writeDisplay(). The next images show these 2 functions side by side, for DL-1414 (left) and HDSP-2534 (right):

Note that the 2 chips share the D0-D6 and A0-A1 lines, but WR lines are separate, which allows individual control of each chip.

In the end, the DL-1414 offers the same functionality as HDSP-2534, at a lower cost, but also with less visibility (characters are about half the size) and less coolness (harsher "font", no lower case).

The DL-1414 experiment opened the door for future WiFiChron displays. Essentially, any 8-character display can be adapted by modifying the two above mentioned functions. This will be next. Stay tuned.

Upgrade your HDSP clock to an NTP-synchronized WiFiChron

So you have the simple HDSP clock but you wish you had the NTP-based time synchronization and the weather feature of the WiFiChron (not to mention the alarm). The "solution" is to buy the WiFiChron kit :)

The alternative "solution" is to hack your HDSP clock, by adding a proto-shield with an ESP8266 module, a 3V3 regulator (e.g. MCP1700) and a buzzer, the components that make the difference between the two clocks.

Before building the ESP8266 proto-shield, perform the following 4 modifications (highlighted in the next photo) on the HDSP board:

1. isolate the FTDI's CTS pin (second from the top) by cutting its traces to the ground;
2. wire the newly isolated FTDI pin 2 to pin 16 of the processor (D10, used for the buzzer);
3. cut the trace connecting pin 1 of the LED display (RST) to pin 3 of the processor;
4. solder the right angle FTDI male header on the back of the board, towards the USB plug.

The small proto-shield, that looks like in the photos below, will plug in the FTDI header. Naturally, the same FTDI header is used for either the FDTI breakout (to upload sketches) or the ESP8266 proto-shield.

Besides the hardware, one little software change (of the original WiFiChron sketch, available here) is required as well, due to the second button connected to A3 (instead of A1 as in WiFiChron):

    #define PIN_BTN_UP 17  // A3 in hacked HDSP
// #define PIN_BTN_UP 15  // A1 in WiFiChron

Since the 3rd button ("Down") is missing on the HDSP board, only the "Up" button function will be available (the left button).

Follow this post to set up the network connection.
And remember, the ESP8266 baud rate MUST be lower than 115200 (set it to 38400), since the ATmega328 with internal clock cannot handle this speed reliably (according to the datasheet, the drift is about 8%).