Sorry to hear that!! I hope you manage to get things back in order.
To make the program just run, would you consider (when you have some time) working with PNG files directly?
The advantages of that are:
simpler to use and understand for new users
demonstrate how to use the image decoder, the use of lodepng library in Micropython, etc.
agnostic to color mode. The image utils automatically converts PNG to the correct color mode that is being used. So you don’t need to convert differently for unix, esp32 etc. You can have a single script with a single set of images that can be used on different platforms.
Well, the colors are wrong!
Did you manage to install libpng? If yes, then you could try argb8888_to_png to convert the images into png files. Have a look at them with eog or gimp.
If the colors are ok there, then you could use the lvgl image converter to get the bin files in the format you need for your hardware. https://www.lvgl.io/tools/imageconverter
Or you could load the png files directly. Have a look at the ili9341 version of the program: https://github.com/uraich/lv_mpy_examples/tree/main/ili_demo_printer
to see how you can load png images
Hi Amir,
I already gave it a try. Unfortunately I have again a problem: The image scan_example_522x340.png
seems to be too big to be loaded:
All the rest seems to work.
In the meantime I also have the ili9341 version running on the ESP32. Also there I see problems with the scan_example image:
Maybe I should try to write a short program just reading and displaying this image file?
The image display program eog and gimp read and display the png file just fine.
One more thing: file is not defined on the esp32 port. I must therefore check on which platform I run and set script_dir correspondingly.
Looks like the ESP32/ILI9341 version is now working correctly. The error on the scan_example image probably came from a not correctly uploaded image file.
Please give it a try and tell me if it also works for you.
I would like to add the option of using either argb565 or png files later.
@uraich When running your latest version on the unix port from another directory I’m getting many “ERROR:DemoPrinter:Could not find image” errors. Perhaps you need to fix paths relative to __file__.
When changing directory to “lv_mpy_examples/demo_printer”, the demo (unix port) works correctly.
I noticed that you created a separate version of the demo for esp32/ili9341.
I think it would be better to have a single version of the demo that works on multiple platforms, otherwise it could become harder to scale and maintain multiple scripts.
How difficult would it be to create a single script that works for both the unix and the esp32/ili9341 ports?
Were you able to overcome the lodepng problem? Is the only problem related to scan_example_522x340.png?
scan_example_522x340.png is 300KB image when compressed, probably too big for many embedded platforms. A possible solution could be to use a smaller image.
I’ve tried your demo on esp32+ili9341+xpt2046 and it’s working!
Very nice job!!
It feels a little slow… Animations don’t feel smooth enough. Images take a bit to get painted. I’m not sure why or how to solve this. Worth trying with uasyncio, maybe the problem is related to lvesp32?
I noticed that RAM is being consumed in the background all the time, even when nothing changes on the screen. You can try running gc.mem_alloc() multiple times and see the numbers go up. They go down again when gc is collected.
So what is constantly allocating RAM? This may be related to the slowness I observed so maybe worth looking into.
I had to upload ulogging.py from demo_printer in addition to all the files under ili_demo_printer.
I needed to change ports and touch calibration values on the display driver. While it’s easy for me, it could be a little difficult for new users. So maybe it’s worth passing these values (SPI pins of ili9341 and xpt2046, calibration values etc.) as arguments to class DemoPrinter to make it easy for new users configuring them.
After playing with the demo for a while, it got stuck (everything including the REPL). I’m not sure how to reproduce this, it only happened once. Did you see something like that happening?
Hi Amir
The mess left by the burglars in my house is almost gone. So I had a quick look at your comments and tried to respond at least to the easy ones. Perhaps you need to fix paths relative to __file__ .
__file__ does not exist on the esp32 version. I therefore check for the platform I am running on. Only, the platform for the unix port is “linux” and not “unix”. Corrected!
This error should be gone. I had a similar problem with the fonts, also corrected.
I noticed that you created a separate version of the demo for esp32/ili9341. I think it would be better to have a single version of the demo that works on multiple platforms, otherwise it could become harder to scale and maintain multiple scripts. How difficult would it be to create a single script that works for both the unix and the esp32/ili9341 ports?
Actually the esp32/ili9341 also works on the unix port. It just has the lower resolution as compared to the original version. Please try!
The lodepng problem is still there. I think that a micro-controller capable of driving a 800x480 pixel display should also be able to handle images this big. Is there a button that can be turned on lodepng to get bigger image buffers at least for hardware capable of handling this? The unix port should be able to treat such a big images.
I Needed to handle a case of NULL argument in mp_to_ptr (updated latest lv_micropython_bindings)
And this is what I got:
If lodepng really requires that much RAM to decode a large image, I believe the problem is that there is not enough RAM allocated to the Micropython unix port.
The unix port currently allocates 1MB for gc RAM. Some of it is used by Micropython and LVGL, and the rest it not enough for large image decoding through lodepng. (The compressed image is 300KB so it’s not surprising that 1MB might not be enough to hold both the compressed image and the uncompressed image)
I think it’s ok to have a smaller demo that “just works” the same way on multiple platforms. Another option to to allow the same demo to work in multiple resolutions according to some configuration.
lv_fs_file_t is an internal, complex type. It has a field that is the void * file_p passed to the wrapper functions. We use void * in the wrappers because it can be anything depending on the FS handlers. E.g. FIL, FILE, my_custom_file_dsc_t
In v8 I think it’s clearer: the wrappers receive what was returned from the open_cb.
Hi Amir,
That is strange! At the moment I try set up a system for a university in Ghana and I created a fresh Ubuntu 20.04 LTS system in a virtual box (They have only windows machines)
I then cloned lv_micropython, made the unix port work and cloned my lv_mpy_examples repository.
I added imagetools.py, fs_driver.py, and ulogging.py. After that the demo runs without problems on the unix port. (On the machine I usually work with I have quite a few modules in ~/.micrpython/lib, which is created when you use upip.
Since fs_driver seems to be corrected I went go back to this. I find the idea of storing the file descriptor in file_p->file_d quite attractive. I was just too dumb to figure out how the correct cast has to be. fs_driver, imagetools.py and ulogging.py are now also copied to the printer_demo directory.
I therefore added everything that is needed to run the demo for both, the 800x480 version (where I use argb8888 files, which cause no problems) and the ili9341 version with 320x240 resolution. The ili9341 version uses png files. I download the repository and just run the demo on a standard lv_micropython version without any optionally loaded modules.
When trying to run ili_demo_printer from another directory I get:
fs_open_callback() exception: ENOENT
so fonts loading should probably be relative to __file__ dir as well.
But running your latest version from ili_demo_printer dir works well!
Very nice!
Going forward, do you think it makes sense to maintain two versions of demo_printer.py with different resolutions?
What do you think of the idea of merging them such that the same demo_printer.py could work in those two resolutions according to some parameter?
I’ve merged the fixed fs_driver into lv_micropython_bindings.
Hi Amir,
I don’t think the error of font loading is in my code: When I construct the filename of the font I get: S:/opt/ucc/micros/esp32/lvgl/lv_mpy_examples/demo_printer/font/montserrat-22.bin
In the open callback of fs_driver however I see: opt/ucc/micros/esp32/lvgl/lv_mpy_examples/demo_printer/font/montserrat-22.bin (the initial / is gone)
As a work around I now check in fs_driver if the path is different from ./ in which case I add the leading ‘/’.
I will have a look if is possible to merge the two versions but this is far from evident, All the icons have will have different sizes in the 2 cases and I have to re-calculate all the positions of the widgets. To make things worse the aspect ration between 800x480 and 320x240 is different. I may give it a try but I am not sure it is worth the effort.
@uraich I hope the issues at your house have been resolved!
I just wanted to let you guys know that I have gotten around to implementing the rest of the MicroPython example logic on the documentation and the lv_ex_arc examples are now available on latest. I can add the rest of the examples easily now.
Sure.
My thinking was that in the long term it’s less convenient to maintain two very similar versions of the same demo. Think about migrating it to v8 at some time in the future - we would have to fix the same things on both scripts.
That’s great @embeddedt!!
I think it’s extremely important to show all these examples in the official docs.
That’s invaluable for new users.
Are you also going to add the “Try It Online” button for each example, to open it in the JS simulator?
Well that couldn’t hurt.
I don’t know how I missed it, it clearly says “Click to try in the simulator!”.
Maybe I was unconsciously looking for a hyperlink.
That’s great!
If you have any problems when enabling any of the other examples, please let me know.
I am very pleased that all the Micropython examples will be soon be visible on the docs. Thanks again!
