MicroPython Forum (Archive)

Those criticisms are correct. The driver does perform temperature compensation for higher temperatures but I don't think the displays are suitable for outdoor operation where temperature can be below 0°C. Their USP is zero power consumption for an unchanging image where there is no competition.

Given that on a moving bike power consumption is not an issue the 0°C limitation and slow response at low temperatures could be overcome with local heating to, say, 20°C. The storage temperature for the device is -20°C to +60°C which could be an issue if you live in, say, Finland.

Ok, some good news:

I got my board today. It's not a PyBoard, but an STM32 running MicroPython.
I have to admit that it took me the entire afternoon, but I learned a lot of stuff and I managed to make the E-Paper display work using pythoncoder's driver. I'd like to thank you very much for making this code available to us.

I had to remap the pin names and make some minor changes, but it works flawlessly. I made a fork of the original repo, so if anybody happens to need the code, it's available here:
https://github.com/mattogodoy/micropython-epaper

Cheers!

EDIT: I'm still not sure if I'll be using this display for my project. It has some drawbacks, but I think the ghosting is acceptable. I'll give it a try.

I'm looking to use the 2.7 inch epaper display with a wipy 3.0. I guess from the last post here that I should be able to do this if I can provide the correct mapping of pins between the pyboard and the wipy 3.0. I've looked at the pinout description for the wipy here

https://docs.pycom.io/datasheets/development/wipy3/

but I can't see how to figure out what the equivalent pin on the wipy 3.0 is for any given pin on the pyboard.

Any help or suggestions would be greatly appreciated.

nordam wrote: ↑

Fri Jul 26, 2019 8:59 pm

but I can't see how to figure out what the equivalent pin on the wipy 3.0 is for any given pin on the pyboard.

Depending on which ePaper module you have, most of the pins don't matter which pin you use, other than the SPI bus. Those three are labeled MISO, MOSI, SCK (or CLK). The other pins are things like chip select, display reset, charge pump control, etc, and can be any digital i/o pin.

On the Pyboard, MISO is X7, MOSI is X8, SCK is X6 (or Y7, Y7, Y6 on the other side -- use either machine.SPI('X') or machine.SPI('Y')). On the WiPi, this looks like pins 14, 11, 10 respectively.

Thanks for the help. So if I just connect it to a bunch of pins that can work in general GPIO mode, and connect the SPI pins to the correct ones on the wipy, and then provide the correct pin mapping, and change the code that creates the SPI object, then it should work? I'll be sure to give it a try and see if I can make it work.

The Adafruit and Pervasive Displays ePaper displays now appear to be obsolete.

I have written a driver for the Adafruit 2.9 inch flexible ePaper display as part of the nano-gui project. The driver subclasses the display from framebuf.FrameBuffer. Consequently the display can be accessed in three ways:

• With FrameBuffer built in graphics primitives.
• Using the Writer class to render arbitrary fonts.
• Using nano-gui to display data via a variety of widgets.

Links:

• Adafruit 2.9 inch display.
• interface board.
• Driver docs.
• FrameBuffer official docs.

pythoncoder wrote: ↑

Mon Jan 18, 2021 10:38 am

The Adafruit and Pervasive Displays ePaper displays now appear to be obsolete.

I have written a driver for the Adafruit 2.9 inch flexible ePaper display as part of the nano-gui project. The driver subclasses the display from framebuf.FrameBuffer. Consequently the display can be accessed in three ways:

• With FrameBuffer built in graphics primitives.
• Using the Writer class to render arbitrary fonts.
• Using nano-gui to display data via a variety of widgets.

Links:

• Adafruit 2.9 inch display.
• interface board.
• Driver docs.
• FrameBuffer official docs.

Peter, Thank you for sharing and I will Order the ePaper display and the interface board and give it a try.