Powerless Display Technology (Part 2)

Interface an MCU to an E-Ink Display Module

Last month in Part 1, Jeff explained how to interface a microcontroller to a 2.7” e-ink display module. In this article, he covers the process of preparing new image data, details how temperature affects writing to the display, and explains the potential of partial screen updates.

Turn off almost any appliance or mobile device and its display will most likely go dark (blank). We’ve been used to this limitation for so long that it seems like the only game in town. The Sony Librie was the first product marketed in 2004 as an e-reader or tablet style e-book reader, shortly before Amazon’s Kindle. They employ e-ink technology developed by E Ink Corp. in the late 1990s. While many of today’s portable devices have e-book apps, most of these do not use e-ink displays since they must also perform other functions that are outside of this technology’s limitations.

E-ink’s claim to fame is its readability (especially in sunlight) and battery life (since it can be turned off and still retain its display image). It does have its downside, however. It’s a monochrome display with low refresh rate and potential ghosting on partial screen updates. Even with these limitations, we are seeing more and more products taking advantage of this technology.

Last month, I showed how to interface an Arduino microcontroller to an available 2.7″ e-ink display module (consisting of the display and associated circuitry.) My application presents a menu of selections via the microcontroller’s console I/O. Photo 1 shows the user menu presented along with some additional information (debug). Display data for a single 2.71” screen require 5,808 bytes. While the display has no storage per se, external circuitry contains a serial flash memory that can hold up to 128 images. The first exercise was to dump data from the flash memory to the console using “.” and “X” to simulate white and black data such that the image was recognizable.

Finally, the process of initializing, transferring data, and powering down the display was discussed in detail. Transferring data to (updating) the display is a bit more complicated than just writing the display data to the display. This technology requires retaining a properly polarized charge on each pixel. To accomplish this, the user must know the pixel’s state and write one of three states (2 bits) to the pixel. If the state is to change, you write the inverse data. If 1, then write 10. And if 0, then write 11. If the state is to remain the same write 00. This prevents over charging the pixel data. Image data must be written in stages, writing the negative of the present image, clearing the screen to white (or black), writing the negative of a new image, and finally writing the positive of the new image.

The charge on a pixel will attract or repel pigmented particles within the pixel’s microcapsule. In one polarity, the white side of each particle is attracted to the surface. Switching the polarity attracts the black side. The charge remains when power is removed and the pixel retains its color. If a pixel is overcharged, it would require more of an opposite charge to change its state; therefore, just applying the standard charge would leave the pixel in some intermediate state. If you missed last month’s column, this would be a good time to review it. This application uses an Arduino MEGA 2560 with a protoboard (see Photo 2) providing a 2 × 7 pin interface to the Embedded Artist’s adapter and a 2 × 10 interface to the Pervasive Displays extension board.

• Photo 1
• Photo 2

IMAGE DATA

Bit-mapped data for this display must conform to the display size. This 2.71” display is 264 pixels wide by 176 pixels in height. The 264-pixel width consists of 33 bytes (i.e., 264 pixels/8 bits). This width times the height equals a total of 5,808 bytes (i.e., 33 bytes × 176 rows). You may be familiar with the .BMP file format for storing device-independent bitmaps in various color resolutions. It consists of a bunch of header and color information that describes everything about the file, followed by the image data where each bit mapped location can have rather large color information. This is a bit overkill for this black and white (1 bit) color data. Enter the XBM format.

XBM is a monochrome bitmap format in which data is stored as a C language data array. The format is easily editable (see Listing 1). Note the width and height definitions prior to the unsigned char array. This format can be exported by many graphic editors. I use GIMP the free GNU Image Manipulator Program (www.gimp.org) to prepare an image for use on the e-ink display. After scaling, cropping, and touchup to an image, GIMP will export an XMB format file that can be easily imported. In this case, the file name is “jlb.xmb.”

Listing 1
Data is stored as a C language data array

#define jlb_width 264
#define jlb_height 176
static unsigned char jlb_bits[] = {
   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xfe, 0xff, 0xff, 0xff,
…
   0xff, 0xff, 0xff, 0x7f, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 };

IMPORTING

One of the menu selections offered is: “Load Image File to Selected FLASH Image.” However, there are a few steps to preform before importing. You will want to “Select a FLASH Image,” which will point to the sector/block location in which the file will reside (0–127) in the flash memory device. Since each image will require two adjacent sectors, we will point to an odd sector. To write data into flash memory, the memory first must be erased. Erasure takes place on a block basis. Use “Erase Selected FLASH Image” to erase two blocks (enough space for one image file).

Since I am already using RealTerm as my console (connected to the Arduino’s USB port), I can use its “Dump File to Port” function to send the .XMP file to my application. Listing 2 is the partial load routine.

Listing 2
The partial load routine

//
void LoadBuffer()
{
  int Value;
  Serial.println(“Send File Now!”);  
  ByteIn = 0;
  while (ByteIn != ‘{‘)
  {
    GetAByte();
  }
  Serial.println(“Loading Buffer Image”); 
  from = (Image * ImagePageSize)+ ImageOffset;               
  for (int X = 0; X <= DisplayHeight-1; X = X + 1)
  {
    if (GetARowOfData())
    {
      Serial.println(“Illegal Value, Operation Cancelled”);
      return;    
    }
    //DumpLine(X);
    SaveLine(X);   
  }
  Serial.println(“Done”); 
} 

We start with a message, indicating the application is ready to receive the file. Characters are read from the console until the { is received. After the “open bracket” is found, a second message states that the loading of the buffer has begun. The data format consists of 176 lines of data. Each line consists of 33 bytes in hexadecimal format separated by commas. The GetARowOfData() function reads the console input collecting 33 bytes of data into the ImageBuffer() array. Should the collection run into an unexpected character, the return is false, triggering a cancelled operation. Otherwise, the line is saved using the SaveLine(x) function. This writes the data to the flash memory. Note the commented out DumpLine(x) routine that can be used to verify the data in a graphic way (shown in last month’s column). Photo 3 shows the imported image file written to the e-ink display.

• Photo 3
• Photo 4

TEMPERATURE

The temperature specifications for e-ink displays is typical of other technologies (i.e., LCDs) because low temperatures raise the viscosity of the liquid used in these displays. Typically, this causes slowing response times. A lower temperature is compensated for by extending the charging times of each pixel. (A temperature sensor is part of the interface circuitry.) The display datasheet gives a temperature factor (TF) versus temperature table that increases the TF from 1 at room temperature to 17 at temperatures below –10°C. The TF is a multiplier used to increase the nominal frame write time of 630 ms as the temperature decreases. The frame write time controls the number of times a frame is written, thus increasing the charge times to compensate for the temperature’s viscosity change.

You can see that the total time for writing a frame (image) for the four stages of an image update can be long at extreme temperatures. You probably noticed that the LCDs used in today’s gas pumps have a slower refresh rate during the winter months. I wouldn’t be surprised to find that the chemical content of these technologies could be altered for normal use in extreme conditions if the production demand warranted it.

PARTIAL SCREEN UPDATES

So far in this series, I’ve discussed a display update that includes four stages. This is known as a “global update.” A “partial update” is the process of updating a display from the previous image to a new image directly by refreshing only the pixels that need to be changed. While the global update is the preferred method for updating a screen, as it provides the best solution to eliminate ghosting and extend the life of the particles, a partial update will increase the refresh rate and eliminate screen flash, but it may result in ghosting. Ghosting is visual difference in contrast between the updated and static portion of the screen. Whites might seem whiter, and blacks might seem blacker, than those of previously written static areas. Sounds like a laundry commercial, but ghosting can be accumulative with continual partial updates. E-readers that are using partial updates will do a global update after so many partial updates to renew and eliminate the issue (as stated earlier).

The partial update only requires a single stage. However, there is some additional computational power necessary to determine the differences between old and new image. Remember: for each image pixel you’ll be writing 2 bits, Black or White, to change the state, or Nothing, to leave the charge unchanged. A frame consists of writing data for one row at a time: first the 132 odd bits, then the 176 row enable bits, and finally the 132 even bits. In stages 1 and 4 of global updates, every pixel is inverted (Black or White). In stages 2 and 3 (and for partial updates), we need to figure out which of the three states we need to write. Most microcontrollers have limited RAM space, so instead of creating one giant array holding all the odd, row, and even data for an entire frame, we can work on a row by row basis.

A typical application would have some basic background (static) image with a portion of the screen (dynamic) devoted to a word or number that will change (i.e., a temperature). While text/numbers are treated as individual characters on a character-based LCD, there is no font engine for the e-ink display. Everything must be handled as bit-mapped graphics. This means every character or number must be preconfigured as a graphic object. The size of the graphic character will depend on the font size, with a minimal graphic being (nominally) 5 × 7 pixels. An image is created by placing graphics characters within the original background image at the appropriate locations. Let’s say the background consists of a white screen with the static black text “The temperature is:”. Next to the colon we add two graphic characters, 6 and 2. These images are written to a totally “White” portion of the background display. The rules dictate that we will be writing “Black” to all the “White” pixels that must turn “Black” and “Nothing” to all the “White” pixels that are to remain “White.”

If the sample data increases by one, a new image is created by placing the new graphics characters 6 and 3 within the original background image at the appropriate locations. To update the image on the e-ink display, we use the same rules: write a “Nothing” to all pixels that will remain the same (the background and the character “6”). In fact, many of the pixels within the “3” graphic will also remain the same color. This includes any “White” pixel not part of either “Black” character (2 or 3) and any “Black” pixel that is “Black” in both characters! The only pixels that are written with “White” are those “Black” pixels that now must be “White.” The only pixels that are written with “Black” are those “White” pixels that now must be “Black” (see Photo 4).

Using the Boolean operator XOR on corresponding bits in each image’s data will tell you which bits have changed. If a bit has changed, the high order bit for that pixel’s 2-bit data will be “1”; otherwise, it’s “0.” The new image’s bit will then indicate the low order bit for that pixel’s 2-bit data. If the high order bit in the 2-bit data written to the display is a “0,” then this is a “Nothing” (independent on the low order bit, 00 or 01).

ADDITIONAL MENU ITEMS

During my experimentation with the handling of data, I added a number of debugging extras that can be turned on and off by writing data to the debug byte. Writing a “0” to a bit turns off that function; a “1” turns it on. Be careful enabling these bits, as the amount of data spit out to the console can be quite staggering, causing a function to take a while to complete, especially enabling more than one at a time. These can be used to display actual addresses and data during the transferring of an image, the 2-bit data computed for each pixel, or the actual frame write times.

Menu item 6 allows you to fill a screen with a particular byte of repeating data. This can be used to create a “White” screen, “Black” screen, or vertical stripes of various widths.

I can think of some other items you might want to add to this application. Presently, I don’t have a choice to select Partial update versus the standard Global Update. This doesn’t make a whole lot of sense for total static displays, but it could be used to demonstrate the potential degradation due to shadow/ghosting. Again, this would be more of a graphic manipulation application, as opposed to a technology review.

THE FUTURE

Since I received my first display (years ago) there has been continual improvements in the display technology. I don’t see any reason that the present driver (COB) couldn’t be expanded to handle all display updating tasks. With the addition of some display RAM a user could treat the display as a bit mapped display array. The required algorithms for screen updates would be optimized and no longer a burden to the developer.

There are a number of partners associated with e-ink that offer drivers and such, but nothing you can grab onto and run with. Pervasive display’s website has what I consider the best offering for those interested in playing around with E-Ink technology. Since my original Embedded Artist purchase, their ‘kits’ have expanded to 18 offerings, which include displays ranging from 1.4” to 10.2”. You may wish to get something that you can control via you own code and circuitry or pick out a product that features a TI, Atmel, NXP, or Microchip microcontroller or perhaps driven by a Raspberry Pi or a MpicoSys Tcon.

Besides all of the e-readers on the market, other companies are taking advantage of the zero-power display technology for information kiosks, thermostats, medical testers, smart band/watches, and even cell phones. Photo 5 shows some of these products.

Let’s says you are developing a product that requires some static data, but at a reduced screen size. As you can see from some of the devices in Photo 5, special graphic or screen sizes can be manufactured using e-ink technology. You might benefit from experimenting with some of the reduced function displays available. Photo 6 shows the two standard segmented displays that come with the new quick start kit available through Digi-Key. When segmented displays are properly designed, they do not have the artifacts normally associated with the bit-mapped displays that have closely packed pixels of potentially opposite charges. So much simpler updates are the norm.

• Photo 5
• Photo 6

• 

• 

• 

• 

• 

Don’t be apprehensive about using this or any new technology. It might be just the ticket to improve your next product. Add e-ink to your arsenal of tools and you’ll be smarter. 

Read Part 1 Here

RESOURCES
ePaper Information, repaper.org.
Pervasive Displays, “E-Paper Display COG Driver Interface Timing for 1.44”, 1.9”, 2”, 2.6”, and 2.7” EPD with G2 COG and Aurora Mb Film,” Doc.No.4P015-00, 2015.

SOURCES
Arduino MEGA 2560 Microcontroller
Arduino | www.arduino.cc
EM027BS013 Display module interface
Embedded Artists AB | www.embeddedartists.com
GNU Image Manipulator Program
GIMP | www.gimp.orgE1271CS021 2.7” TFT EPD Panel
Pervasive Displays | www.pervasivedisplays.com

PUBLISHED IN CIRCUIT CELLAR MAGAZINE • NOVEMBER 2016 #316 – Get a PDF of the issue

Jeff Bachiochi

Website | + posts

Jeff Bachiochi (pronounced BAH-key-AH-key) has been writing for Circuit Cellar since 1988. His background includes product design and manufacturing. You can reach him at: jeff.bachiochi@imaginethatnow.com or at: www.imaginethatnow.com.

• Jeff Bachiochi

  https://circuitcellar.com/author/jeff-bachiochi/

  Under Pressure?
• Jeff Bachiochi

  https://circuitcellar.com/author/jeff-bachiochi/

  A Radar Speed Monitor
• Jeff Bachiochi

  https://circuitcellar.com/author/jeff-bachiochi/

  Just How Fast Was I Driving, Officer?
• Jeff Bachiochi

  https://circuitcellar.com/author/jeff-bachiochi/

  Rainbow LEDs