MemoryError: memory allocation failed, allocating 2048 bytes - LOPY - 1.2.0.b1

[robert-hh]

At first glance, everything should be there. Next step: I will try to add these to lines to mpconfigport.h:

#define MICROPY_MODULE_FROZEN_MPY           (1)
#define MICROPY_QSTR_EXTRA_POOL             mp_qstr_frozen_const_pool

That activates the required code in pyexec.c. Maybe then, a load error pops up, and I'll seet further.

[robert-hh]

@Shaun: This one worked for me:

In mpconfigport.h, goto the line

#define MICROPY_MODULE_FROZEN (0)

and change it to the three lines:

#define MICROPY_MODULE_FROZEN (1)
#define MICROPY_MODULE_FROZEN_MPY (1)
#define MICROPY_QSTR_EXTRA_POOL mp_qstr_frozen_const_pool

Then, put your python code like before into the directory modules and run:
make FROZEN_MPY_DIR=modules BOARD=LOPY

[Shaun]

@robert-hh
I duplicated the steps you have listed and all appeared to work correctly.
The *.py files were converted to *.mpy files and then frozen and compiled into an object file, frozen_mpy.o
That file has been linked into the final image and the module does not give an import error, so is very much part of the image.

But I get errors like;

File "main.py", line 28, in <module>
TypeError: 'int' object is not callable
MicroPython v1.8.6-412-gf55ba50-dirty on 2017-02-10; LoPy with ESP32

and if I use dir(my_module) the listed content is not correct.

It is as if the frozen module content is in some way corrupted.

[robert-hh]

Hello @Shaun, That's strange. I used that method to embed two large scripts, a text editor and a set of unix--shell-like commands, which I typically have on all boards, and these work fine.
I'm using the latest available Lopy repository form this place: https://github.com/pycom/pycom-micropython.

>>> os.uname()
 (sysname='LoPy', nodename='LoPy', release='1.5.0.b2', version='v1.8.6-437-gea056e6-dirty on 2017-02-10', machine='LoPy with ESP32')

I guess you do that too. Did you use mpy-cross from the same build? I never had experienced that it make a difference, but you never know. Maybe it's a size issue. Did you try first with smaller files?
Although, the code I have embedded totals to about 750 lines, so it is not tiny.

[Shaun]

@robert-hh
I did have an issue compiling mpy-cross initially. (make -C mpy-cross)

In file included from ../py/parse.h:32:0,
from ../py/scope.h:29,
from ../py/emit.h:31,
from ../py/emitnative.c:50:
../py/obj.h:33:22: fatal error: esp_attr.h: No such file or directory
compilation terminated.

To fix this I ended up manually copying the
~/pycom-esp-idf/components/esp32/include/esp_attr.h
file into
~/pycom-micropython/py/esp_attr.h

Perhaps something is not correct?

[robert-hh]

Hello @Shaun, I recall something like that in the past. I think I did the same. Did you update the pycom-esp-idf too? You should.
And updating th esp-idf might have required deleting it and cloning again.

[Colateral]

@robert-hh With the latest release 1.6.7 are you able to run on fronzen bytecode?

[robert-hh]

@Colateral: No, I cannot. And since the repository is not updated, I cannot make a suitable build. That's kind of sad. I asked Daniel, and he said (as always) that they will do so soon. But like you asked, enabling pre-compiled or frozen bytecode is just a small change in mpconfigport.h, however at the cost of additional firmware code size (~2k).
It could be an issue of testing and support.

[Shaun]

I too require "frozen" code for my large application and hope the git repository will be updated and that "frozen" functionality will be available sooner rather than later.

I am ecstatic that the threading and GC issues have been resolved and that I can continue with development at this point ;-)

[Colateral]

@Shaun I can enumerate at least 5 active people from this forum that required the frozen functionality.