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: 1393
Joined: Fri Jul 18, 2014 8:01 am

Re: epaper driver for the Pyboard

Postby 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

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

Re: epaper driver for the Pyboard

Postby 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: 1393
Joined: Fri Jul 18, 2014 8:01 am

Re: epaper driver for the Pyboard

Postby 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


User avatar
pythoncoder
Posts: 1393
Joined: Fri Jul 18, 2014 8:01 am

Re: epaper driver for the Pyboard

Postby 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


Return to “Drivers for External Components”

Who is online

Users browsing this forum: No registered users and 1 guest