how to alter library micro-gui-main for waveshare with st7789/xt2046

[TLmv]

due to the market i ended up with a waveshare 2.8 240x320 touchscreen and a fairly incomplete and crippled library that was not designed or optimised for this screen. but at least showed something on screen.
nonetheless i managed to make my first script (a clock with a few buttons) run on it.

however, due to the display size i made 2 font_to_py fonts, one at 40px and only numbers at 64px
although it works you can see the pico has a hard time getting it to the display and i do not know how to expand the menu without running into memory issues. i could try a smaller font size to clear up memory, but i'd rather improve or rewrite my script to better handle that display.
i thought that a better designed library and examples would help me on my way

so i found micro-gui-main from Peter Hinch and thought i would adapt the st7789_4bit.py to match resolution, and changed hardware_setup to match pin setup and i get a missing height error if i try to run aclock.py.
if i hard code height and width in there i get a driver incompatability.

i tried to use files from waveshares nanoguilib, (like st7789.py, writer.py,color_settings.py(=hardware_settings) but then all i got were memory errors.

so i'm stuck, unexperienced and would like a helping hand to make a better script.

i've included the waveshare st7789 driver that i use now and would like to see working with micro-gui-main
st7789.txt

[TLmv]

suggestions are welcome :)

[peterhinch]

You haven't stated the exact model of Waveshare display but it sounds similar to this one. Also you haven't stated what platform you're using. Is it a Pico?

The first step to getting a new display working, and to validate your color_setup.py file, is to run this code. Please show what occurs when you do this.

[TLmv]

Your height error in micro-gui suggests a problem in your hardware_setup.py. It should not occur if it calls up a driver from the drivers tree and follows the guidelines. You will have to declare pins for the interface even if you don't plan to use them.

i have used the setup you linked to in a previous post and that includes height and witdh. the pins are the same as also used in my color_setup file from nanoguilib.
fyi what i use is not the regular nanoguilib, but the one you can download from waveshare and that has a few values hard coded and incorrect values and missing functions for Cwriter on this screen.

in hardware setup i have height and width:

# For portrait mode:
ssd = SSD(spi, height=320, width=240, dc=pdc, cs=pcs, rst=prst)

Adapting micro-gui to use a touch interface is likely to be difficult. The best you are likely to achieve without a major rewrite is to replace the up, down, left and right buttons with touches near the corresponding parts of the screen. But this would be a very eccentric way to implement a touch display.

that was what i was thinking to relay my touch choice to the buttons by lack of a better idea. but maybe i can just leave the touch as is in my script and forego the button approach of micro-gui

[peterhinch]

I've found the Waveshare example with nanoguilib. It looks like they have adapted my code in some way. Note that their test runs only the basic functions of FrameBuffer such as vline and hline. They do not test any GUI or Writer code. My guess is that their display driver nanoguilib.st7789 does not fully conform with the requirements of my libraries.

I'm not willing to spend time debugging their driver. I suggest you use mine. Alternatively study theirs with reference to this doc to identify and fix any non-conformance in their driver.

[TLmv]

I've found the Waveshare example with nanoguilib. It looks like they have adapted my code in some way. Note that their test runs only the basic functions of FrameBuffer such as vline and hline. They do not test any GUI or Writer code. My guess is that their display driver nanoguilib.st7789 does not fully conform with the requirements of my libraries.

Yes, waveshare does not invest enough in software that much has become clear to me....and maybe their hardware suffers from the same.
They just search for something that they can make (partly) work with the least effort without the required knowledge of what they are doing.
Their included version of guidemo2 does not work because they ripped out boolpalette from st7789 ...with your driver the whole demo does nothing, but at least also no error :)
and the other demo's they crippled in their 'library' have adaptions of the same quality.

I'm not willing to spend time debugging their driver. I suggest you use mine. Alternatively study theirs with reference to this doc to identify and fix any non-conformance in their driver.

I wouldn't expect you to do that unless waveshare was willing to compensate you for your time. And by the looks of it, that's not likely to happen any time soon.

Thanks for the link, i will invest some time sorting out what i can do, Your help at least showed me your driver could produce something on this screen, even if it was just a line with 2 squares, so there is hope.
If all fails i'll go back to a 1602 with pushbuttons.
Lighter on the pico and on me ;)

[peterhinch]

I am underwhelmed by Waveshare. Their hardware design was lousy: I have two identical E-ink displays with different hardware faults. They seem to have hired a competent engineer lately. But their software is just shoved out the door without regard for quality. I never use it.

[TLmv]

It is my fist experience with waveshare and the pico. And i'm sure to steer clear of waveshare in the future until they are willing to invest in better hard and software.
maybe they have a competent hardware engineer, but obviously too late for this design.
and with poor components there is only so much you can accomplish even if you are the smartest in your field.
as for software engineer, that is still nowhere near what you would expect from a company that sells globally and tries to be a brand.

however, since i have it, i am reluctant to throw it away.
as for now i got part of your nanoguilib working, demo's like aclock and colors15 but not sharptest or my script.
as soon as i try to run my script with anything more than the st7789 from your set of nanoguilib it runs to memory allocation failed...depending on what module i call it varies, the higher up the tree the more memory i am short on. at least still no boolpalette

That is probably also because my script is not very nicely written, so i'm looking into how to improve that.
is your version of nanoguilib using buffers from the st7789 that might not be wired? or are all buffers on the pico?
but enough spend on crippleware....i think it will be smarter to stop investing time in this.
since it does what i designed it to do....flick a switch every 30 seconds(this can be changed via touch display) and refresh the screen with a timer once a second......not that impressive i would say. and i certainly didn't expect the display taking up this much resources by presenting a few numbers.

time to get another display, either a 1602 or something with less (preferrably larger) pixels and better hard and software.

[peterhinch]

The sharptest demo is for Sharp displays only. It is not expected to run.

I am puzzled by your memory allocation failures. My Pico shows 182880 bytes free with nothing running, and 116480 bytes free running the aclock demo. In microcontroller terms that is a lot of RAM. An ESP8266 has only about 42KiB in total and it can run nanogui with optimisation.
If you really need more than 116480 bytes of RAM you can always use the optimisations outlined in the docs: freezing fonts and code. This might be expected to halve the approximately 65K in use.

You might like to read this doc on optimising your own code.

something with less (preferably larger) pixels

You can always create large fonts with font-to-py. I have users who created digital clock fonts with minimal character sets. The idea was a display which could be read across a room.

better hard and software

For all that my e-paper displays are rubbish, I have no complaints about my sample of this display from a hardware point of view.

[TLmv]

mind you, my program does not have those memory allocation problems (yet) when i use it in combination with the crippled waveshare library...although it might come close, i have no idea.
the visual part of my code is actually created with inspiration from aclok (not your aclock, the waveshare adapted one)
only when i switch to calling modules from your nanoguilib library i get the memory allocation failures, but not when i run a few of the demo's you've included. so it's all on my program.

i have no idea why that is, but i'm guessing it has to do with what waveshare removed from the driver (boolpalette and more) in order to make their screen work.
and although i don't use it in my program, your library does use it when i run my program via your library and apparantly not with aclock or color15

the plus is, because of this i made serious progress in my understanding of micropython. but apparantly not enough yet to analyze my sluggish code...... i removed a few things that do not have to be refreshed every second,
when i started the code i had to slow down everything, since the screen i removed all sleeps since creating something on screen takes up visible time.....so the screen is sleep enough i guess. if i add some more text on screen it won't even make my call for 1 frame a second.

i added your library to the pico so i could test your demos and as extra waste of space and then my script running on the waveshare set is still running without memory problems. so i wouldn't know if compacting the code by freezing would help.

other things that might eat up memory, i use a pico W, so it also has code for wifi on board.
as for creating large fonts, i'm guessing that is part of my low memory.
for that reason i thought it would be easyer for the pico to have an equally large display with a quarter of the pixels to adress, large font without the data.
alas these screens don't have a scaling (cluster) option, that would save a ton of data to be written; font10 > scale 6 :)

if you have this display, pico w, ds3231 and maybe a relay or led i could give you my script so you can run it yourself.
but i completely understand if you aren't that interested or lack the parts :)

[peterhinch]

other things that might eat up memory, i use a pico W, so it also has code for wifi on board.

The Pico W shows 161728 bytes free as against 182880 for the Pico, a ~20KiB loss. The aclock demo reports 90432 bytes free on Pico W. That is still a lot of RAM by microcontroller standards. In my view substantial nano-gui applications should be possible on Pico W.

Unfortunately I don't have time to set up hardware, test and debug your code. If you raise questions in Discussions I and others will attempt to answer them. If your code is not too long, post it there for review.

[TLmv]

by now the script has become way too large to post and there is also a lot more going on on the display than when i started this thread.
so i'm not unhappy the way this is turning out although it might need further shaving.

as for the memory errors, although i was planning to start over with your library i couldn't leave it alone.
i might have gotten closer, but the memory errors are still there...although now accompanied with some other errors prior.
i tried a different approach where i would take one module from your library and adapt it until it works.
except for st7789_4bit i included a few widgets this way, but if i switch nanogui and import writer this is where it keeps failing: line 87 in set_pend: keyerror, get_globals, memory allocation failed... although it's now only 3680 bytes.
if i use writer or color in my script, i immediately get a memory error with a lot higher values.
the really strange thing is, both writer files are identical except for a bdcolor and a verbose from false to true...and those can't be the problem. But if i switch them all text is gone, only the dial and label things are written to screen...no error.
But eventually i found out that i had to change it in both my script and label and then it works...the more files are involved, the more to check (note to self)
and now nanogui from your setup is also working without memory errors...i'm getting there.

i'm sure i'm just missing something that doesn't point right in some module to make it work. untill then, memory trouble :)
nothing to worry about.

[TLmv]

i do have a question after another day of tries and tests, is it possible to rotate the screen from script?
in color_setup it uses:

ssd = SSD(spi, height=320, width=240, disp_mode = 0, dc=pdc, cs=pcs, rst=prst)

where disp_mode = 0 defines the orientation of the screen.
can i change to disp_mode = 2 from a script while running? and if so, how do i make that work?
i'm not moving from landscape to portrait, i would like to rotate 180 degrees. same layout, different orientation.

would that entail another buffer or could i just recalculate the x&y coordinates 240-x, 320-y when plucked from the buffer