M5stack and their M5Paper

[wash34000]

Hello,

I've bought a M5Paper with an e-ink screen. Do you know how to start to add this board to your project?

Kind regards

[blakadder]

I will get one soon and see what is possible

[fvanroie]

The main part is getting the display driver to work with lvgl. It seems they already have a standalone SPI driver @ https://github.com/m5stack/M5EPD/blob/main/src/

Lvgl only uses 2 functions of the driver:

1. Init: To set communications and initialize the device
2. Flush pixels : To update part of the screen with changes:

/** @brief Write the image at the specified location, Partial update
  * @param x Update X coordinate, >>> Must be a multiple of 4 <<<
  * @param y Update Y coordinate
  * @param w width of gram, >>> Must be a multiple of 4 <<<
  * @param h height of gram
  * @param gram 4bpp garm data
  * @retval m5epd_err_t
  */
m5epd_err_t M5EPD_Driver::WritePartGram4bpp(uint16_t x, uint16_t y, uint16_t w, uint16_t h, const uint8_t *gram)

A glue driver (interface) between hasp-lvgl and the actual EPD driver needs to be implemented.

I see two challenges when flushing the buffer:

1. 4bpp is not a native lvgl color format, so probably 8bpp with a conversion is needed
2. Flushing needs to be done at 4 pixel (16 bit) horizontal boundaries, which needs special handling

I have never used an e-paper, so it will be an interesting exercise.

[fvanroie]

So, lvgl does have options to handle special buffer alignment and can arrange pixels in special ways too. These callbacks seem to address the two concerns above:

• set_px_cb() - this will be called whenever LittlevGL wants to write a pixel into the VDB and will handle writing the pixel data into bytes in the correct format to send straight to the display. For example if your display accepts vertically aligned pixels (e.g. one byte represents an 8 pixel vertical line) you will use this callback to dispose them correctly.

• rounder_cb() - this will make sure that the area sent to flush_cb() will always be a whole number of pages, as we always have to update the display using pages. Most monochrome displays will only accept data at least 1 byte wide, so it would not make sense for lvgl to try and refresh an area of 3x5 pixels: with this callback you should round buffer areas to the closest page (in this example, a vertical byte boundary).

These need to be implemented to produce the correct 4bpp aligned image data for the EPD. An example of a 4bpp set_px_cb callback can be found in the lvgl forum.

[wash34000]

Thanks for your answer.

Do you thinks that it's an easy task ? Do you need that i try somethink on my M5Paper ?

[fvanroie]

It seems that the M5EPD_Driver.cpp and M5EPD_Driver.h can be used in another sketch without dependencies. If that is the case, the first step is to use those files in another standalone project as test: drawing a rectangle would be enough to verify it works. This step is independent of lvgl and involves trial and error, but should be straightforward if you have access to the hardware.

Another approach to step 1 is to include the whole M5EPD stack from https://github.com/m5stack/M5EPD/blob/main/src/M5EPD.h which is more bloated.

The 2nd step is tailoring the lvgl flush_cb, set_px_cb and rounder_cb to the IT8951 EPD pixel format. Having read the post on the lvgl forum this should be possible, again with trial and error.

And finally we need a bridge driver that maps the two drivers into an api that hasp-lvgl can use transparently. It will require some customizations here and there, but the heavy lifting should be in the drivers.

If you have experience with Arduino coding, you could try to create a basic draw sketch using only the M5EPD_Driver files. Without the hardware I don't have much to go. I think it can work but I don't know how much effort it is going to take at this moment.

[Touftoufe]

Hi, I'm actualy trying to write a driver for the IT8951 controller for the M5Paper. But it's the first time I use LVGL so I don't really know how it works. I wrote some code for set_px_cb() and rounder_cb(), I have something printed on the screen, but it's angled and kind of messy. Any one with an idea? Thanks

[fvanroie]

@Touftoufe Is your project published somewhere? I haven't had a look into this myself yet. It might be helpful if we could put in a joint effort.

[Touftoufe]

No, it's not published yet. I think I managed to get it work. I'm actually able to display labels. So I will clean and organise a bit my code and publish it so you can take a look at it and see if there is something to add or something I did wrong. And I might need to add a color convertor to 4bit grayscale

[fvanroie]

That is very cool already! It demonstrates that it can be done using lvgl and you put the theory into practice. Well done! I'm looking forward to testing this device...

[wash34000]

Sound good ! good job man !!

[fvanroie]

Hi @Touftoufe . I have now also received my M5Paper device. Did you have a chance to post the driver code for the IT8951 controller? I will gladly take a look.

[Ernest-su]

does this link help? https://forum.lvgl.io/t/display-driver-for-e-ink-displays/4186

[fvanroie]

hmmm that's a linux implementation using fb device. I don't think that's going to work in this case.

[jesse-schein]

I know it's not the same but lvgl works just fine on m5core2. I'm gonna try this library out there.

My repo here shows how to do it

[fvanroie]

Yes, we do have M5stack core2 config for hasp-lvgl and it is working pretty well. We still need to handle rotation of the touch driver though.

The challenge for the M5Paper is getting down the lvgl specifics to drive the ePaper display directly. That's why @Touftoufe 's example is very interesting. Otherwise we have to rely on the M5EDP class...

[fvanroie]

Is anyone still interested in this screen?

[MitsuSan]

Yes, sure! Impatiently waiting to use! Most likely many others too. I do not like that M5EDP, want to have something easily portable to other devices.

[Ernest-su]

my M5EDP has waiting a long time.

[wash34000]

I'll love and impatient to use my M5Paper with your project "A really good portable switchplate !"

[Ernest-su]

any update?

[fvanroie]

No feedback from @Touftoufe since his last post, so if anyone want to pick this up...

[wash34000]

Hello,

Any new for this hardware ?

Have a good day.

[fvanroie]

There is a very interesting post in the lvgl forum about the Lilygo EPD47 epaper display. Is anyone actually doing coding or testing for the M5Paper?

[fvanroie]

Closed due to inactivity.

[megawubs]

Please, can someone pick this up? If I could do it I would, but I'm no good with C/C++.

[acabrol]

Any progress on this topic ? I would like to use M5Paper with OpenHASP

[fvanroie]

There is no epaper driver yet, so you will have to implement that display driver for it.

[yetanothercarbot]

I tried compiling this for someone on the Discord server, but they didn't actually have a M5Paper on hand to test (and nor do I).

The bin is on the discord server in case anyone would like to test: https://discord.com/channels/538814618106331137/692393568266092617/1234135438449705022

Hopefully it works, but I can't really do much if it doesn't as I don't have a unit.

Keep in mind that epaper displays are electromechanical devices. If it acts weirdly or starts refreshing too often (most epaper screens recommend only refreshing every few seconds at most), put your device into bootloader mode and erase the flash. Also keep in mind this is untested and is provided as-is.