Saturday, August 11, 2018

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).

Sunday, June 24, 2018

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.



Tuesday, April 17, 2018

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%).


Thursday, October 19, 2017

WiFiChron "user manual"

With the daylight saving time ("DST") fall back fast approaching (Nov 5, 2017 for North America), a few explanations and details are required to prepare the WiFiChron clock to automatically set itself.

As much as I would like the menu items to be intuitive, I have to acknowledge that some of them look a little cryptic, and the reason is the 8-character space constraint of the display. Below is the list of all menu items, in the order they appear when the "Set" (left-most) button is pressed.
  1. Alrm on/off - alarm on or off by pressing either the "Up" or "Down" button;
  2. Al 00.00 - alarm time; first set the hours (flashing) by pressing either the "Up" or "Down" button, then move to the minutes by pressing "Set" (minutes will flash); set minutes with "Up"/"Down" buttons;
  3. HH.MM.SS - current time; move from hours to minutes, to seconds by pressing the "Set" button; set the flashing value by pressing "Up" or "Down";
  4. 12/24 Hour - display time in either military (24 hour) mode or am/pm (12 hour) mode;
  5. Scroll 4 - text scrolling speed;
  6. Chimes Y/N - chime (or not) every half hour (top and bottom of the hour);
  7. Moon   Y/N - display (or not) moon phases, in scrolling words (calculated based on the date);
  8. Brite  27 - display brightness;
  9. Yr    2017 - current year;
  10. Month 1 - current month;
  11. Date  1 - current day of the month;
  12. TzHr -1 - time zone hours offset;
  13. TzMn -15 - time zone minutes offset (some places, e.g. Newfoundland and Labrador, use half-hour offsets);
  14. WiFi  Off/On/Ini - connect (or not) to WiFi network (see this post for details);
  15. DST En Y/N - enable or disable automatic time self-adjust when DST changes;
  16. DSTsm 3 - stands for "DST start month"; month for DST spring forward, by default set to 3 (March);
  17. DSTsw 2 - stands for "DST start week"; week of the month for DST spring forward, by default set to 2 (second Sunday);
  18. DSTem 11 - stands for "DST end month"; month for DST fall back, by default set to 11 (November);
  19. DSTew 1 - stands for "DST end week"; week of the month for DST fall back, by default set to 1 (first Sunday);

Here are some photos, courtesy of Tom, of his custom-enclosed, WiFi-enabled, WiFiChron.




Thursday, September 14, 2017

Remixed WiFiChron board

Thanks to all buyers who waited patiently for the new batch of re-designed WiFiChron PCBs to arrive.
The new board eliminates the need for the 2 extra wires on the back (that connected Rx and Tx to ESP8266). The XBee socket, intended for the $45 GPSBee, was also dropped, and replaced with a 3-pin header, used for connecting the $5 GPS modules available on ebay.

Here is the list of notable changes:
  • the only RTC now supported is DS3231;
  • DS3231 is now powered from the regulated 3V3;
  • GPS module is now connected to D17 (already supported in software);
  • as mentioned above, Rx and Tx already connected to ESP8266 module (no need to solder the 2 wires on the back); as before, remember to unplug the ESP8266 module from its socket when uploading a new sketch;
This is how the new board looks like:


and assembled:

Below is the new schematic (compatible with the old one, just re-mixed):


The latest release of the WiFiChron software should still work unchanged with the new board.

On the assembly front, youtuber 12voldvids put together this nice video:


Here is another video on WiFiChron, courtesy of RayS:


If anyone else would like to make and publish videos on any of my kits, I will gladly support it, with explanations/clarifications and, obviously, discounts :)