Grove - Triple Color E-Ink Display 2.3"

[arul]

Hi,

Right now, I have Grove - Triple Color E-Ink Display 2.3".

I seen the schematic of the Grove - Triple Color E-Ink Display 2.3". In that schematic, the display have one of the STM32F031F6PTR microcontroller(MCU). The  MCU communicate with externally through UART interface and communicate with display section through SPI interface. Am I correct to understood?

In my project, I use the ATSAMD21J18A MCU and I read the sensor data from temperature and humidity sensor, after data conversion , finally I push the conversion data to Grove - Triple Color E-Ink Display 2.3" through MCU UART interface.

In page no.4 of Grove - Triple Color E-Ink Display 2.3 data sheet, you suggested to flash the one of demo code. If I flash that demo code on  "Grove - Triple Color E-Ink Display" mean that is enough to get data from my MCU UART to display UART and display my data on display board. Or else can I write separate code for that STM32F031F6PTR MCU?

Please give your suggestion.

Thanks & Regards,
Arul

[I wanted a rude username]

I have not completely understood your question, but in general I would not re-flash that STM32. Just use another microcontroller to write to the display using the Grove connector.

This is because it is easy to permanently damage an e-paper display. The firmware on the STM32 has the correct algorithms to minimise the risk of damage, and even so the product page still warns the user not to write more than once every three minutes. So I would not want to change that firmware.

There was a good video on Applied Science a few years ago discussing the challenges of creating your own algorithms for driving an e-paper display.

[Nominal Animal]

Are you referring to this e-ink module? Its Wiki page is here.

Assuming you have the Grove board with the STM32 microcontroller, it is possible to reprogram it using the Firmware Download pins using a suitable programmer.  However, its default firmware is ultra simple: it waits for and receives 5512 bytes, then displays it as a three-color image on the display.
(See write_image_picture() function in the example Arduino sketch for details on how a separate microcontroller can send those 5512 bytes to update the display.  It consists of two frames of 2756 bytes each, or 2756×8 = 212×104 = 22048 bits, with black frame first, then red frame, with set/1 bits indicating white, and clear/0 bits indicating black/red, but I can't really tell whether it is row or column first.  (I think the 212 bytes represent a 212×8 horizontal slice in the display, but I'm not sure.)

So, to answer your question, you only need to write a program for your ATSAMD21J18A microcontroller, that measures the sensors, and whenever the display needs updating, writes the 5512 bytes to the display via UART.  (The example code sends in sets of 212 bytes, with a 80ms delay after each set, and an additional 90ms delay between frames.)  Do note that the display datasheet points out that you should have at least 18 seconds between display updates, or you'll degrade it; I recommend only sending the new display data if the display needs updating, and making sure you wait (measure sensors but do not try to update the display) for at least 30 seconds between display updates.

When you have your ATSAMD code sending those 5512-byte display images via the hardware UART, you only need to connect it to the Grove to see the visual result.  You should not need to try to reprogram the Grove at all.

[Nominal Animal]

As it happens, I recently got a rather similar 2.6" e-ink 296×152 display module with an integrated UC8151C controller.

The electrical interface is very different, but logically it is rather similar: you send the display data (via SPI in this case), separate black and red frames or parts of frames, and then tell the UC8151C controller to update the display.  In some ways, it is slightly more versatile (you don't need to send a full frame, you can send parts of frames), but in others it is harder and less safe to use (no safeguards!).

Because the 24-pin flat flex connector has 0.5mm pitch (it's just about 12mm or half an inch wide!), I haven't soldered it and tested it yet; I'd like some extra connectors, and 24-pin to DIP converters to make sure I can goof and still have replacement parts.

(I'm kinda thinking of making a "No ads" sign on my mailbox, and have it occasionally change to e.g. "No abs" or similar, when nobody is looking.  Except in Finnish, but you see the idea.  It'll probably be stolen immediately, unless I can epoxy it to a metal bracket of some sort, and screw that in from the inside.)

On the software side, I will be using a 296×152 framebuffer with 2-bit pixels; using just 11248 bytes of SRAM.  I'll write the drawing primitives I'll need, as well as the conversion to the black/red frames the UC8151C controller wants.  I'll store the characters or images I need in a similar format. The 2-bit format is a bit tricky (as each byte contains information for four display pixels), but I also like the fact that I then have four "colors": 0=white, 1=black, 2=red, 3=unchanged.  Essentially, I can stuff my Flash full of "images", and display them to wherever I want on that framebuffer.  For each kilobyte of flash used, I can store 64×64 pixels.  If I need more, I'll use a microSD card.

To convert artwork to this two-bit pixel format, I'll write some NetPBM-compatible utilities, essentially to convert a .ppm image to this 2-bit format, with greens and blues converted to the "unchanged" color.  (That "unchanged" means that if I create a stencil of say a smiley face, I can "stamp" many of them all around the display, and only the face part will be repeated; not the entire rectangular area.  The stencil/stamp itself can consist of all three colors the e-ink display supports, with the fourth "color" leaving the display pixels unchanged.  Nifty!)

Do note that I don't use Windows at all, and can't help with issues with that.  However, if you use Linux, or command line tools on Macs, I guess I could hurry up and write those conversion utilities, and maybe even the corresponding e-ink framebuffer functions for Arduino.

However, if you are a Windows user, I think this example of displaying pictures on Grove Triple Color E-Ink Display will be useful for you.