mpy-cross configuration for RP2350?

[SteKme]

Hi,

please does MPY cross compiler already support RP2350? Is there a way to generate valid MPY files for 2350?

For RP2040, the architecture switch is '-march=armv6m', however RP2350 ?probably? is Armv8-M - and at least at this moment, the page
https://pypi.org/project/mpy-cross/#description
doesn't list this architecture in 'mpy-cross options' section.

Thanks so much,
Stepan

[peterhinch]

Have you tried armv7m?

[SteKme]

apologies @peterhinch for me not being able to read between lines :-)

does it mean that armv7m is THE suggested and correct setting -- or You believe it might work (but not certain about it)?

According to e.g.
https://medium.com/@wassimdhokkar/arm-architecture-what-are-the-differences-between-armv7-and-armv8-arm-architectures-9a80cea35596
it appears v8 has extra features that, indeed, might not be related to MPY bytecode. Of course, I'd better avoid unexpected quirks caused by a wrong architecture MPY, I already have full hands of rather complicated issues anyway.

Best,
Stepan

[peterhinch]

I think it's worth a try. Pyboards support the Arm Thumb V7 instruction set. V8 is presumably a superset of V7 but I'm not aware of the MP compiler emitting any V8 opcodes.

I have done a brief test. In this demo I added the native decorator as follows. The function was chosen for being reasonably involved and using FP maths.

@micropython.native
async def aclock(dial, lbldate, lbltim):
    # Return a unit vector of phase phi. Multiplying by this will
    # rotate a vector anticlockwise which is mathematically correct.
    # Alas clocks, modelled on sundials, were invented in the northern
    # hemisphere. Otherwise they would have rotated widdershins like
    # the maths. Hence negative sign when called.
    def uv(phi):
        return rect(1, phi)

    def suffix(n):
        if n in (1, 21, 31):
            return "st"
        if n in (2, 22):
            return "nd"
        if n in (3, 23):
            return "rd"
        return "th"

    days = ("Mon", "Tue", "Wed", "Thu", "Fri", "Sat", "Sun")
    months = ("Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec")

    hrs = Pointer(dial)
    mins = Pointer(dial)
    secs = Pointer(dial)

    hstart = 0 + 0.7j  # Pointer lengths. Will rotate relative to top.
    mstart = 0 + 1j
    sstart = 0 + 1j

    while True:
        t = time.localtime()
        hrs.value(hstart * uv(-t[3] * pi / 6 - t[4] * pi / 360), CYAN)
        mins.value(mstart * uv(-t[4] * pi / 30), CYAN)
        secs.value(sstart * uv(-t[5] * pi / 30), RED)
        lbltim.value("{:02d}.{:02d}.{:02d}".format(t[3], t[4], t[5]))
        lbldate.value(
            "{} {}{} {} {}".format(days[t[6]], t[2], suffix(t[2]), months[t[1] - 1], t[0])
        )
        await asyncio.sleep(1)

I compiled the file using march=armv7m, renamed the .py file, and the demo ran correctly. Hardware was a Pico 2.

[SteKme]

thank You, Peter, for Your help!

[jkorte-dev]

From reading sys.implementation._mpy rp2350 should be arch armv7emsp.

I compiled a native c module for this target arch and could load it on the rp2350 (latest micropython) so far as expected, but I made a strange observation:
the module has two functions: one calculates the mandelbrot set with float the other with fixed point arithmetic. The float calculation does not work any more but the fixed point calculation does. The same code worked before with the same target arch (armv7emsp) on stm32f411 and stm32h723 (but micropython 1.21 and 1.22) . I upgraded the stm32f411 to micropython-1.25-preview and tried the same mpy module again and the float was correct. any ideas?

mpremote run show_mpy_sys_version.py
mpy version: 6
mpy sub-version: 3
mpy flags: -march=armv7emsp

micropython show_mpy_mod_version.py ../boards/rp2350/mandelbrot-1.24-armv7emsp.mpy
mpy version: 6
mpy sub-version: 3
mpy flags: -march=armv7emsp

[SteKme]

@jkorte-dev so if I understand, You're able to exec MPY file created with armv7emsp target, but floating point arithmetic runs on software instead of the (new on 2350) hardware FPU, ok?

To understand how uPy works, if anyone could clarify for me - uPY still needs to convert py files to this "bytecode" generated by the compiler to execute it when PY file is uploaded to a microcontroller instead of already converted MPY, pretty much like the regular python generates PYC files first and then executes these, right? (yes, PYC is just cached converted data I know, but the conversion simply must take place.)
-- So the 2350 uPy project must include this compiler's code in some form, too...? and the architecture could? be determined from there?

[[What I need this compiler namely for is to save microcontroller's RAM: MPY files kill comments in the PY file and generally compress original files to dramatically smaller ones; plus when the module gets loaded, no extra memory is taken for the conversion I guess: it is the only way to squeeze more complex stuff in a limited RAM, and it helps much. On ESP8266, it makes a dramatic difference in usability of uPY with its just 80k RAM, but RP's benefit significantly, too. Naturally, it'd be a pity to give up the hardware FPU, on the other hand!]]

[jkorte-dev]

@SteKme sorry for hijacking this thread and causing confusion. mpy-cross compiles python scripts to micropython byte code embedded in .mpy files. It has all the advantages you have mentioned and does not require to specify the architecture. Mpy files can also contain native code. These mpy files are architecture dependent. stm32f411 and rp2350 are both marked as armv7emsp (hardware fpu) by micropython and can therefore execute the same mpy file but the cpu architecture differs: stm32f411 is cortex arm m4f and rp2350 cortex m33 maybe this is the reason which the result of fpu calculation differs, more likely I made somewhere a silly mistake, but I really don't know. rp2040 is cortex m0 and has no hardware fpu therefore I implemented the fixed-point version as a work around which should not be needed on rp2350.

[jkorte-dev]

I started a new discussion for my problem: https://github.com/orgs/micropython/discussions/16592