ulab, or what you will - numpy on bare metal

C programming, build, interpreter/VM.
Target audience: MicroPython Developers.
User avatar
rcolistete
Posts: 264
Joined: Thu Dec 31, 2015 3:12 pm
Location: Brazil
Contact:

Re: ulab, or what you will - numpy on bare metal

Post by rcolistete » Sun Jul 12, 2020 4:45 pm

Another option is to move the 'lwip' (a small independent implementation of the TCP/IP protocol suite) native module to FLASH_EXT.
Just add to line 51 of '../micropython/ports/stm32/boards/PYBD_SF2/f722_qspi.ld' :

Code: Select all

        *lib/lwip/*(.text* .rodata*)
So :
- writing firmware 'PYBD-SF2_lwip-2MB_v1.12-623-gf743bd3d2_20200712.dfu''' with .native module 'lwip' in FLASH_EXT (external 2 MB QSPI flash), 414.616 bytes are written to FLASH_APP (480 kB), so there are ((480*1024=491520) - 414616 = 76904) bytes free in FLASH_APP, enough for ulab;
- writing firmware 'PYBD-SF2_lwip-frozen-2MB_v1.12-623-gf743bd3d2_20200712.dfu''' with .native module 'lwip' and .py frozen modules in FLASH_EXT (external 2 MB QSPI flash), 388.136 bytes are written to FLASH_APP (480 kB), so there are ((480*1024=491520) - 388.136 = 103384) bytes free in FLASH_APP, enough for ulab.

I hope that 'lwip' module is not used during Pyboard D SF2W boot, so the boot time doesn't increase due to reading from the slower QSPI flash. The MicroPython main developers could confirm this behaviour.

So these 3 options allow to install full ulab :
- .py frozen modules;
- 'lwip' native module;
- py frozen modules + 'lwip' native module;
moved to FLASH_EXT (external 2 MB QSPI flash).
My "MicroPython Samples". My "MicroPython Firmwares" with many options (double precision, ulab, etc).

v923z
Posts: 149
Joined: Mon Dec 28, 2015 6:19 pm

Re: ulab, or what you will - numpy on bare metal

Post by v923z » Sun Jul 12, 2020 7:20 pm

rcolistete wrote:
Sat Jul 11, 2020 1:57 pm
@v923z, do you want that I post this as a GitHub issue ?
I don't quite know. I mean, this seems to be a distribution-specific problem. On ubuntu, I haven't had this issue, and no-one has mentioned any difficulties. But I am not trying to imply that you shouldn't bring it up on github, if you think that your mentioning it would have merit.

User avatar
pythoncoder
Posts: 4374
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: ulab, or what you will - numpy on bare metal

Post by pythoncoder » Mon Jul 13, 2020 4:41 am

@v923z This is a hardware issue with SF2W and SF3W Pyboard D. It doesn't affect the Unix build.

@rcolistete I think there are two options. Either it should be documented or it should be made standard behaviour on those particular boards. I've never noticed a performance hit, but I haven't actually measured it. The question is whether or not the speed of the bytecode interpreter is dominated by memory access time. The interpreter itself hasn't moved, only the bytecode.
Peter Hinch

v923z
Posts: 149
Joined: Mon Dec 28, 2015 6:19 pm

Re: ulab, or what you will - numpy on bare metal

Post by v923z » Mon Jul 13, 2020 4:47 pm

pythoncoder wrote:
Mon Jul 13, 2020 4:41 am
@v923z This is a hardware issue with SF2W and SF3W Pyboard D. It doesn't affect the Unix build.
I am not sure. According to the report on github, (https://github.com/v923z/micropython-ulab/issues/132), it is a glitch in the makefile. It seems to me that the makefiles don't contain the path of the required libraries.

User avatar
pythoncoder
Posts: 4374
Joined: Fri Jul 18, 2014 8:01 am
Location: UK
Contact:

Re: ulab, or what you will - numpy on bare metal

Post by pythoncoder » Tue Jul 14, 2020 5:06 am

Sorry, at cross purposes. I was referring to the issue with firmware size. There is evidently also something else (and above my pay grade) at play here.
Peter Hinch

v923z
Posts: 149
Joined: Mon Dec 28, 2015 6:19 pm

Re: ulab, or what you will - numpy on bare metal

Post by v923z » Tue Jul 14, 2020 7:39 pm

pythoncoder wrote:
Tue Jul 14, 2020 5:06 am
Sorry, at cross purposes. I was referring to the issue with firmware size. There is evidently also something else (and above my pay grade) at play here.
I can't really comment on the firmware size issue. I know that I can still compile for the pyboard, in fact, I still have something like a 100 kB empty flash space with ulab. But I understand that if you add other modules (or frozen bytecode), then it might become tight. This is exactly, why we decided to split up the code and modularise ulab.

User avatar
rcolistete
Posts: 264
Joined: Thu Dec 31, 2015 3:12 pm
Location: Brazil
Contact:

Re: ulab, or what you will - numpy on bare metal

Post by rcolistete » Wed Jul 15, 2020 10:14 pm

Created an issue in ulab GitHub repository because it also happens when using the official download of 'gcc-arm-none-eabi-10-2020-q2-preview-x86_64-linux.tar.bz2' (v10.1), so more users can experience this problem.
rcolistete wrote:
Sat Jul 11, 2020 1:57 pm
It took some hours to discover a bug/incompatibility between gcc-arm 10.1.0 and ulab+MicroPython. For example, using Manjaro Linux v20.0.3 and installing gcc-arm via 'arm-none-eabi-gcc v10.1.0-1' from oficial repository, it gives a link error :

Code: Select all

[stm32]$ make -j8 BOARD=PYBD_SF6 USER_C_MODULES=../../../ulab all
    ...
    Including User C Module from ../../../ulab/code
    ...
    LINK build-PYBD_SF6/firmware.elf
    arm-none-eabi-ld: build-PYBD_SF6/code/ulab.o:(.bss.ulab_extras_module+0x0): multiple definition of `ulab_extras_module'; build-PYBD_SF6/code/extras.o:(.data.ulab_extras_module+0x0): first defined here
    arm-none-eabi-ld: build-PYBD_SF6/code/ulab.o:(.bss.ulab_vectorise_module+0x0): multiple definition of `ulab_vectorise_module'; build-PYBD_SF6/code/vectorise.o:(.data.ulab_vectorise_module+0x0): first defined here
    make: *** [Makefile:605: build-PYBD_SF6/firmware.elf] Error 1
The solution was to use older versions of gcc-arm from GNU Arm Embedded Toolchain Downloads, e. g.,
'gcc-arm-none-eabi-8-2019-q3-update' or 'gcc-arm-none-eabi-9-2020-q2-update'. The 'gcc-arm-none-eabi-8-2019-q3' generates code a little bit smaller, so I've chosen it.

@v923z, do you want that I post this as a GitHub issue ?
My "MicroPython Samples". My "MicroPython Firmwares" with many options (double precision, ulab, etc).

User avatar
rcolistete
Posts: 264
Joined: Thu Dec 31, 2015 3:12 pm
Location: Brazil
Contact:

Re: ulab, or what you will - numpy on bare metal

Post by rcolistete » Wed Jul 15, 2020 11:38 pm

pythoncoder wrote:
Mon Jul 13, 2020 4:41 am
@v923z This is a hardware issue with SF2W and SF3W Pyboard D. It doesn't affect the Unix build.
Sorry for mixing different issues, which are 4 since page 7 of this topic :
- ulab issue #135, "Incompatibility between gcc-arm 10.1 and ulab+MicroPython", it is more a warning for the moment;
- ulab issue #132, "Error building/linking ulab with double precision float (FP64/DP)" & MicroPython PR#6242 "add round.c to libm_dbl", pending;
- ulab #133, "ulab not compatible with enabling '_thread' module from the make command", solved;
- Pyboard D SF2/SF3 internal 512 kB flash memory with not enough space left (41-42 kB) to fit 'ulab' module (44 kB) with all sub-modules. Solutions are :
* disable some 'ulab' sub-modules to fit 41 kB;
* move native or frozen modules from internal flash to 2 MB QSPI flash memory by editing MicroPython source code, '../micropython/ports/stm32/boards/PYBD_SF2/f722_qspi.ld' to free more space in internal flash for ulab.
My "MicroPython Samples". My "MicroPython Firmwares" with many options (double precision, ulab, etc).

User avatar
rcolistete
Posts: 264
Joined: Thu Dec 31, 2015 3:12 pm
Location: Brazil
Contact:

Re: ulab, or what you will - numpy on bare metal

Post by rcolistete » Wed Jul 15, 2020 11:51 pm

pythoncoder wrote:
Mon Jul 13, 2020 4:41 am
@rcolistete I think there are two options. Either it should be documented or it should be made standard behaviour on those particular boards. I've never noticed a performance hit, but I haven't actually measured it. The question is whether or not the speed of the bytecode interpreter is dominated by memory access time. The interpreter itself hasn't moved, only the bytecode.
I 100% agree with :
- better documentation of firmware building options for official MicroPython boards (like Pyboard D), like in "Building Micropython Binaries" wiki;
- comments with options to move code to QSPI flash memory, in '../micropython/ports/stm32/boards/PYBD_SF2/f722_qspi.ld', in line 51 :

Code: Select all

/*         *frozen_content.o(.text* .rodata*)*/ 

or

Code: Select all

/*        *lib/lwip/*(.text* .rodata*)*/
etc;
- or enabling one of the lines cited above.

I'll do some benchmarking of Pyboard D SF2 in the following week, maybe some timing measures can show how much a module in QSPI flash is slower (importing and running).
My "MicroPython Samples". My "MicroPython Firmwares" with many options (double precision, ulab, etc).

User avatar
rcolistete
Posts: 264
Joined: Thu Dec 31, 2015 3:12 pm
Location: Brazil
Contact:

Re: ulab, or what you will - numpy on bare metal

Post by rcolistete » Wed Jul 15, 2020 11:58 pm

v923z wrote:
Tue Jul 14, 2020 7:39 pm
I can't really comment on the firmware size issue. I know that I can still compile for the pyboard, in fact, I still have something like a 100 kB empty flash space with ulab. But I understand that if you add other modules (or frozen bytecode), then it might become tight. This is exactly, why we decided to split up the code and modularise ulab.
@v923z, the issue is not with Pyboard v1.11, which has approx. 557 kB free in internal flash memory with MicroPython v1.12, without 'ulab'.

The issue happens with Pyboard D SF2/SF3, with 512 kB internal flash memory, of which 480 kB as FLASH_APP, so only 41 kB is left with MicroPython v1.12, without 'ulab'. As Pyboard D SF2/SF3 has 2MB QSPI flash with 2048 kB as FLASH_EXT, with approx. 1.4 MB free, it is better to know how to move modules from internal to QSPI flash memory.
My "MicroPython Samples". My "MicroPython Firmwares" with many options (double precision, ulab, etc).

Post Reply