epaper driver for the Pyboard
- pythoncoder
- Posts: 5956
- Joined: Fri Jul 18, 2014 8:01 am
- Location: UK
- Contact:
epaper driver for the Pyboard
This is now available at https://github.com/peterhinch/micropython-epaper.git
It enables the Pyboard to drive the epaper display from Embedded Artists http://www.embeddedartists.com/products ... epaper.php
These units continue to display when the power is shut down, enabling extremely low power devices to be built, particularly in conjunction with the Pyboard's ability to enter low power modes and periodically be woken by the real time clock. The displays are monochrome only, with pixels being black or white with no greyscales. It should be noted that a display update takes about 3.5 seconds (see the "Introduction and Demo" video on the EA website).
The driver enables simple graphics to be drawn and text to be rendered in any font. Instructions and code are included for converting Widows system fonts to a form suitable for use by the driver. Full screen images in XBM format can also be displayed. The EA device has four megabytes of flash memory: this may be mounted in the Pyboard filesystem and used for general purpose storage.
It enables the Pyboard to drive the epaper display from Embedded Artists http://www.embeddedartists.com/products ... epaper.php
These units continue to display when the power is shut down, enabling extremely low power devices to be built, particularly in conjunction with the Pyboard's ability to enter low power modes and periodically be woken by the real time clock. The displays are monochrome only, with pixels being black or white with no greyscales. It should be noted that a display update takes about 3.5 seconds (see the "Introduction and Demo" video on the EA website).
The driver enables simple graphics to be drawn and text to be rendered in any font. Instructions and code are included for converting Widows system fonts to a form suitable for use by the driver. Full screen images in XBM format can also be displayed. The EA device has four megabytes of flash memory: this may be mounted in the Pyboard filesystem and used for general purpose storage.
Last edited by pythoncoder on Sat Sep 05, 2015 3:44 pm, edited 1 time in total.
Peter Hinch
Index to my micropython libraries.
Index to my micropython libraries.
Re: epaper driver for the Pyboard
Very nice! I really like how you can use the flash on the display as an externally mounted drive. Is it also possible to just use this flash directly, ie read and write blocks using _read and _write? If so maybe you want to expose those methods as public methods?
- pythoncoder
- Posts: 5956
- Joined: Fri Jul 18, 2014 8:01 am
- Location: UK
- Contact:
Re: epaper driver for the Pyboard
Thank you! The reason I made _read() and _write() protected is that using them makes limited sense in the context of a mounted filesystem - and _write() has the potential of wreaking havoc. They are powerful methods but _write() does require the user to understand the flash hardware. It enables you to write to multiple contiguous byte addresses with an arbitrary start address regardless of sector boundaries. Its user needs to ensure the necessary sectors were erased before writing, and to handle gory details like cacheing any saved data prior to erasure and re-writing it (along with the new data) afterwards. I figured that anyone wanting to engage at that level would probably be doing a substantial rewrite of flash.py.
However if you feel making them public is more in keeping with the MicroPython approach (with a caveat implementator in the docs), I'm happy to go along with it![Wink ;)](./images/smilies/icon_e_wink.gif)
EDIT:
On reflection the solution is to implement a write() function complementary to [_]read(). This enables a bytes or bytearray of arbitrary length to be written to an arbitrary flash address. It would handle the low level nastiness of cacheing, erasing and write enabling. To conserve RAM it would use one of the sector buffers for the single sector cache. As such it would be incompatible with mounting the drive, but then direct writing implies the user has devised their own storage scheme. I may yet do this.
However if you feel making them public is more in keeping with the MicroPython approach (with a caveat implementator in the docs), I'm happy to go along with it
![Wink ;)](./images/smilies/icon_e_wink.gif)
EDIT:
On reflection the solution is to implement a write() function complementary to [_]read(). This enables a bytes or bytearray of arbitrary length to be written to an arbitrary flash address. It would handle the low level nastiness of cacheing, erasing and write enabling. To conserve RAM it would use one of the sector buffers for the single sector cache. As such it would be incompatible with mounting the drive, but then direct writing implies the user has devised their own storage scheme. I may yet do this.
Peter Hinch
Index to my micropython libraries.
Index to my micropython libraries.
- pythoncoder
- Posts: 5956
- Joined: Fri Jul 18, 2014 8:01 am
- Location: UK
- Contact:
Re: epaper driver for the Pyboard
I've updated this driver. It now also supports fixed-pitch fonts (by default fonts are proportionally spaced).
Peter Hinch
Index to my micropython libraries.
Index to my micropython libraries.
- pythoncoder
- Posts: 5956
- Joined: Fri Jul 18, 2014 8:01 am
- Location: UK
- Contact:
Re: epaper driver for the Pyboard
Further updated to support fonts stored in a frozen bytecode module. This saves RAM and improves performance. Minor API simplifications.
Peter Hinch
Index to my micropython libraries.
Index to my micropython libraries.
- pythoncoder
- Posts: 5956
- Joined: Fri Jul 18, 2014 8:01 am
- Location: UK
- Contact:
Re: epaper driver for the Pyboard
Another upgrade. Now supports the Adafruit display https://learn.adafruit.com/repaper-eink ... ment-board (2.7 inch model only). It also offers a "FAST" mode intended for displaying (fairly) realtime data. This is imperfect - some "ghosting" can be seen where a faint remnant of old images remains visible but it does enable these displays to be used in applications where display data changes frequently.
Peter Hinch
Index to my micropython libraries.
Index to my micropython libraries.
Re: epaper driver for the Pyboard
Peter,
I was trying to look at the fast mode to see how it worked and how I would need to change my existing drawing code to implement its features. However, in doing so I can across a couple of problems which I am not sure are related to the driver as such but perhaps someone on here can throw some light on them.
Issue 1 is that I get a memory allocation error when I try to import the clock example code from the REPL, this happens everytime without fail unless I call pyb.info() before I do the import clock on the REPL. Log attached below clock is stopped at end of log by CTRL-C.
Issue 2 is that if I put all the epaper driver files in the /lib folder (which I do with most of my standard library files that I have not messed with without problem) then i get the following error on import clock:
I imagine that it is something to do with the embedded from..import commands down the chain of imports for the driver, but odd that it should happen unless it is expected behaviour and i am misusing the .libs folder.
I was trying to look at the fast mode to see how it worked and how I would need to change my existing drawing code to implement its features. However, in doing so I can across a couple of problems which I am not sure are related to the driver as such but perhaps someone on here can throw some light on them.
Issue 1 is that I get a memory allocation error when I try to import the clock example code from the REPL, this happens everytime without fail unless I call pyb.info() before I do the import clock on the REPL. Log attached below clock is stopped at end of log by CTRL-C.
Code: Select all
=~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2016.03.21 20:27:05 =~=~=~=~=~=~=~=~=~=~=~=
PYB: sync filesystems
PYB: soft reboot
MicroPython v1.6-246-gb894551 on 2016-03-21; PYBLITEv1.0 with STM32F411RE
Type "help()" for more information.
>>> import clock
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "clock.py", line 4, in <module>
File "epaper.py", line 167, in __init__
File "epdpart.py", line 104, in __init__
MemoryError: memory allocation failed, allocating 5808 bytes
>>>
PYB: sync filesystems
PYB: soft reboot
MicroPython v1.6-246-gb894551 on 2016-03-21; PYBLITEv1.0 with STM32F411RE
Type "help()" for more information.
>>> import clock
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "clock.py", line 4, in <module>
File "epaper.py", line 167, in __init__
File "epdpart.py", line 104, in __init__
MemoryError: memory allocation failed, allocating 5808 bytes
>>>
PYB: sync filesystems
PYB: soft reboot
MicroPython v1.6-246-gb894551 on 2016-03-21; PYBLITEv1.0 with STM32F411RE
Type "help()" for more information.
>>> pyb.info()
ID=40006400:03513431:34383038
S=96000000
H=96000000
P1=24000000
P2=48000000
_etext=806375c
_sidata=806375c
_sdata=20000000
_edata=20000110
_sbss=20000110
_ebss=20006614
_estack=2001ffff
_ram_start=20000000
_heap_start=20006614
_heap_end=2001c000
_ram_end=20020000
qstr:
n_pool=0
n_qstr=0
n_str_data_bytes=0
n_total_bytes=0
GC:
86528 total
1040 : 85488
1=11 2=4 m=39
LFS free: 5632 bytes
>>> import clock
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "clock.py", line 37, in <module>
File "clock.py", line 33, in <module>
File "clock.py", line 33, in <module>
File "epaper.py", line 503, in puts
File "epaper.py", line 492, in _putc
File "epaper.py", line 455, in _character
KeyboardInterrupt:
>>>
Code: Select all
>>> import clock
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "clock.py", line 4, in <module>
AttributeError: 'module' object has no attribute 'FAST'
>>>
- pythoncoder
- Posts: 5956
- Joined: Fri Jul 18, 2014 8:01 am
- Location: UK
- Contact:
Re: epaper driver for the Pyboard
Regarding the memory allocation error I mention in the README that the FAST mode driver has to create two large buffers, each of which must consist of contiguous memory locations. In use the heap becomes fragmented. This even occurs if you use rshell to copy files across and enter the REPL. If you instantiate a Display after any significant amount of use it will fail. In testing the solution is always to issue <ctrl>D to soft reset the Pyboard before you start. In code which is to run at boot, import the driver and instantiate the display as early as possible, before importing other modules.
The epaper driver, and FAST mode in particular, does seem to be quite demanding of resources on the Pyboard. If you run into problems, issue gc.collect() at strategic points in your code e.g. when a large object goes out of scope.
[EDIT]
I can't replicate your problem with lib. I put the following files in /sd/lib, and deleted them from /sd:
clock.py, epaper.py, epd.py, epdpart.py, panel.py, pyfont.py, flash.py
I then issued:
and it ran as expected. You won't need every file listed to run the clock demo, but they will ensure you can run all the demo code. Have you got panel.py in there? I only ask because that is where FAST is defined. Also, all the above files must be from the latest version of the driver - most (including panel.py) have changed with the implementation of FAST mode.
The epaper driver, and FAST mode in particular, does seem to be quite demanding of resources on the Pyboard. If you run into problems, issue gc.collect() at strategic points in your code e.g. when a large object goes out of scope.
[EDIT]
I can't replicate your problem with lib. I put the following files in /sd/lib, and deleted them from /sd:
clock.py, epaper.py, epd.py, epdpart.py, panel.py, pyfont.py, flash.py
I then issued:
Code: Select all
>>> import clock
Peter Hinch
Index to my micropython libraries.
Index to my micropython libraries.
Re: epaper driver for the Pyboard
Thanks for the reply,
My issue with memory allocation is subtly different from the case you describe in that the memory allocation will fail directly from a CTRL-D soft reset. However, if I soft reset and then from the REPL call pyb.info(), then the memory allocation will work. i.e. the memory allocation is not failing due to a lack of memory, but for some other reason. I will have a play and see if I can recreate this behaviour independent of the epaper driver to try and narrow down the cause.
Thanks for trying the sd/libs issue out. I am pretty sure that I had all the appropriate files there but I will check again. I assume that you checked on an original pyboard? I will compare to see if it is user stupidity or a pylite specific issue.
Neil
My issue with memory allocation is subtly different from the case you describe in that the memory allocation will fail directly from a CTRL-D soft reset. However, if I soft reset and then from the REPL call pyb.info(), then the memory allocation will work. i.e. the memory allocation is not failing due to a lack of memory, but for some other reason. I will have a play and see if I can recreate this behaviour independent of the epaper driver to try and narrow down the cause.
Thanks for trying the sd/libs issue out. I am pretty sure that I had all the appropriate files there but I will check again. I assume that you checked on an original pyboard? I will compare to see if it is user stupidity or a pylite specific issue.
Neil