Waveshare 2.13in display v2 driver

Discuss development of drivers for external hardware and components, such as LCD screens, sensors, motor drivers, etc.
Target audience: Users and developers of drivers.
mattstock
Posts: 3
Joined: Sun Jun 02, 2019 2:38 pm

Waveshare 2.13in display v2 driver

Post by mattstock » Sun Jun 02, 2019 2:51 pm

Hi all,

I'm new to the micropython community, and am working on a project that's based around a custom ESP32 board and one of the common Waveshare/Good Display 2.13" black and white e-ink displays. Between ordering my first display and my second, they seem to have replaced the display with one that seems faster/better, but has a completely different programming and initialization method. :-) There seems to be very little code out there for the new "v2" board.

The model numbers seem to vary a bit, but I'm talking about Waveshare SKU 12672 V2, or Good Display GDEH0213B72. The only example code I've found that works with the new board is https://github.com/ZinggJM/GxEPD, which is great but not python and is somewhat hard to read due to the massive amount of subclassing involved due to the hardware and graphics abstractions.

Before I go down the rabbit hole of porting this logic to a micropython module:

1. Has this already been done, or is anyone working on it and would like to collaborate?
2. Are there existing generic graphics modules that someone could point me to?
3. Is there a process I should be following to provide any developed code to the community?

Thanks much, and I am quite impressed with what I've seen in the platform so far.

User avatar
mcauser
Posts: 484
Joined: Mon Jun 15, 2015 8:03 am

Re: Waveshare 2.13in display v2 driver

Post by mcauser » Mon Jun 03, 2019 4:17 am

Official WaveShare drivers - now includes python2 and 3 (Raspberry Pi):
https://github.com/waveshare/e-Paper

WaveShare product page:
https://www.waveshare.com/2.13inch-e-Paper.htm

WaveShare wiki:
https://www.waveshare.com/wiki/2.13inch_e-Paper_HAT

1. A while ago, I forked their old python drivers and made a MicroPython friendly version:
https://github.com/mcauser/micropython-waveshare-epaper
They've made more changes since which I'll need to rebase against in the near future.

Heres a pycom flavoured one:
https://github.com/ayoy/micropython-waveshare-epd

2. There's many supported displays. OLEDs, TFTs, character LCDs etc. Have a search on Github for "MicroPython display driver". Bitbucket and Gitlab too. Have a look at the MicroPython docs on Framebuf.

3. Share your code on Github or your favourite platform and announce with a forum post. Or fork and contribute pull requests to other peoples drivers.
Once you have a working driver, you could even publish it on PyPI so it can be installed using upip.

mattstock
Posts: 3
Joined: Sun Jun 02, 2019 2:38 pm

Re: Waveshare 2.13in display v2 driver

Post by mattstock » Mon Jun 03, 2019 12:49 pm

Thank you mcauser. I saw your code, and figured that might be the right place to start from. Expect some pull requests if I find the answers I'm looking for.

Unfortunately, Waveshare released the new hardware, and has told me (and the repo seems to confirm) that they have not yet released any sample code or libraries that work with it. It's possible that someone released from Good Display is available (and thus the working ardunio library I reference), but I haven't found anything yet.

Update:

I did find the Good Display example code, which seems very promising. I'll see what I can do with that: http://www.e-paper-display.com/products ... d=423.html

mattstock
Posts: 3
Joined: Sun Jun 02, 2019 2:38 pm

Re: Waveshare 2.13in display v2 driver

Post by mattstock » Sun Jun 30, 2019 2:24 pm

I have made some progress!

I have the full update ESP module logic mostly baked. One issue I did run into is that due to the orientation of the display (long axis is horizontal), I ended up needing a vertical MSB mode for the standard framebuffer I'm using for drawing primitives. I've made a pull request at https://github.com/micropython/micropython/pull/4887 to see if that can get rolled into the standard distribution.

Now that I know I can draw things and in the proper orientation, I'm going to be looking at some of the other framebuffer extensions that allow support for different fonts, etc, as well as potentially implementing partial updates of the screen.

I'll report back once I have a module for this screen that seems fit to share.

Matt

User avatar
pythoncoder
Posts: 4664
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: Waveshare 2.13in display v2 driver

Post by pythoncoder » Mon Jul 01, 2019 6:46 am

Re fonts and framebuffers you might like to look at this solution.
Peter Hinch

peternz
Posts: 1
Joined: Mon Aug 12, 2019 6:10 am

Re: Waveshare 2.13in display v2 driver

Post by peternz » Mon Aug 12, 2019 7:17 am

Hi Mattstock,
Have you made any progress on your the driver? I have an ESP32 TTGO T5 V2.0 board with 2.13in e-ink display. I think it has the same GDEH0213B72 chip.

I tried mcauser’s driver. The display flashes black and white a couple of times but only displays random black and white pixels, which looks like sandpaper. I have 2.9 inch display on a Lolin board and can display text on it, so I think my code is ok. Any suggestions would be great.

Thanks.

GryKyo
Posts: 15
Joined: Sat Dec 15, 2018 12:43 am

Re: Waveshare 2.13in display v2 driver

Post by GryKyo » Mon Apr 13, 2020 1:45 am

pythoncoder wrote:
Mon Jul 01, 2019 6:46 am
Re fonts and framebuffers you might like to look at this solution.
Hi Peter,
I have managed (I'm not a programmer!) to cobble together mcauser's driver and can write to Nokia and Waveshare SPI displays, all is well here. The font using framebuffer fb.text() is 8 points high which is not an issue on the Nokia but on a 1.54" display that is 200 x 200 the text is microscopic.

I have converted a couple of fonts using your font_to_py.py which works a charm. I am not quite sure how to use the NewFont.py file with the framebuffer. In fact a Wemos D1 throws up a memory error importing the NewFont.py! How does one leverage frozencode if this is the issue?

Have I got this all wrong? Here's some code that works with default font in framebuffer, but not as is here...

Code: Select all

import epaper1in54
from machine import SPI, Pin
import framebuf
import ArBold

spi = SPI(-1, baudrate=80000000, polarity=0, phase=0, bits=8, firstbit=0, sck=Pin(14), mosi=Pin(13), miso=Pin(12))
cs = Pin(15)
dc = Pin(0)
rst = Pin(2, Pin.OUT)
busy = Pin(4, Pin.OUT)

e = epaper1in54.EPD(spi, cs, dc, rst, busy)
e.init()

w = 200
h = 200
x = 0
y = 0

buf = bytearray(200 * 200 // 8)
#fb = framebuf.FrameBuffer(buf, 200, 200, framebuf.MONO_HLSB)
fb = framebuf.FrameBuffer(buf, 200, 200, framebuf.ArBold)
black = 0
white = 1

fb.fill(white)
fb.text('It may work this time!',10,80,black)
e.set_frame_memory(buf, x, y, w, h)
e.display_frame()
... where ArBold is a 40 point high Arial Bold TTF post font_to_py.py rendering.

Thanks a mil in advance if you (or anybody) can point me straight

Garry

User avatar
pythoncoder
Posts: 4664
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: Waveshare 2.13in display v2 driver

Post by pythoncoder » Mon Apr 13, 2020 7:56 am

GryKyo wrote:
Mon Apr 13, 2020 1:45 am
...In fact a Wemos D1 throws up a memory error importing the NewFont.py! How does one leverage frozencode if this is the issue?...
A principal purpose in converting a font to Python source is so that it can be frozen as bytecode: bitmapped fonts are large and the ESP8266 has little RAM. The way to do this is covered in the docs.

Your line

Code: Select all

fb = framebuf.FrameBuffer(buf, 200, 200, framebuf.ArBold)
is incorrect. You can't initialise a framebuf in that way: the argument must be a color format as specified in the framebuf doc. You can render text to a framebuf using the Writer class, which you'll find in the font-to-py repo.

So the process is as follows:
  • Convert your font to Python.
  • Build the ESP8266 firmware with the font as frozen bytecode, install.
  • Check that the firmware runs and you can import the font.
  • Instantiate the framebuf as per the line you commented out.
  • Use the Writer class to render text in the font to the framebuf.
I'm not a programmer!
By the time you've done that, you will be ;)
Peter Hinch

GryKyo
Posts: 15
Joined: Sat Dec 15, 2018 12:43 am

Re: Waveshare 2.13in display v2 driver

Post by GryKyo » Mon Apr 13, 2020 10:22 pm

Many thanks!

Back to school for me then. Looks like I am about to learn how to:
Build the ESP8266 firmware with the font as frozen bytecode, install...
The rest of what you say makes sense though is above my wheelhouse so to speak. I will soldier on, this is a self improvement project :roll:

I will report back...

Thanks again

G

JeroenH
Posts: 9
Joined: Sat May 23, 2020 8:19 am

Re: Waveshare 2.13in display v2 driver

Post by JeroenH » Sat May 23, 2020 8:40 am

peternz wrote:
Mon Aug 12, 2019 7:17 am
Hi Mattstock,
Have you made any progress on your the driver? I have an ESP32 TTGO T5 V2.0 board with 2.13in e-ink display. I think it has the same GDEH0213B72 chip.

I tried mcauser’s driver. The display flashes black and white a couple of times but only displays random black and white pixels, which looks like sandpaper. I have 2.9 inch display on a Lolin board and can display text on it, so I think my code is ok. Any suggestions would be great.

Thanks.
I have the same board, and the same problem. I run this code:
import epaper2in13
from machine import Pin,SPI

spi = SPI(miso=Pin(12), mosi=Pin(23), sck=Pin(18))
cs = Pin(5)
dc = Pin(17)
rst = Pin(16)
busy = Pin(4)
e = epaper2in13.EPD(spi, cs, dc, rst, busy)

e.init()
w = 128
h = 296
x = 0
y = 0

e.display_frame()
And all it does is flash the display, and I end up with seemingly random noise.

Image

I'm not entirely sure I've set the correct SPI pins, I've cobbled the pin numbers together from several sources, none of which official. The official Lilygo website (which btw is blocked by my employer's proxy!) isn't much help in that regard either.

I've played around with other libraries both could not get this ESP32/epaper display to work.

Has anyone made any progress on this? This should be a very nice, compact, low power, unit and it would be great if I could make it work with micropython.

Assuming this can be made to work, mcauser's example scripts only draw images. How would one draw a pixel? If I know how to do that, I should be able to figure out how to draw lines, rectangles, circles, etc.

Thank you!

Post Reply