micro-gui: Highest resolution display to date

[peterhinch]

The image below shows a variety of widgets on an ILI9486 480x320 display.

The host was an RP2 Pico using frozen bytecode. Free RAM while the demo ran was just under 70K. The much smaller nano-gui ran demos without the need for frozen bytecode.

Credit is due to @brave-ulysses in this thread for helping me understand the hardware used in the Waveshare Pi HAT.

[TA1DB]

Hi @peterhinch
Could you please explain shortly how do you preserve the directory structure of the micro-gui ( nano-gui ) code base when freezing to bytecode. I can freeze a module by putting it into the ..ports\rp2\modules subfolder but I don't know how to freeze package folders alltogether preserving the directory relations; do you put all files in the same ..ports\rp2\modules folder ( and change the sources accordingly ) or, do you create subfolders in the ports\rp2\modules subfolder like ports\rp2\modules\gui\fonts\bitmaps\m00 ?? Thanks in advance

By the way ili9486 driver works well for ili9488, tested on this display

[peterhinch]

Thank you for testing the ili9488.

The correct way to freeze modules is via manifest files. This allows the source tree to be free from modifications. I should update the docs which are out of date in this regard. This is my approach.

Build script:

cd /mnt/qnap2/data/Projects/MicroPython/micropython/ports/rp2
MANIFEST='/mnt/qnap2/Scripts/manifests/rp2_manifest.py'

make submodules
make clean
if make -j 8 BOARD=PICO FROZEN_MANIFEST=$MANIFEST
then
    sleep 1
    echo Firmware is in build-PICO/firmware.uf2
else
    echo Build failure
fi
cd -

Manifest file. The first line ensures that the default modules are frozen:

include("$(MPY_DIR)/ports/rp2/boards/manifest.py")
freeze('/mnt/qnap2/Scripts/modules/rp2_modules')

The directory '/mnt/qnap2/Scripts/modules/rp2_modules' contains a symlink to the gui directory of the microgui library. The entire GUI with widgets, fonts etc are frozen in the correct directory structure.

Unfrozen are hardware_setup.py (for easy changes) and the display driver with boolpalette.py: I have had problems with frozen display drivers.

[beetlegigg]

White is the new Black
I've got a waveshare Pico Res-Touch 3.5 that uses the ili9488 as mentioned by @TA1DB above. Using the nano gui driver for ili94xx it's working, but the colours are seemingly reversed. When create a label widget with a foreground of BLACK and a background of WHITE I get the exact opposite on the screen. When my label has a foreground of RED with a background of BLUE I get Green text on a Yellow background. Peter's ( @peterhinch ) nice clock demo comes out in purse pink instead of Green.
Apart from me twiddling with the color mapping in the color.py is there anything obvious I could be doing wrong, or some other simple code tweak I could be doing?
For full info my code is running on a picoW. The example micopython script provided by waveshare runs out of memory when run on a picoW, but it does run on a plain old pico. But nano-gui library seems to run OK apart from strange colours.

[beetlegigg]

Further to previous post regarding a waveshare ili9488 board (that has a place to plug in a pico) if I amend the the gui.core.color.py to have the following color definitions then we are restored to proper colours. I suspect instead of doing this there is a better tweak somewhere so that the standard colours dont have to be re-defined, but its working OK with these redefinitions.

if hasattr(SSD, 'lut'): # Colors defined by LUT:
BLACK = create_color(0, 255, 255, 255)
GREEN = create_color(1, 255, 0, 255)
RED = create_color(2, 0, 255, 255)
LIGHTRED = create_color(3, 80, 255, 255)
BLUE = create_color(4, 190, 190, 0)
YELLOW = create_color(5, 0, 0, 255)
GREY = create_color(6, 155, 155, 155)
MAGENTA = create_color(7, 0, 255, 0)
CYAN = create_color(8, 255, 0, 0)
LIGHTGREEN = create_color(9, 255, 120, 255)
DARKGREEN = create_color(10, 255, 180, 255)
DARKBLUE = create_color(11, 200, 200, 50)
# 12, 13, 14 free for user definition
WHITE = create_color(15, 0, 0, 0)

[peterhinch]

There is evidently a logical inversion taking place. I'll try to figure out the reason, but I've pushed a fix. The driver now has a class variable INVERT_COLOR. This is a 16-bit value defaulting to zero. On the ILI9488 change the color_setup.py (hardware_setup.py on micro_gui) as follows:

from drivers.ili94xx.ili9486 import ILI9486 as SSD
SSD.COLOR_INVERT = 0xFFFF  # Fix color inversion

Please let me know if this fixes the problem.

Re "out of memory" even using 4-bit color the frame buffer for this display is large. The nano_gui library is much smaller than micro_gui, but even so you may need to resort to frozen bytecode for significant applications.

[beetlegigg]

@peterhinch - Thanks very much for the fix, it fixes the problem OK.
Regarding your tip on frozen bytecode, as my intended use for this screen is to receive mqtt messages using your mqtt_as library I think I will have to have a go at creating both the nano and mqtt libs into frozen bytecode. Maybe this combination will be too much for the humble picoW memory, but I will give it a go and see.

[peterhinch]

@beetlegigg Thanks for confirming.

My guess is that, with frozen bytecode, your application will work. Note micro_gui runs this driver on a Pico with ~70K free. While you're using a Pico W, nano_gui is very much smaller. Let us know how you get on, and how much free RAM you're seeing.

[beetlegigg]

@peterhinch - I froze the mpy_as and the gui directory of the nano_gui but leaving out the demo files. The driver for the ili9486 and the bootpalette.py were not frozen as you indicated.

A quick test of program (on a pico W) to receive some mqtt messages and displaying the info received on the waveshare LCD (14 Labels being updated) shows the following free memory results:
gc.mem_free : 48128
gc.mem_free : 49680
gc.mem_free : 49008
gc.mem_free : 49680

(I just printed a gc.mem_free() result after each mqtt message had been received and the screen had been updated without any gc.collect() )

So it all appears to be working quite splendidly, thanks to your exceedingly useful libraries :) . If I should be doing something else to check on the memory usage then let me know and I will test again.

[peterhinch]

@TA1DB I assume you didn't experience this. Are you using micro_gui or nano_gui? I'm wondering if this effect is specific to one GUI.

[beetlegigg]

@peterhinch - its not @TA1DB but me again :). Just to confirm that, at least on my ili9488 (a waveshare designed for the pico as per the link from TA1DB) the mico_gui colours were inverted just the same as on the nano_gui. Of course the 'SSD.COLOR_INVERT = 0xFFFF' sorted it out ok.

And fyi on a picow with just the mico_gui module frozen, running the various.py demo, the free RAM was reported as 40688

[peterhinch]

Thank you for testing!

[uGinn-R]

Sorry for a bit of offtop question, but i'm currently looking for any micropython driver lib for running 128x160 lcd display based on ILI9163 controller. Does micro-gui or nano-gui have support for this type of controller? Thanks.
UPD. As far as i can figure out from quick google research ili9163 is compatible with st7735 and probably drivers are almost identical? Correct me if i'm wrong.

[peterhinch]

It's hard to give a definitive answer. Trawling the datasheets might not tell me because there are often different ways to connect the chip to the LCD display: these require corresponding adaptations to the driver. If you want a "just works" solution you need to buy a display that exactly matches one which has been tested. Otherwise prepare for a journey of research, adaptation and testing.

[uGinn-R]

Thanks for your reply! According to this lcd datasheet main registers are the same as for st7735, at least those that used for initialization in the sample code piece (display on/off, setting column/page addresses etc). Screenshot attached if it can help somehow.

[peterhinch]

I really can't see how I can help. Either the ST7735r driver works or it doesn't. If it doesn't, to debug it I would need the following:

• A display using the IlI9163.
• A datasheet for the above (easy).
• Plenty of time (not so easy).

For the reasons given in my previous post I would only consider doing this if there were a good ILI9163 display available from a reputable source. Chinese ones are likely to use differing pin assignments and require different drivers.

[uGinn-R]

Thank you, i guess there is no need in such complex actions from your side, i'll give it a try next week and report the results :)

[uGinn-R]

Welp, no luck so far with regular st7735 driver from Guy Carver, display test showing some horizontal splitted areas, looks like wrong init...

[uGinn-R]

Upd. I was able to run display with adapted init procedure, yohooo!