8000 Freezing resources that are not Python scripts · Issue #5394 · micropython/micropython · GitHub
[go: up one dir, main page]
Skip to content

Freezing resources that are not Python scripts #5394

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
RJSDevel opened this issue Dec 7, 2019 · 6 comments
Open

Freezing resources that are not Python scripts #5394

RJSDevel opened this issue Dec 7, 2019 · 6 comments
Labels
enhancement Feature requests, new feature implementations

Comments

@RJSDevel
Copy link
RJSDevel commented Dec 7, 2019 •
edited
Loading

I want to flash modules with html files together, but I can't read them.
e.g list
_boot.py
public/index.html

I modified makemanifest.py to pass other files types as path, I cheked existing it in the firmware.elf, and it exist, but I cant read it for send by http

May be exist way for read those files or what sorces can I modify for get this possibility?
@jimmo
Copy link
Member
jimmo commented Dec 7, 2019

This is possibly a longer-term feature for the manifest system, but not currently implemented. At the moment it only generates frozen modules (with optional compiling to bytecode first).

The code that loads modules at runtime (i.e. the import statement) then preferentially finds these frozen modules before looking on the filesystem. However the filesystem itself is totally separate and not part of the firmware image.

It is possible however to construct a filesystem and append it to the firmware image. See for example https://forum.micropython.org/viewtopic.php?f=16&t=6677 for some general ideas but also at the end of the thread there's an ESP8266-specific example of doing this all automatically.

@peterhinch
Copy link
Contributor

This utility enables an arbitrary file to be converted to Python source which can be frozen.

@dpgeorge dpgeorge added the enhancement Feature requests, new feature implementations label Dec 9, 2019
@dpgeorge dpgeorge changed the title How to access modules files? Freezing resources that are not Python scripts Dec 9, 2019
@RJSDevel
Copy link
Author
RJSDevel commented Dec 9, 2019

This is possibly a longer-term feature for the manifest system, but not currently implemented. At the moment it only generates frozen modules (with optional compiling to bytecode first).

The code that loads modules at runtime (i.e. the import statement) then preferentially finds these frozen modules before looking on the filesystem. However the filesystem itself is totally separate and not part of the firmware image.

It is possible however to construct a filesystem and append it to the firmware image. See for example https://forum.micropython.org/viewtopic.php?f=16&t=6677 for some general ideas but also at the end of the thread there's an ESP8266-specific example of doing this all automatically.

I think this is right way. Thank you!

@TravisJoe
Copy link

I have done something based on Peter's solution which has worked quite well for me. Plus easily do dynamically build and move into my frozen file directory when building the firmware.

@jedie
Copy link
Contributor
jedie commented Jan 8, 2020

It is possible however to construct a filesystem and append it to the firmware image. See for example https://forum.micropython.org/viewtopic.php?f=16&t=6677 for some general ideas but also at the end of the thread there's an ESP8266-specific example of doing this all automatically.

That sounds as the best way. Would be great if this is doable in the normal micropython build pipeline.

It would also be good not only not to transfer non-py files on the device, but also to avoid having to create the filesystem on the first startup e.g. with inisetup.py.

I see the advantages over Peter's solution in the fact that you can open the files normally. So it is also possible to change the files, like all normal files.

@peterhinch
Copy link
Contributor

I see the advantages over Peter's solution in the fact that you can open the files normally. So it is also possible to change the files, like all normal files.

That is true, and there are applications for a filesystem populated at build time. The approaches have different benefits and drawbacks.

My approach has the following benefits, especially if you need random access e.g. for fonts:

  1. If the frozen Python code supplies a memoryview into a bytes object, RAM usage can be almost zero (mutable objects must be located in RAM).
  2. Accessing a memoryview slice into a bytes object in flash is much faster than a seek into a random access file.

The immutability of frozen bytecode is therefore both a benefit and a limitation.

tannewt added a commit to tannewt/circuitpython that referenced this issue Oct 13, 2021
@tannewt
Merge pull request micropython#5394 from microDev1/c3-port
fab27f6 
Add initial esp32c3 support
@jimmo jimmo mentioned this issue Aug 25, 2022
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement Feature requests, new feature implementations
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@jedie @TravisJoe @jimmo @dpgeorge @peterhinch @RJSDevel
0