MicroPython Forum (Archive)

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.

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

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.

I Found these ones. seems availeble in digikey
http://the-digital-reader.com/2016/10/1 ... -projects/
https://www.youtube.com/watch?v=_QJXEg6f9Ss
https://www.youtube.com/watch?v=SQUYMaHz4pU

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.

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!

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:
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.

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.

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.

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.