ulab for ESP8266

[v923z]

I am not against posting the instructions on https://github.com/v923z/micropython-ulab/. Raise an issue, if you want to do that!

If the PR#6284 is merged, then the instructions to compile MicroPython for ESP8266 + ulab will be very simple : use ulab >= 0.54.0 & MicroPython newer than 'some date'.

This might be a thorny issue, and I was wondering, whether we could do that on ulab's side. Can we insert linker instructions in the make fragment https://github.com/v923z/micropython-ul ... opython.mk ?

The FFT takes place in place, so as long as you can fit your data (watch out for the imaginary part!) in RAM, you should be fine. I only use a couple of bytes for temporary variables. 4096 points might be a bit tight, though.

After FFT with 2048 points, the free RAM on ESP8266 (WeMos D1 Mini) & MicroPython v1.12 2020-07-24 is very small, just 2800 bytes (from 35968 bytes of free RAM after boot/restart).
So no way to run FFT with 4096 bytes on MicroPython for ESP8266.

I see. Has the ESP8266 double or float implementation?

[rcolistete]

I am not against posting the instructions on https://github.com/v923z/micropython-ulab/. Raise an issue, if you want to do that!

If the PR#6284 is merged, then the instructions to compile MicroPython for ESP8266 + ulab will be very simple : use ulab >= 0.54.0 & MicroPython newer than 'some date'.

This might be a thorny issue, and I was wondering, whether we could do that on ulab's side. Can we insert linker instructions in the make fragment https://github.com/v923z/micropython-ul ... opython.mk ?

I don't know if it is possible or how to make linker instructions in "micropython.mk" ulab file, complementing the file "micropython/ports/esp8266/boards/esp8266_common.ld".

One option is to insert "ICACHE_FLASH_ATTR" decorator before the declaration of all C functions of the module. See :
- "micropython/ports/esp8266/esppwm.c" and "micropython/ports/esp8266/uart.c";
- "ESP8266, D1 and the esp-open-sdk";
- "The ESP8266 -- What goes where?";
- "Guidelines for writing code for the ESP8266".

Maybe an option would be :
- to implement all ulab functions with "ICACHE_FLASH_ATTR" decorator;
- detect when not building for ESP8266, then "ICACHE_FLASH_ATTR" decorator could be set as empty.

I prefer to add 1 single line in "micropython/ports/esp8266/boards/esp8266_common.ld".
Not just that, I prefer to have ulab builtin in many MicroPython firmwares (with enough space) : Pyboard v1.11, Pyboard D, ESP8266 with >= 2MB flash, ESP32, etc.

[rcolistete]

I see. Has the ESP8266 double or float implementation?

No, MicroPython for ESP8266 is fixed with single precision for float point numbers (SP/FP32).
See this topic, "double precision float on ESP8266".
"micropython/ports/esp8266/mpconfigport.h" has the line :

Code: Select all

#define MICROPY_FLOAT_IMPL          (MICROPY_FLOAT_IMPL_FLOAT)

but changing the value to "MICROPY_FLOAT_IMPL_DOUBLE" yields many compile errors. So the MicroPython mainline for ESP8266 isn't ready to compile with double precision (for floats, FP64).

I'm interested to have MicroPython on ESP8266 with FP64, but I don't know the work needed to modify the source code to bring this support. I'll leave it as low priority task to try one day.

[v923z]

Maybe an option would be :
- to implement all ulab functions with "ICACHE_FLASH_ATTR" decorator;
- detect when not building for ESP8266, then "ICACHE_FLASH_ATTR" decorator could be set as empty.

I am not sure it is an elegant solution. What happens, if some other platform requires other kind of decorators? I think compilation issues have to be handled either in the main, or in make files, and the ulab code itself should be platform-independent.

I prefer to add 1 single line in "micropython/ports/esp8266/boards/esp8266_common.ld".

If so, you could try to convince the micropython maintainers to provide a tool that would overriding of the linker options possible. I believe, all that would be required is that at the beginning of the make process, you should be able to/allowed to run your own script that could modify the Makefile, the linker scripts, or whatever. This could be a rather universal solution, and it would also eliminate the need for modifications of the micropython main for each user library.

I see that you are passionate about bringing ulab to the ESP8266. So am I, but we also have to keep in mind that micropython itself should not be steered by external libraries. There should be tools to make the inclusion of third-party components possible, but everything else should he done on the library's side.

If you want to make ESP8266 with ulab available for everyone, you should simply write and publish a script that modifies the above-mentioned three files, and then you are done. We can do that in the ulab repository, if you would like.

Not just that, I prefer to have ulab builtin in many MicroPython firmwares (with enough space) : Pyboard v1.11, Pyboard D, ESP8266 with >= 2MB flash, ESP32, etc.

I think the cleanest way is to compile the firmware yourself, if you need ulab. The problem is that there are other user modules out there, and you can't possibly put everything in the "official" firmware. But if it is so, who should choose the packages? Even on a computer, python is in every linux distribution, but you have to install numpy separately. And what should happen, if the modification of an external module breaks the compilation process? Whose responsibility will it be to fix the problem?

Also, even the pyboard has many options that you can switch off (like support for SD card, user switch, LEDs, etc.) to save space. I also made ulab highly configurable, because I do know that there are situations, when flash space is an issue.

[v923z]

I see. Has the ESP8266 double or float implementation?

No, MicroPython for ESP8266 is fixed with single precision for float point numbers (SP/FP32).

This sort of makes sense now: for each FFT, there are four arrays: real and imaginary inputs, and real and imaginary outputs. So, with 2048 points, you have to store 8192 numbers, and that is 32278 bytes.

One could, in principle, overwrite the input arrays, but that would be a departure from numpy's convention.

[rcolistete]

I'll later (time to sleep...) describe the needed changes in '...esp8266/Makefile' and '...esp8266/mpconfigport.h', make a "README.md" in the repository below, etc.

I've added documentation and 2 versions of MicroPython firmware for ESP8266 with ulab, for >= 2 MB of flash and 1 MB of flash (with reduced filesystem) :
MicroPython v1.12 firmwares with 'ulab' module for ESP8266
Firmwares for MicroPython on ESP8266

[rcolistete]

If you want to make ESP8266 with ulab available for everyone, you should simply write and publish a script that modifies the above-mentioned three files, and then you are done. We can do that in the ulab repository, if you would like.

The branches that I'm citing have the modifications listed. Anybody can use the branch (easier) or copy the changes and manually edit the files. It would better to have mainline support, of course.

I think the cleanest way is to compile the firmware yourself, if you need ulab.

I disagree. The large majority of MicroPython users don't know/have time/interest to compile firmware. Part of them have interest in using ulab.

IMHO, it is important to promote ulab by listing (in ulab repository & docs) :
- the MicroPython variants which adopted ulab module built-in :
* CircuitPython firmware >= v5.1.0 (2020-04-02);
* OpenMV Cam firmware >= v3.5.0 (2019-11-04);
* MicroPython for K210 Lobo firmare >= v202002;
so some users will simply buy and use (Micro/Circuit)Python boards because of the built-in ulab support and other features;
- firmwares with ulab built by the community.

[v923z]

I think the cleanest way is to compile the firmware yourself, if you need ulab.

I disagree. The large majority of MicroPython users don't know/have time/interest to compile firmware. Part of them have interest in using ulab.

Well, we can agree to disagree. You can produce firmware with ulab, but that might not include threading, or SD card support etc. I see your point about the inexperience of the users, but compiled firmware will always be out of sync with either micropython, or third-party libraries.

If you want to go down that path, you have to somehow automate your compilation process, so that new firmware is generated, when the source code changes.

- the MicroPython variants which adopted ulab module built-in :
...

We can compile a list in the readme, if you want: https://github.com/v923z/micropython-ul ... /README.md

[rcolistete]

Well, we can agree to disagree. You can produce firmware with ulab, but that might not include threading, or SD card support etc. I see your point about the inexperience of the users, but compiled firmware will always be out of sync with either micropython, or third-party libraries.

Yes, I agree that it is impossible to cover all possible options when building a firmware (SP/DF, threads, FAT/LittleFS, btree or not, filesystem or not, ulab or not, etc). But look at Pyboard download page, it has the main configurations (SP, DP, SP + threads, DP + threads, SP + network) so lot of users can experience double precision, threads, etc.

If you want to go down that path, you have to somehow automate your compilation process, so that new firmware is generated, when the source code changes.

I've made local scripts to automate Pyboard firmware building, with more than 40 variants (SP/DP, threads, network, ulab). The next step would be to use GitHub/GitLab automatic tools, but I need to learn them...

- the MicroPython variants which adopted ulab module built-in :
...

We can compile a list in the readme, if you want: https://github.com/v923z/micropython-ul ... /README.md

I can submit a PR with this and other minor documentation fixes.

[v923z]

Well, we can agree to disagree. You can produce firmware with ulab, but that might not include threading, or SD card support etc. I see your point about the inexperience of the users, but compiled firmware will always be out of sync with either micropython, or third-party libraries.

Yes, I agree that it is impossible to cover all possible options when building a firmware (SP/DF, threads, FAT/LittleFS, btree or not, filesystem or not, ulab or not, etc). But look at Pyboard download page, it has the main configurations (SP, DP, SP + threads, DP + threads, SP + network) so lot of users can experience double precision, threads, etc.

That's right, but those options are all under the control of micropython itself. ulab is a third-party library, and that changes the equation.

If you want to go down that path, you have to somehow automate your compilation process, so that new firmware is generated, when the source code changes.

I've made local scripts to automate Pyboard firmware building, with more than 40 variants (SP/DP, threads, network, ulab). The next step would be to use GitHub/GitLab automatic tools, but I need to learn them...

You could ask the e.g., the circuitpython people, who do this on a large scale. But as far as I see, they use a service external to github.

- the MicroPython variants which adopted ulab module built-in :
...

We can compile a list in the readme, if you want: https://github.com/v923z/micropython-ul ... /README.md

I can submit a PR with this and other minor documentation fixes.

I have already added a list: https://github.com/v923z/micropython-ul ... /README.md, but if you have other suggestions, I am listening.