Executing frozen module code at REPL startup.

C programming, build, interpreter/VM.
Target audience: MicroPython Developers.
Post Reply
brianh
Posts: 3
Joined: Tue Jun 18, 2019 3:52 pm

Executing frozen module code at REPL startup.

Post by brianh » Tue Jun 18, 2019 4:28 pm

Hi. I am new to MicroPython and I've been experimenting with building and running (REPL) on an ARMv6. I'm sure I am misunderstanding some basic concepts re: frozen modules. What I want to do is have a simple uPy boot script that is frozen and which executes before I enter the REPL. The primary goal is just to pre-define some convenience functions in uPy that can be used from the REPL and without even having to type 'import blah...' to enable them.

The problem is that if I freeze the uPy function definitions directly, it doesn't work at all. None of the functions are available at the REPL prompt. However, somewhat strange to me, is that I can freeze a module that executes a module on the disk and it works fine.

So, assume my functions are defined in 'conv-func.py'. If I create a 'boot.py' containing:
exec(open("conv-func.py").read())

Then, I can add 'boot.py' as a frozen module and in my C code I do:
pyexec_frozen_module("boot.py")
pyexec_friendly_repl()
This works fine, and my convenience functions are immediately available in the REPL, having beed defined by executing the script from disk.

BUT, if I try just adding 'conv-func.py' as the frozen module and in my C code using pyexec_frozen_module("conv-func.py"), then it doesn't seem to work and the functions are undefined until I 'import conv-func'. Is there a reason that it works this way?

I'm glad I have this relatively simple workaround, but it seems to unnecessarily complicate the process. I'm also not sure it can be solved by freezing both modules and using one to import the other. I might be stuck with having the main functionality needing to be loaded from disk, which is definitely problematic.

Any advice to simplify, or just fix my flawed understanding of frozen module, would be appreciated.

User avatar
jimmo
Posts: 328
Joined: Tue Aug 08, 2017 1:57 am
Location: Sydney, Australia

Re: Executing frozen module code at REPL startup.

Post by jimmo » Wed Jun 19, 2019 12:48 am

I'm not 100% sure this is relevant, but which type of frozen modules are you using? (i.e. are you defining FROZEN_DIR or FROZEN_MPY_DIR).

User avatar
dhylands
Posts: 3199
Joined: Mon Jan 06, 2014 6:08 pm
Location: Peachland, BC, Canada
Contact:

Re: Executing frozen module code at REPL startup.

Post by dhylands » Wed Jun 19, 2019 1:26 am

On my pyboard I put the following boot.py file into the modules directory:

Code: Select all

print('Executing frozen boot.py')

def myfunc():
    print('Executing myfunc')
When I boot the board, I see this:

Code: Select all

Executing frozen boot.py
MicroPython v1.11-47-g1a51fc9dd on 2019-06-18; PYBv1.1 with STM32F405RG
Type "help()" for more information.
>>> 
and then I can execute myfunc without having to import anything:

Code: Select all

>>> myfunc()
Executing myfunc

brianh
Posts: 3
Joined: Tue Jun 18, 2019 3:52 pm

Re: Executing frozen module code at REPL startup.

Post by brianh » Wed Jun 19, 2019 3:22 pm

Yep, that's exactly what I want. Well now that I know it is suppose to work, I need to look more deeply into my build scripts to see where the code is (probably) misconfigured. I don't have a pyboard, but I'll try to reproduce your results in ports/unix, then use that as a basis to compare to my ARM build, which I derived starting from ports/minimal. But I've made numerous changes to the configuration in mpconfigport.h, and probably broken frozen module somehow.

I'll report back my findings.

brianh
Posts: 3
Joined: Tue Jun 18, 2019 3:52 pm

Re: [SOLVED] Executing frozen module code at REPL startup.

Post by brianh » Wed Jun 19, 2019 4:01 pm

Thanks for the feedback, gentleman. Lo and behold, it is working fine for me now.

I didn't change anything and the frozen module is now running fine at startup and defines my convenience functions as desired, without resorting to the exec() workaround. The only thing I can figure is that I had messed up my frozen module during experimentation with the "-X emit=native" switch of the 'mpy-cross' tool. A fresh build of the module, not using -X, and it works fine.

Best.

Post Reply