Part of script wont run when named main.py or boot.py

[LeafTeaNeko]

Hi micropython team,

I am using a RaspiPico W RP 2040 with micropython and this is the script Im trying to autorun when Pico is powered. I plan on powering the pico with an external power brick.
The script is a multithreading process which runs a server on one thread to receive data on the socket while the other thread drives the display.
I can get the script to work with Thonny and I can see normal output but when I name it boot.py or main.py, I see no output. Somehow I can still send messages to the webserver on the Pico. What am I doing wrong that it only works when connected to Thonny?

import _thread
from time import sleep
from machine import Pin, SPI
from gc import collect
import jpegdec
from pimoroni_bus import SPIBus
from picographics import PicoGraphics, DISPLAY_PICO_DISPLAY, PEN_RGB332
from web_test import connect_WLAN, open_socket, data_poll
import st7789py


spLock = _thread.allocate_lock() # creating semaphore
global data_buffer
data_buffer = []


def init_display():
# Incase picographics fails to initalise the display, use ST7789py driver to initiate display
    try:
        screen_width = 135
        screen_height = 240
        screen_rotation = 1
        spi = SPI(1, baudrate=31250000, polarity=1, phase=1, bits=8, firstbit=SPI.MSB, sck=Pin(10), mosi=Pin(11))
        screen = st7789py.ST7789(spi, screen_width, screen_height, reset=Pin(12, Pin.OUT), cs=Pin(9, Pin.OUT), dc=Pin(8, Pin.OUT), backlight=Pin(13, Pin.OUT), rotation=screen_rotation)
    except:
        print("failed display initialzation")
    
    spibus = SPIBus(cs=9, dc=8, sck=10, mosi=11)
    display = PicoGraphics(DISPLAY_PICO_DISPLAY, bus=spibus, pen_type=PEN_RGB332, rotate=180)
    return display



def image_screen(path, max_images):
    spLock.acquire() # acquiring semaphore
    display = init_display()
    display.clear()
    collect()
    j = jpegdec.JPEG(display)
    for n in range(1, max_images):
        j.open_file(path + str(n)+".jpeg")
        j.decode(0, 0, jpegdec.JPEG_SCALE_FULL)
        display.update()
        sleep(0.3)
    spLock.release()


def text_screen_list():
    spLock.acquire() # acquiring semaphore
    over_temp_flag = False
    display = init_display()
    WIDTH, HEIGHT = display.get_bounds()
    WHITE = display.create_pen(255, 255, 255)
    display.clear()
    try:
        data_package = eval(data_buffer)
        display.set_pen(WHITE)
        display.set_font("bitmap8")
        if int(data_package[0])>39:
            over_temp_flag = True
        display.text(("CPU:   "+data_package[0]), 0, 0, WIDTH, 3)
        display.text(("GPU:   "+data_package[1]), 0, 25, WIDTH, 3)
        display.text(("M.2:   "+data_package[2]), 0, 50, WIDTH, 3)
        display.text(("MAS:   "+data_package[3]), 0, 75, WIDTH, 3)
        display.update()
        sleep(1) #keep the numbers on the screen
    except:
        pass
    
    spLock.release()
    collect()
    return over_temp_flag

def engage_screen():
    while True:
        for _ in range(3):
            over_temp_flag = text_screen_list()
            collect()
        if over_temp_flag is True:
            image_screen("/boost/image", 5)
        else:
            image_screen("/idle/image", 5)
    return None

second_thread = _thread.start_new_thread(engage_screen, ())

def core1_thread():
    global data_buffer
    connect_WLAN()
    comm_socket = open_socket()
    while True:
        data_buffer = data_poll(comm_socket)
        collect()
    return None

print("Resuming Core0 processes")
core1_thread()

More details:
Display: https://www.waveshare.com/wiki/Pico-LCD-1.14#Run_in_Raspberry_Pi
firmware: pimoroni-picow-v1.19.2-micropython.uf2
https://github.com/pimoroni/pimoroni-pico/releases

[peterhinch]

In general the best approach is to save your program under a different name, say test.py. This enables you to test it by issuing

import test

When it's fully working, then edit main.py as follows:

import time
time.sleep(3)
import test

I find the delay useful in the case where something goes wrong and the program locks up the device. It gives you time to reset the device and issue ctrl-c to regain control.

[LeafTeaNeko]

Thank you for the insight, I tried this approach and now all of a sudden my old code has started to throw memory allocation errors haha

[LeafTeaNeko]

Wait no, nevermind, that seems to help! How can this be? as far as I understand its the same thing, right? You're calling the same functions just under a different script. How is this different from defining these functions under main and starting them? Could you elaborate on the answer?

[karfas]

I can get the script to work with Thonny and I can see normal output but when I name it boot.py or main.py, I see no output

Do you mean "output to the display" or "REPL output" ?

In my opinion, you can't trust thonny (or any other colorful IDE) when you want to know what really happens on the board.

Use pyshell or mpremote to verify that your script has been copied to the device (and there are no older boot.py/main.py versions left).
Use pyshell, mpremote or putty to see the REPL output.

[LeafTeaNeko]

Verified that main is indeed in the directory

[scruss]

In my opinion, you can't trust thonny (or any other colorful IDE) when you want to know what really happens on the board.

Thonny's Files view is as reliable as any other way of seeing flash filesystem status. Unless you have evidence of it using a different file display mechanism from the other tools?

[karfas]

@scruss: I don't use Thonny and have no reason to question it's file view.
The comment was more aimed at the usage of Thonny as the only source of REPL output, especially for problems like the one in this thread.
Using e.g. putty is the most transparent way to connect to an embedded device nowadays, as not too many people are lucky enough to own a physical VT220 terminal and an UART/RS232 converter. With Thonny and other IDEs you need to be aware of all things the IDE does (e.g. the time setting thing that comes up once a month or so).

[peterhinch]

If I can offer another general comment. This isn't intended as a criticism of Thonny or any other IDE, but an IDE is another layer of software which has the potential for problems. I think is the point being made by @karfas.

When confronted with a puzzling problem I recommend using the simplest, most reliable, tools available to access the device under test. In my opinion these are official mpremote and unofficial rshell; in extremis I use a terminal emulator - my choice is miniterm.py.

[LeafTeaNeko]

Thank you for the suggestions everyone, I will keep in mind to use the REPL more often.

[LeafTeaNeko]

As an update to the problem, I have it named boot.py and now it will boot right into the script but the script now encounters memory allocation errors more often.
Would the autorun cause some kind of processing overhead causing more memory issues? or is there another explanation for it?

[robert-hh]

Would the autorun cause some kind of processing overhead causing more memory issues?

No. But to be sure to have the best state of the heap, call gc.collect() at the start of the script.