SRAM decorator for RP2 port?

[dx9s]

I am fairly new to MicroPython. This question is targeted at RP2 port! Been writing C-like languages for a while now, decided to force myself to learn MicroPython!

I am curious if there has been any discussion as to having a SRAM decorator to keep time critical bytecode in SRAM and avoiding XIP cache misses?

from machine import Timer

@micropython.sram # keep/copy into sram
@micropython.native # if necessary for native or viper performance ??
def my_callback(t):
print("Timer fired!")
# [...]

tim = Timer()
tim.init(period=2000, mode=Timer.PERIODIC, callback=my_callback)

I am also uncertain as to IRQ call backs to native/viper code, I think I read there are some gotchas or limits to this so a callback might need to do:

@micropython.sram # keep/copy into sram
@micropython.native # or viper
def cpu_intensive_function(x: int) -> int:
# something CPU intensive here
return answer

@micropython.sram # keep/copy into sram
def my_callback(t):
print("Timer fired!")
result = cpu_intensive_function(1)
# [...]

or possibly freeze the code into custom firmware.UF2 for RP2's (did a hello "module" frozen into a custom UF2 firmware to figure out how that works).

>>> help("modules")
__main\__ asyncio/lock hashlib random
_asyncio asyncio/stream heapq re
_boot binascii hello rp2
...
>>> import hello
>>> hello.world()
hello world

Just throwing this out. Thanks for any constructive responses back to a MicroPython newb!

[scruss]

Can one even do this with the native API?

[robert-hh]

Python code loaded from the regular file system will reside in RAM. But the runtime system compiling and executing the Python code resides in flash. And so called "frozen bytecode" and code located in the vfsrom file system will stay in flash. Given that, no special SRAM decorator is needed. You can control already whether the Python bytecode is executed in RAM. And you can used Native or Viper code for speed improvement. See https://docs.micropython.org/en/latest/reference/speed_python.html.

[dx9s]

@robert-hh:
Just repeating for clarification and possible correction or confirmation:

Frozen bytecode (bytecode,native,viper) in the UF2 firmware (as this is a RP2 port topic):
Already loads from QSPI into SRAM and runs from there?

Same is true for .mpy files pre-compiled for bytecode/native/viper and stored in the vfs (or where else the mpy can be access, i.e. SD card).

I guess the only thing I need to resolve is custom C code, that appears to default to loading from QSPI into XIP and running there (does not stay resident in SRAM).

If I got this correct thanks! This helps determine which direction to put efforts into learning and developing test/scratch/reference code.

I have left-over deterministic execution tendencies from writing pic assembler in the past. A slight amount of jitter is acceptable as long as I understand all the moving pieces and can optimize.

Including compiled native/viper for performance as needed, keeping as much of the code in MicroPython for maintainability, portability and readability is desired (avoiding C, and REALLY avoiding PIO assembler or RP2040 assembler).

Although I am not above writing custom C library for the RP2 port and usable from the python side of the runtime code inside the RP2040, to enhance and offload potential CPU intensive tasks (rapid collection and decoding of sensor data). I still need to look into a simple hello world from the C side of a custom UF2 firmware.

Thanks for your time!

[robert-hh]

@dx9s

There are three places from which Python bytecode (= compiled Python source code) can be executed. Executed means interpreted by the Python runtime machine, not executed by the ARM CPU directly.

1. RAM. It gets into RAM from the mutable file system, either by compiling Python source code or by loading pre-compiled Python source code. Pre-compilation happens on your PC.
2. Flash memory, when it is stored in a VFSROM file system. The VFSROM file system image is created at the PC and stored to flash using e.g. mpremote.
3. Flash memory, when it is part of the MicroPython firmware as frozen bytecode. Frozen bytecode will be bundled with the firmware as part of the firmware building process. Quite a few Python modules from the library are included that way by default into the firmware, like asyncio, neopixel, dht, ...

In any case, this bytecode is not directly responding to events. An interrupt for instance is in the first place handled by the MicroPython firmware, which then may "call" a piece of Python bytecode or native/viper code.
A while ago I testes the IRQ latency to GPIO events for the RP2040. Typical response times between an event at a GPIO pin and a reaction by a Python callback were about 30µs for devices which were otherwise idle, but could go up substantially when the device was busy or needed a flash re-caching of garbage collection. Getting a reliable maximum IRQ response time is difficult to achieve because of these two effects.

1. Serial Flash: Machine code is not directly executed from flash, which only has a 4 bit address/data bus. Instead, it it loaded into a cache and executed from there. If code to be executed is not in the cache, it has to be loaded from the flash, which takes about 300µs.

2. Python dynamic memory: If your Python code needs to allocate memory for objects, it may not be available on the heap. Then, a garbage collection must be done to free unused memory. That takes time.

[dx9s]

To clarify what I know or am hearing:

• The RP2040 (not a Micropython thing) either runs code from SRAM (aka static RAM) or from Flash (serially read in via QSPI) and typically cached via XIP. I've even ran some demo code (in C) that forced bypassing XIP (similar to https://github.com/Sreekesh92/rp2040_xip_cache/blob/master/blink.c ).
• Micropython (RP2040 runtime) compiles source files into the remaining ~230KB* RAM and run there, but only as bytecode (no viper or native). *=based on current RP2 port builds

(side note: 264-230 is 34KB? Is the runtime+heap really that small on a fresh boot, just seems insanely small, +100XP for MicroPython)

Remaining confusion if I understand the first section above (2. and 3. in particular):

• (pre-compiled using mpy-cross -march=armv6m and native/viper decorations) .mpy files only runs from Flash (again from the XIP 16MB cache) regardless if stored into the VFS or Frozen into UF2 firmware image?
• There might be a way to get C code compiled and loaded into the UF2 Firmware that eventually can be loaded from QSPI flash and resides in RAM like portions of the Micropython runtime+heap resides in RAM.

The only reason for this line of exploration is there might be a need for faster code (mpy-cross native/viper or C) that persists in RAM (outside of flash + XIP, avoiding cache misses).

In a somewhat related note, there are discussions like this on the C side here: raspberrypi/pico-sdk#2653

@micropython.sram decoration while it doesn't exist now, having the ability to somehow flag bytecode/native/viper pre-compiled code to be copied to RAM from Flash would be nice.

Perhaps I am wrong and there is a way to have mpy precompiled code loaded into the remaining 264KB of RAM??

Thanks for sharing information on GPIO jitter experimental tests you did. Between 30 and 300µS is still quite impressive (ignoring any GC hold-ups). That sounds cool!

Guess a goal is to avoid GC events, i.e. create a buffer once and reuse (aka memoryview) which I have tinkered with some scratch/reference code. Perhaps also schedule GC events gc.collect() when it makes sense.

Again thanks for the feedback. I'm a newb to Micropython, a bit more knowledgeable on C and micro-controllers in general (started with PICs and assembler with 35 instructions total). Have tinkered around with some RP2040 C and instead of uLua or other interpreted embedded languages, MicroPython appears to be the best match for many reasons. Just kicking the tires (an English phrase meaning 'check things out') !

[Josverl]

Is there a maximum latency that you need/want to achieve?
I ask as it is always a resource scarcity tradeoff. One piece runs faster, but at the cost of something else, speed, size, power.
I think its good to have clear goals so that good can be good enough.

I suggest you also look into the delays that the garbage collector may have on your code.

[Josverl]

The way I understand it is :

• The MicroPython firmware (including compiled C code, MicroPython runtime, built-in modules, frozen modules) is stored in flash and is executed from flash via XIP.
• The actual source( .py) or bytecode (.mpy) is read from Flash or filesystem one time, then converted into code objects and data in SRAM.
• MicroPython does not execute directly from the Flash memory mapped space (XIP), unlike some C/C++ firmwares that place functions in Flash and run them with XIP support.
• for time-critical code on other CPUs you could consider using native code @micropython.native decorator, though even then the execution is from SRAM.

Theoretically it might be better to not freeze modules that contain hot loops.

• this will take one initial hit to compile load the bytecode into SRAM, but after that you should not see any XIP cache misses for that.
• frozen modules reside in (QSPI) flash - and may be mapped out of XIP space, (but not without reason)

Note

I have not tested / verified this

[dx9s]

I am still learning. I've got a lot to do and test. Long ago, I came from the PICmicro (12/14/16F's) where code execution was highly deterministic and still have that mindset. I've also poked around writing native C for the RP2040 but have not YET dove in and learned how to make custom C library for use in MicroPython (something I should test).

That said, deterministic responses to Timers or external interrupts (radio module, sensors, etc.) that are time critical are of a concern, but as I am new to MicroPython. The latency (jitter) in a callback is something I will need to keep an eye on.

The RP2040 (~264KB) might be enough to fit everything inside. I don't fully understand MicroPython's strategy on what is loaded into where, just that code that loads in from QSPI loads and runs out of XIP and as you mentioned could be mapped out.

My thinking was a way to have code that is frozen (native/viper) or native C that loaded and stays resident in SRAM is the way to go.

It sounds like you are saying all bytecode that is compiled at runtime (from .py from vfs/QSPI) stays in SRAM?
And you are saying that precompiled (bytecode/native/viper) mpy code frozen does not make it into SRAM and only runs out of XIP?

Sorry for asking confusing question, but the goal is (where necessary) CPU intensive code optimized as native (C/Native/Viper) that somehow resides in SRAM (until released and GC'ed). I saw somebody else even asked [@scruss] if this is possible (within the context of the RP2 port)

Just thought that this is an interesting edge case or thought experiment for the RP2 port.

[peterhinch]

Bear in mind that MicroPython bytecode is not actually executed. It is read by the MP runtime interpreter. The physical location of the bytecode may be in RAM or in Flash. If the application comprises Python sourcecode, the compiler converts the code into bytecode in RAM which is then interpreted by the runtime.

So XIP is not really relevant to running bytecode, which to the hardware is just data.

[dx9s]

Understood that bytecode is akin to Java bytecode (interpreted), but was discussing the ability to earmark code for staying resident inside the RP2040's SRAM.

Cases were bytecode is compiled from .py source files, the bytecode lives in SRAM, not an issue assuming performance is adequate.

For times where optimization (mpy-cross + decorations for native or viper or custom C library*) is of interest. If the MPY is in the VFS/QSPI, it appears that the code is loaded into SRAM? Not sure.

For times where the code is loaded into the firmware (frozen or native C library*) that defaults to running in the XIP? Also not sure but that is what I think I am hearing (still a newb to MicroPython)

*=C might have a way to stay resident in SRAM I think, but not sure. I think that is how the interpreter functions (out of SRAM).

The goal is to have code that is highly deterministic in response to IRQs or Timers (external sensors, radio modules, etc.) -- as I am new, there are still things I have not tested or experienced as issues. 264KB of SRAM is a lot (a lot more than pic12F683 256 bytes of RAM, but in that case, I wrote assembler to offload detecting and parsing external data for another MCU running C code that was less deterministic).

Was just curious if the idea of earmarking mpy-cross compiled .py (as native or viper as necessary for speed) code as staying loaded into SRAM for use in callbacks was discussed for this particular hardware (the RP2 port)

The RP2040 is a powerful platform but is a little strange (no internal flash and "slow*" external QSPI flash). *=might still be fast enough for XIP cache misses. Still learning

[GitHubsSilverBullet]

The goal is to have code that is highly deterministic in response to IRQs or Timers (external sensors, radio modules, etc.) -- as I am new, there are still things I have not tested or experienced as issues.

Write those parts in assembler. Even if written in a vary sloppy way, half a million IRQs/second are possible within the Micropython environment. Verified!
Be prepared to get your hands dirty and read all about the NVIC.

[peterhinch]

@dx9s If your file is Python source the bytecode resulting from on-board compilation will be in RAM.