epaper driver for the Pyboard

Discuss development of drivers for external hardware and components, such as LCD screens, sensors, motor drivers, etc.
Target audience: Users and developers of drivers.
User avatar
pythoncoder
Posts: 5956
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: epaper driver for the Pyboard

Post by pythoncoder » Tue Mar 22, 2016 9:28 am

Neil wrote:... I will compare to see if it is ... or a pylite specific issue...
As I state in the README introduction, I'm doubtful it will work on a Pyboard Lite because it uses a lot of RAM (especially in FAST mode). When the rewards for the ESP8266 Kickstarter are sent out I'll have one to try but I'll be surprised if it works to a usable extent.

Do post here if you get any joy.

[EDIT]

I now have a Pyboard Lite. The current version of the FAST mode clock demo runs. If I interrupt it with <ctrl>C and issue gc.collect(), micropython.mem_info() shows about 50% RAM usage. My view is that the boards with more RAM are preferable, but for simple applications the Lite should work. You may need to perform gc.collect() at strategic points in your code to avoid issues with heap fragmentation.
Peter Hinch
Index to my micropython libraries.

thoru
Posts: 2
Joined: Sun Feb 12, 2017 9:20 pm

Re: epaper driver for the Pyboard

Post by thoru » Sun Feb 12, 2017 9:28 pm

have you tested any epapers with color red? I see there are displays with three colors now.

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

Re: epaper driver for the Pyboard

Post by pythoncoder » Mon Feb 13, 2017 9:10 am

I'd be interested to see details.

The driver is specific to the two devices specified in the docs (both share the same display hardware). These things require a lot of hardware-specific low-level operations so porting to different display hardware would require significant effort.
Peter Hinch
Index to my micropython libraries.


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

Re: epaper driver for the Pyboard

Post by pythoncoder » Tue Feb 14, 2017 8:41 am

Thanks for that, very interesting. As yet Pervasive Displays aren't offering a module comprising display and controller so any development would have to wait for that to emerge. One beauty of the existing 2.7" display is its neat mechanical design: hopefully they will produce a similar unit for the two-colour ones.

I can see another potential snag: the size of the frame buffer. The 2.7" display requires a 7744 byte frame buffer. Ideally you should use two of these but my driver just uses one. This compromises performance in fast mode - some ghosting is apparent in this mode. But 7744 bytes is a big buffer on the Pyboard.

The 2.87" display would require 9472 bytes (based on 2 bits per pixel) and the 4.2" unit would need 30,000 bytes (400*300/4).

In my view the 4.2" unit would be entirely impractical if the frame buffer still has to be located on the Pyboard. The big hope would be if they changed the controller architecture so that the frame buffer was located on the controller: the Pyboard can drive large displays with that kind of structure (https://github.com/peterhinch/micropython-tft-gui.git).

I'll keep an eye on Pervasive Displays to see what emerges.
Peter Hinch
Index to my micropython libraries.

matto
Posts: 20
Joined: Mon May 22, 2017 11:59 am

Re: epaper driver for the Pyboard

Post by matto » Thu Jun 08, 2017 2:11 pm

pythoncoder wrote:When the rewards for the ESP8266 Kickstarter are sent out I'll have one to try but I'll be surprised if it works to a usable extent.
Hi pythoncoder!
I'm curious about how your driver behaves with the ESP8266. Where you able to test it?
I received two of these wonderful displays today and I'm still waiting for my PyBoard 1.1, but I have a NodeMCU board running MicroPython at home, and I'd like to give it a try, but I'm not sure if it has enough memory to drive them, and if so, how to should I wire it (which pins on the board).

Also, hats off for your work. I really appreciate that you give all that effort away for makers to experiment. Thank you!

matto
Posts: 20
Joined: Mon May 22, 2017 11:59 am

Re: epaper driver for the Pyboard

Post by matto » Thu Jun 08, 2017 5:44 pm

Ok, I have good and bad news.

Good first: I think I found a reference on how to wire the display to the NodeMCU board here: https://blog.squix.org/2017/02/esp8266- ... splay.html
They were able to drive the Embedded Artists display with the NodeMCU board, but using the Arduino environment.

Now the bad: I've uploaded all of the modules to the board, but when I try to import epaper I get this error:

Code: Select all

>>> import epaper
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "epaper.py", line 431
MemoryError: parser could not allocate enough memory
I tried soft-rebooting the board first, but no luck. I guess the ESP8266 just does not have enough memory to drive the display :(
If you have any recommendations or ideas to make it work, they will be highly appreciated.

User avatar
Roberthh
Posts: 3667
Joined: Sat May 09, 2015 4:13 pm
Location: Rhineland, Europe

Re: epaper driver for the Pyboard

Post by Roberthh » Fri Jun 09, 2017 10:11 am

The use of frozen bytecode might help, if the demand for code memory is too big. If it fails because the too little RAM for data, then things are more difficult.

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

Re: epaper driver for the Pyboard

Post by pythoncoder » Fri Jun 09, 2017 2:28 pm

matto wrote:I'm curious about how your driver behaves with the ESP8266. Where you able to test it?
...
I knew almost nothing about the ESP8266 in March 2016. I now think it's a non-starter on grounds of RAM availability.

When considering target hardware bear this in mind. It requires a large contiguous frame buffer (over 5KiB) which makes it demanding on RAM. If you use the Flash memory on the display a further buffer is required - it's usually best not to use this option and store resources in the target's flash as flash is usually more plentiful than RAM. See my previous comments re the Pyboard Lite. tl;dr It works but a full-fat Pyboard is preferable.

As Robert says, frozen bytecode reduces RAM demands. But it's data which is the principal problem with this driver, owing to the nature of the display hardware.
Peter Hinch
Index to my micropython libraries.

matto
Posts: 20
Joined: Mon May 22, 2017 11:59 am

Re: epaper driver for the Pyboard

Post by matto » Sat Jun 10, 2017 12:23 am

Thanks for your answer!

I guess I'll have to wait for my PyBoard to arrive then :)
It's a shame, because the WiFi module would come handy for this display, and it's also very small.

What I'm trying to do is a motorcycle odometer. This display is perfect because of the direct sunlight visibility, but it has a LOT of disadvantages:
- Needs a lot of memory
- Uses a lot of pins
- It's correct operation depends on temperature
- The refresh rate is SLOW

I guess I'll have to use another display for my project. It makes me a little sad, because the visibility is key in this case and the e-paper is perfect for that, but I guess I'll have to keep searching for an alternative display.

Post Reply