reducing ram usage or other solutions for my nanogui script with pico w

[TLmv]

Hi,
i've got the nanogui library of Peter Hinch in use on a pico w combined with a I2C relay card and 6 OneWire sensors.
It also includes logging to a SD card and has a touchscreen.
as a display I have a 320x240px screen with a st7789 chip.
the script only refreshes the screen every 10 seconds, so i thought it would have plenty time to build uo the screen somewhere in those 10 seconds.

and while i was trying to create a extra pwm signal i ran out of memory.
all in all it seems i reached the limits, so i tried to see what my memory usage was, and added a few gc.mem_free() calls.
my first thought was that my script was hogging memory, but after testing it seemed i had not much to work with as is.

what i'm wondering is, can i get more free ram or should i consider something else, like using a different mcu or combining 2 picos to share the workload, stopping with the display and creating a webinterface....

as you can imagine, the script is a bit long to share here, but any suggestions how i can squeeze more out the pico are appreciated.

what i see in memory usage:

after loading machine, the onewire.ds library etc. it still has 137kb free
after loading color setup this drops to 89kb
after writer this drops to 80kb
after fplot it drops to 66kb
after loading 2 fonts (12 and 35 px) and colors it drops to 46kb
and when my main program starts , it's down to 33kb.
finally when running it has about 19kb of free memory on average.

cleaning up about 10kb would be enough i think.
I was thinking about if it would be possible to scale the small lettertype (12pc) to a larger font to save on memory, but then that wouldn't save much RAM is my guess, somebody else came with the idea that i should either drop the buffer to 2bit or that i use a buffer that is only 160x120px and then scale it to 320x240px, but i wouldn't know how or if that is possible.

any suggestion is welcom :)

[beetlegigg]

You don't mention it, so I ask if you are freezing the nanogui, and possibly other libraries, into a custom build of mp to gain memory?

[TLmv]

i was planning to find out how to freeze something as soon as i have the script working stable.
but, isn't freezing more about storage space than ram?

what i do see if i write a label or textbox on a small part of the screen it takes about 15kb for that moment and with only 19 free on average even an extra print statement can tip the scale.

[peterhinch]

Firstly grab the latest daily build which gives you about 30K more RAM (compared to earlier in the week).

Secondly, freezing is all about saving RAM because code and data are stored in Flash rather than in RAM. In particular the way I implement fonts is designed for freezing: frozen fonts use almost zero RAM. See official docs.

[TLmv]

Firstly grab the latest daily build which gives you about 30K more RAM (compared to earlier in the week).

Secondly, freezing is all about saving RAM because code and data are stored in Flash rather than in RAM. In particular the way I implement fonts is designed for freezing: frozen fonts use almost zero RAM. See official docs.

where can i find the latest daily build, i work now with the set that was updated last month:
https://github.com/peterhinch/micropython-nano-gui

as for freezing the font to py converted files, i'll dive into that with the code beetlegigg posted as guidance i might have more luck this time.

[beetlegigg]

Peter was referring to the daily builds of micropython not his nanogui library :-)

[TLmv]

thanks, i just downloaded the new nightly build and i'm up to 40kb free now! an impressive difference

[beetlegigg]

I'm no expert, just a bumbling hobby programmer, but I think that freezing the code into a mp build means the code does not have to be copied into RAM when it runs. Maybe someone would give a better explanation.

I had my first go at a custom build a month back and it was to freeze the nanogui and mqtt_as libraries from @peterhinch. I show the gc.memory() results when I run a script with .py files and the results when its run from a custom build.
code:
import gui.core.colors
import gui.core.nanogui
import mqtt_as
import gc
gc.collect()
print('gc.mem_free : ', gc.mem_free())

.py files:
Traceback (most recent call last):
File "", line 3, in
MemoryError: memory allocation failed, allocating 1784 bytes

custom build:
71232

For the nanogui, following something peter has written I did not freeze the driver file, just the stuff in the gui dir.

my build sequence was:
$ mkdir pico
$ cd pico
$ git clone https://github.com/micropython/micropython.git --branch master
$ cd micropython
$ make -C ports/rp2 submodules
- add some links into the picoW manifest file for links the directories containing the code to freeze into the build
$ cd pico/micropython/ports/rp2
$ make BOARD=PICO_W submodules
$ make BOARD=PICO_W clean
$ make BOARD=PICO_W

my notes on what I did to freeze the .py files are
 ADD FROZEN MODULES TO MP BUILD FOR MICROPYTHON

# add link to directory containg the module to freeze
# eg the - freeze("/home/pi/mp_nano_gui") - is added to the manifest file
# in the PICO_W directory

/home/pi/pico/micropython/ports/rp2/boards/PICO_W/manifest.py -

include("$(PORT_DIR)/boards/manifest.py")
require("bundle-networking")
freeze("/home/pi/mp_nano_gui")
freeze("/home/pi/mqtt_as:)

# e.g. the directory (and sub directories) containing modules to freeze:
/home/pi/mp_nano_gui
sub dir's:
	widgets
	fonts
	core

/home/pi/mqtt_as:
files:
	mqtt_as.py

---

I hope it helps :-)

[peterhinch]

following something peter has written I did not freeze the driver file

Some of the drivers use native and Viper emitters: I suspect this was the reason I have had trouble in the past. When V1.20 comes out I will re-test and review this recommendation. In any event the drivers are fairly small.

[peterhinch]

To add some general comments. nano_gui is designed to minimise RAM use. The frame buffer is the biggest user, and it is unavoidable. Its size depends on the size of the display and the pixel size of the driver. So a 128*128 display with a driver using 8-bit color will consume 16,384 bytes of RAM. Another user is fonts: if you freeze them their usage drops essentially to zero. If you can't freeze them you can sometimes make them smaller. For example a user wanted to make a digital clock with a very large font. I advised him to use font_to_py to restrict the character set to those required.

I'm quite surprised that you're running out of RAM on a Pico.

I would try to determine whether the RAM is being used by nano_gui or by the application. You might adapt the "hello world" test from the docs as follows, to get an idea of how much RAM is being used by the GUI and how much by the application:

from color_setup import ssd  # Create a display instance
from gui.core.nanogui import refresh
from gui.core.writer import CWriter
from gui.core.colors import *
import gc

from gui.widgets.label import Label
import gui.fonts.freesans20 as freesans20  # Use whatever font you are using

refresh(ssd)  # Initialise and clear display.
CWriter.set_textpos(ssd, 0, 0)  # In case previous tests have altered it
wri = CWriter(ssd, freesans20, GREEN, BLACK, verbose=False)
wri.set_clip(True, True, False)

# End of boilerplate code. This is our application:
Label(wri, 2, 2, 'Hello world!')
refresh(ssd)
gc.collect()
gc.mem_free()  # Display free RAM with the GUI loaded

If the bulk of the RAM use is in the application then trawling the code for optimisations is the way forward.

[TLmv]

To add some general comments. nano_gui is designed to minimise RAM use. The frame buffer is the biggest user, and it is unavoidable. Its size depends on the size of the display and the pixel size of the driver. So a 128*128 display with a driver using 8-bit color will consume 16,384 bytes of RAM.

that is why i was wondering if i could scale the display, since the display is 320x240, your calculation comes to something like 70kb for the buffer. however if the buffer is only 160x120 and px 0,0 is copied to 0,0-0,1-1,0-1,1 it might save on memory usage while still maintaining a readable size....although i would dislike the loss of resolution for the graph, functionality before form in this case.

Another user is fonts: if you freeze them their usage drops essentially to zero. If you can't freeze them you can sometimes make them smaller. For example a user wanted to make a digital clock with a very large font. I advised him to use font_to_py to restrict the character set to those required.

it might be me you gave that tip, since i use that too.

I'm quite surprised that you're running out of RAM on a Pico.

i'm not saying i'm an accomplished programmer, so perhaps my code is not as efficient as can be (too much variables?)

I would try to determine whether the RAM is being used by nano_gui or by the application. You might adapt the "hello world" test from the docs as follows, to get an idea of how much RAM is being used by the GUI and how much by the application:

since in theory there may not be a difference in theory and practice, but in reality there is, i rather use my script as reference.
since it's not 'only' a display, but also spi touch and sd card, onewire, I2C and possibly PWM since i have a bit of memory left now.

at this moment i'm at a loss how to further improve on my script in saving more than a few bytes of ram.
since you are too, maybe these numbers give you some info on why i'm running low and you may come to the conclusion that it's no surprise with all these things loaded at start, and this list is not even all that's loaded at start).....although with the new nightly build stability has improved significantly, i still could use a bit more headroom.

from machine import Pin, PWM, SPI
import onewire
import ds18x20
import time
import binascii
import json
import os
import gc
gc.enable()
time.sleep(2)
print('free mem', gc.mem_free())

from color_setup import ssd, wdt  # Create a display instance
print('geheugen vrij color_setup', gc.mem_free())
from gui.core.writer import CWriter
print('geheugen vrij writer', gc.mem_free())
from gui.core.fplot import CartesianGraph, TSequence
print('geheugen vrij fplot', gc.mem_free())
import gui.fonts.arial12 as arial12
import gui.fonts.arial35 as arial35
print('geheugen vrij fonts', gc.mem_free())
from gui.core.colors import *

print('geheugen vrij colors', gc.mem_free())
from gui.core.nanogui import refresh
print('geheugen vrij refresh', gc.mem_free())
from gui.widgets.label import Label
print('geheugen vrij label', gc.mem_free())
from gui.widgets.textbox import Textbox
print('geheugen vrij textbox', gc.mem_free())
refresh(ssd,True)
CWriter.set_textpos(ssd, 0, 0)  # In case previous tests have altered it
wri = CWriter(ssd, arial12, GREEN, BLACK)  # Report on fast mode. Or use verbose=False
wri.set_clip(True, True, False)
wri_t = CWriter(ssd, arial35, GREEN, BLACK, verbose=False)
wri_t.set_clip(True, True, False)
print('geheugen vrij text', gc.mem_free())

and this results in:

free mem 162688
up_is_down = NO
geheugen vrij color_setup 114928
geheugen vrij writer 105360
geheugen vrij fplot 89632
geheugen vrij fonts 72064
geheugen vrij colors 71856
geheugen vrij refresh 71840
geheugen vrij label 67264
geheugen vrij textbox 63328
Orientation: Horizontal. Reversal: False. Width: 320. Height: 240.
Start row = 0 col = 0
geheugen vrij text 54736

If the bulk of the RAM use is in the application then trawling the code for optimisations is the way forward.

i'm trying to improve on what i scripted this far, not only improving functions also things like either dropping Textbox or Label, for a few kb extra.
but i'm no trained professional, just very creative ;)
as for freezing, i hope i can get that working this week, only got errors until now and that's further than i have come yet, so there is still hope.

[peterhinch]

Given your display is 240x320 I'd guess it's an ILI9341. The driver for that is 4 bits so the size in bytes of the frame buffer is 240*320/2=38400. This is created when you import color_setup, when your RAM drops by 47760 bytes. The extra bytes lost are in the creation of an ssd instance. Fonts are using 17,568 bytes - a loss which will vanish if they are frozen.

You could rewrite the driver to scale the display by 2 - this would reduce the buffer to 9600 bytes, saving 28,800 bytes. However freezing bytecode would save you more, without loss of functionality. Note that, with frozen bytecode, nano_gui has run on an ESP8266, albeit with a smaller display.

[TLmv]

peterhinch, thank you for that explanation. i will keep trying to freeze it...

i came close with what beetlegigg posted, no errors up until
make BOARD=PICO_W
it states a freeze error and there is a mistake in my manifest file, no such file or directory....but i'm sure there is and the path reads correct.
for some reason it wouldn't include the whole gui folder, but i got it working with only the 2 fonts and now the free memory is 56KB! so thank you both for helping me with this, i am confident i'll expand my script and freeze some more :)

[beetlegigg]

@TLmv
Woops, my notes may were not entirely accurate as to the directory structure I had on disk. Now Iooking at my pi where I done the custom build I see in my /home/pi/mp_nano_gui directory I had the following structure. (I missed the sub dir GUI and went straight for the Sub Sub dirs in my note. I hope I did not confuse too much, and its seems you are almost there 👍

[TLmv]

@beetlegigg
my directory structure is the same, i guess there are a few things in there that don't want to be frozen.
but even if it's only the fonts, it's fine with me. the pico is definately loving it.

i do have some strange behaviour that i have to check: if i include writer in the frozen build, the 35px font is no longer displayed while the script still works.

@peterhinch
i do see more failed reads on the onewire sensors since i froze the lettertypes, could this be related?

[peterhinch]

A simple approach to freezing is to put a symlink to the gui directory into the directory containing other frozen files.

There should be no problem freezing writer.py. I have done a lot of development with microgui where the entire gui tree is frozen. The commonest reason for a font to fail to be rendered is a poor choice of foreground color (e.g. same as background).

I can't think of any reason why onewire should be affected. nanogui is entirely synchronous code and uses no timers or interrupts. Therefore at the time when you are accessing OneWire nanogui is inactive. Further, I've never encountered a case where freezing affected timing. That said, I've not found the source of the firmware-based _onewire module so I don't know how it works.

[TLmv]

by now freezing had worked out for the gui folder and i have made some other improvements in the script, resulting in a low of 68kb just after writing to screen.

normally if i place a new uf2 file, i have to re-upload my data to the pico.
however, if i place a 'dirty' version on there, the original files remain
there was still a file left with the wrong path, because i had frozen single files without folder structure.
leading to the, still available, gui folder, resulting in a non display of data without crashing the script.

as for the onewire trouble, it wasn't related to when it was happening.
i use a cat 5e cable for connecting the pico to the sensors and relais card and that hadn't had any interference trouble before.
my 12c relay card was standing close to one of the sensor wires since the last test. and that appeared the failing sensor.

since i've placed it some 30 cm further from the sensor wire the problem appears solved or at least happens only incidently.
so I think i'm going to line the 12c relay chip with an aluminum hat [nutter smiley] to see if that makes it less noisy....