Customer:
I’m working on porting an EPub reader and expect to start that work soon. Can you give me an update on any efforts to develop an ESP-IDF driver for the display? If nothing is in progress, I may attempt to port it myself.
Originally submitted via email support on 22 October 2020. Migrated to the forum for community visibility.
Soldered Support:
No progress has been made on the ESP-IDF driver yet, as we don’t have experience with it. If you could try porting it, that would be very helpful. Please let me know if you need anything else for that process.
Customer:
I’ve looked at the Arduino libraries for the Inkplate-6. Beyond the hardware initialization and very basic screen update, I don’t need much of it. I may retrieve the parts I need and rewrite many methods to align with my own development approach. You may not recognize parts of it once I complete the port. I’ll keep it in a separate package from the EPub reader to keep it accessible for others.
Soldered Support:
Of course, use the approach that works for you - I see no issue there. It’s a good idea to do the basic functionality first, then later the other parts. It would be great if you could do the whole port, but I don’t want to put too much pressure on you.
Customer:
Here is a summary of my ongoing porting effort for the Inkplate-6 device access software. This work is mandatory before I can port the EPub app to the device. All of this can be found on GitHub: GitHub - turgu1/EPub-InkPlate: An EPub Reader for the ESP32 based InkPlate e-Ink devices. · GitHub . The EPub app code has been put in another project: https://github.com/turgu1/EPub-Linux and is now using PlatformIO for compilation. It will be migrated piece by piece once the driver layer is ready.
1) Separation of concerns:
I’ve retrieved content from: Inkplate.* System.* Mcp.* defines.h and a small portion of Graphics.h to build two classes responsible for almost all hardware access: MCP and EInk. An ESP class gives support methods for the drivers in connection with ESP-IDF. A Wire class is being developed to give access to the I2C bus with an interface similar to the one supplied by the Arduino framework. I renamed System as InkPlate and it will have the role of a controller for the device.
Using inheritance as the current Arduino implementation causes an issue with separation of concerns. If I want only low-level access to the hardware without the graphical libraries, it is necessary to disconnect the hard binding between classes through inheritance. So I decided to cut the sub-class connection between the drivers and the rest of the library. I will do the same for the Graphics class, as it can also be handy to keep it separate from the GFX. A new class would then be required to bind the GFX with the other pieces through association instead of inheritance.
2) Object management:
The MCP and EInk classes have been constructed using the Singleton pattern: It is not possible to duplicate them in a piece of software, as they are managing part of the underneath hardware. The C++ compiler can then raise errors if a code design would create a situation by which the MCP and EInk instances would be duplicated. I’ve done a lot of #define integration inside the classes. This renders the classes more conventional in a C++ sense and helps readability of the code.
3) C++ naming conventions:
I have revisited all names (variables, constants, methods, class names) to apply a single convention:
I’ve removed the underscore preceding many variable names (e.g. ‘send’ instead of ‘_send’). Some method names have been changed to verbs. That is the case for display1b and display3b that are now named update_1b and update_3b.
4) Questions:
Is there a reason to keep separate both 1bit and 3bit buffers used by Graphics and GFX to prepare the drawings? It seems that as the device is in one mode or the other, a single buffer large enough to accommodate both modes would be OK. This will save 60K of ram. Another way to do this would be to let the upper application decide on its need and supply the appropriate buffer to the driver (the driver would not be managing 4 buffers but only the two required for the screen update process; new parameters will appear for the update methods to receive the buffer of data).
I’ve looked at your 1-hour video live demonstration on Youtube to grasp a sense of the library functionality. At some point, your colleague indicated the need of calling the clear method before displaying stuff. Is it always the case? If so, wouldn’t it be better to integrate this call in the update_xx methods?
Customer:
I’m glad to see that the new screen will give better screen updates. Can you share the part number of the new screen with me? I would look at it to see how far it is from my current code. I’ve started the porting effort. I’m struggling a bit with memory management inside ESP-IDF in relation with the PSRAM. Things are going well so far. I hope to have a first, non-optimized version in a week or even before if there are not too many issues with my code.
Soldered Support:
You are right that the sequence of starting things up should be different. We’ll change it quickly. The new screen is ED060XH7. It’s quite similar to the Inkplate 6 display. You can find some hints here: GitHub - BornaBiro/Inkplate6P: Arduino library for controlling ED060XH7 bare epaper panel with ESP32 WROVER. · GitHub . Inkplate 10 is the new thing we will be publishing next, based on ED097OC1. Check this for some hints: GitHub - BornaBiro/Inkplate97: Arduino library based around ESP32 WROVER for controlling ED097OC1 epaper panel on e-radionica Inkplate10 board. · GitHub