Skip to main content
Frozen Modules:
The custom made firmware mentioned in my previous blog includes a froze module CryptoXo, which is just a simple XOR encryption.

The esp8266 port does not support threading. I want to incorporate concurrent codes in esp8266, so I have modified uasyncio modules from two files; __init__.pt and core.py to one uasyncio.py file, and include a frozen uasyncio module for esp8266.

A micropython running on Unix is a nice thing to have. It is useful for developing and testing scripts. Of course, we can not test scripts using some specific parts of hardware boards' electronics.

Unix port micropython will find modules under the 1) current directory, 2) '$HOME/.micropython/lib' and 3) '/usr/lib/micropython'.

Nevertheless, all frozen modules are only visible in REPL. If you try to import a frozen module in a script executing outside of REPL then you will get an ImportError message.

A shebang micropython, that is to say, a script with #! execute mechanism, will not properly find a frozen module. The only way to import a module is by installing the module under any of the directories listed in sys.path.

Let say we have an executable script test_import_frozen_module.py:
#!/usr/bin/env micropython
import CryptoXo
print(dir(CryptoXo))

Running this script will result in:
$ ./test_import_frozen_module.py
ImportError message; no module named CryptoXo

Similarly with:
$ micropython test_frozen_import.py
ImportError message; no module named CryptoXo

Importing the script in REPL will work.

$ micropython
MicroPython v1.11-631-gb76f0a73b-kaki5 on 2019-12-09; linux version
Use Ctrl-D to exit, Ctrl-E for paste mode
>>> import test_import_frozen_module
['__class__', '__name__', '__file__', 'sha', 'Crypt']

However, there is a way to use the frozen modules in scripts directly.
Now this will work:
$ micropython -c "import test_import_frozen_module"
['__class__', '__name__', '__file__', 'sha', 'Crypt']

Therefore, we can make a shell command wrapper, say mp:
#!/bin/sh
micropython -c "import $1"

Save it under $HOME/bin and make it executable.

To run any script that uses frozen modules we need just to execute it using our wrapper.

$ mp test_import_frozen_module
['__class__', '__name__', '__file__', 'sha', 'Crypt']

Note that we drop the py extension.

We can also have a wapper script, say exe:
#!/bin/sh
/home/sharil/bin/micropython -c "exec(open('$1').read())"

 And running this wrapper,

$ exe test_frozen_import.py
['__class__', '__name__', '__file__', 'sha', 'Crypt']

The result is similar. The mp wrapper uses Python import mechanism, while in exe the python script is read and executed explicitly.

The mp wrapper has the same behavior as main.py with microcontroller boards. We will import our script in /pyboard/main.py startup script.

main.py:
import test_import_frozen_module

The shebang scripts run under the control of OS (example, Linux). All micropython script executing on a microcontroller run under the main application thread. The main thread is REPL.

Comments

Popular posts from this blog

Custom made - Sometimes, it is nice to be able to build custom made things. Thanks to Damien George and all the clever people at micropython.org for making it easy. So that, to custom build a micropython is not that difficult. Why do you want to build customize firmware anyway? Well, you might want to include some functionalities of your own and removed some functionalities from the standard distribution. The choices are there for you to make. I have a few changes that I want to make in micropython. version header -kaki5 (pronounce kaki-lima) an additional thread cleanup function for esp32 add frozen modules CryptoXo and uasyncio remove help, upip, and webrepl camera C module for esp32 camera board These are accomplished by modifying and adding files. py/makeversionhdr.py py/modthread.c extra/CryptoXo.py, extra/uasyncio.py, and manifest.py mpconfigport.h main.c and modcamera.c I also want to remove some modules specifically, help, upip, and webrepl from esp32...
Multi-threading : I previously used an uasyncio webcam server. This time around, I am testing a multi-thread webcam server. The result is promising. A multi-thread server seems to give a better throughput. The program logic is simpler when compared to the server based on uasyncio. The server is a four threaded application, two for port 80, one for port 81, and port 82 runs on the main thread, which blocks the REPL.  You can start a dedicated thread for port 82 if you do not want to block the REPL. I found pix/7 gives the best performance. A spe/2 will reduce the image size but give you a grayscale image. Please see my previous blog if all these seem mysterious to you. I have compiled a new firmware, MicroPython v1.11-571-g7e374d231.  You can download the new firmware from my repository at GitHub. The soft reset is not functioning properly. You need to do a hard reset. I also include four new functions in modcamera.c: pixformat agcgain aelevels aecvalue The pixfo...
Micropython - v1.11-498 introduced a few changes in the source-code directory structure. Changes to specific files, as previously described in esp32-cam , will no longer work. A simple working summary on how to build esp32-cam firmware is described below: Make a recursive copy of ports/esp32 to ports/esp32-cam, and you will need to modify the following files: 1) ports/esp32-cam/main.c 2) ports/esp32-cam/Makefile 3) ports/esp32-cam/modcamera.c 4) ports/esp32-cam/mpconfigport.h 5) ports/esp32-cam/boards/manifest.py 6) ports/esp32-cam/boards/sdkconfig.base Or, you can just download a precompiled Micropython v1.11-498 from firmware.bin at GitHub if you want to save some work. However, I encourage you to compile the firmware yourself. You will learn a lot and you can choose to modify anything to your liking. The modcamera.c includes something new. The still photo was taken using these settings; pix =8, con =2, qua =10, and spe =2. You will understand those parameters, later...