MicroPython Forum (Archive)

Hi,

I'm learning micro-python since... last weekend. So please excuse my stupid questions
I watched the amazing talk from Damien on code optimization and I tried to use mpy-cross (from the PiPy repo: https://pypi.org/project/mpy-cross/1.9.4/ to fit my board version) on my code and I was surprised to see that whatever the -X emit option I add (emit=native, emit=viper, emit=bytecode...), the resulting mpy file is strictly the same. That looks like magic... or buggy

Anything I missed ?

Thanks!

shazz

Any emitter besides bytecode requires to specify the target architecture. That is possible with version 1.10 via the -march keyword. Call mpy-cross --help to get the list of choices.

If I'm not wrong, as my board runs MicroPython v1.9.4-616-g41fb4d3-dirty on 2019-03-13; MEOWBIT with STM32F401xE, I need to use cross-mpy 1.9.4 right ?

And for this version there is no march option:

$ python -m mpy_cross --help
usage: C:\Backup\meowbit\micropython\apps\badapple\PC\.venv\lib\site-packages\mpy_cross\mpy-cross.exe [<opts>] [-X <implopt>] <input filename>
Options:
-o : output file for compiled bytecode (defaults to input with .mpy extension)
-s : source filename to embed in the compiled bytecode (defaults to input file)
-v : verbose (trace various operations); can be multiple
-O[N] : apply bytecode optimizations of level N

Target specific options:
-msmall-int-bits=number : set the maximum bits used to encode a small-int
-mno-unicode : don't support unicode in compiled strings
-mcache-lookup-bc : cache map lookups in the bytecode

Implementation specific options:
emit={bytecode,native,viper} -- set the default code emitter
heapsize=<n> -- set the heap size for the GC (default 1048576)

So the emit option cannot be used ?

The mpy-cross from PyPi will be targeted for the unix version of MicroPython.

If you build the firmware for your board, (or any STM32F4 board) then you'll get a version of mpy-cross which can generate the varioous outputs.

Unfortunately Kittenbot doesn't publish the code of their version of MicroPython... so unless I try to rebuild MicroPython for the STM32F401RET6, no way to get mpy-cross I guess.

Thanks! Makese sense now.

You can build micropython for the NUCLEO_F401RE and it will build an mpy-cross that should work for you (assuming you're using the same version of source code).

Thanks Dave, that helps, I was looking at which micropython/ports/stm32/boards/ templates I could use.

The NUCLEO_F401RE looks very similar. Should be enough for mpy-cross.

A little unrelated question, if I would like to build my own firmware and use the NUCLEO_F401RE as a base, do you think:

1.I can patch the mpconfigboard.h file and add MICROPY_HW_ENABLE_SDCARD ?
2. For the TFT Screen (ST7735), I can use the SPI class to test I can init and plot a few pixels ?

3. If this firmware doesn't fit, is there a chance to brick my board by flashing it ?

Thanks

Unfortunately as this is not actually a NUCLEO_F401RE board, I doubt this will work. The individual entries in BOARDS are typically highly specific to a given board even if they share the same CPU (e.g. the pin mappings will be different).

I noticed `MEOWBIT` in the version string. I had to look up what this is (looks really neat though!) but it would appear that it doesn't run straight MicroPython firmware -- it would appear that MicroPython is just one part of a larger firmware, which includes their own uf2 bootloader, make:code support, etc etc. (It doesn't appear that this firmware is open source (yet?) but I only spent a few mins looking).

It's pretty hard to completely "brick" a device, but:
- assuming you can find a way to flash firmware built from "main" Micropython via their bootloader (i.e. convert the micropython firmware image into something compatible with u2f), you should be able to recover by flashing their original firmware image (which doesn't appear to be available for download though?).
- you could flash it with SWD (e.g ST-LINK) directly, but then you're likely to overwrite their bootloader, so to recover fully you'd need their firmware.

And you'd be starting from scratch creating your own board definition (pin mappings, drivers, etc). I don't see schematics, etc, available so this could be difficult.

If you can find a copy of their firmware source, you'll be much better of working from there (and I guess rebasing their changes on top of MicroPython 1.10). (Hopefully they do that themselves soon!)

Ah I took a closer look at https://github.com/KittenBot/uf2-meowbit and understand better now -- looks like it works similar to the micro:bit -- make:code generates a uf2 file, and they've provided the micropython uf2 file. (On the micro:bit it's the same, except with .hex files instead, and there are tools for appending code to the micropython .hex file)

So yeah, using the pin mappings from https://github.com/KittenBot/uf2-meowbi ... it/board.h and if you can come up with a way to generate a uf2 file from the "main" MicroPython build with the right memory map to work with their bootloader layout, then it should be possible to make a regular MicroPython build and flash it. (And low risk of bricking it because you can always restore their meowpy.uf2 file).

But you'd be much better off trying to find their MicroPython repo

Hi Jimmo,

Yes you're right... that's not a baremetal micropython firmware, thanks for forcing me to re-arrange my brains
So yes I would need to generate a uf2 compatible with their loader.... pretty different than generating a micropython firmware.

I hope they will publish the source code of their version of micropython. Sometimes I feel the MIT license too permissive

Looking at their flasher gives some interesting hints on how heir board works:
- screen.c : the TFT ST7735 controller, SPI interface
- uf2cfg.h : about uf2 and hex.
- uf2hid.h: ?
- https://github.com/KittenBot/uf2-meowbit/tree/fat/uf2

Here is their micropython UF2 binary
meowpy.uf2

If I understand well, in this case, this is just an image of the flash no ? And there is a tool to convert UF2<->BIN