MicroPython on RTEMS experiments

Languages Python
1

I have been able to set up an example for SPARC that uses MicroPython’s embed port with RTEMS. It is based on MircoPython’s own embedding example and the RTEMS “Hello World” application.

This application can be found here.

The Makefile micropython_embed.mk is used to generate the directory micropython_embed/ that contains the .c files for an embeddable MicroPython build. These are then used in mpy.c, where we have an example Python script stored as a string in example1, which is passed into mp_embed_exec_str() that runs it.

This should ideally be a baseline example that has an interactive MicroPython shell, but I am not sure if I can take user input in the SPARC simulator. I started with SPARC because it allowed me to quickly verify that it is possible to run MicroPython under RTEMS.

What should the next steps be?
This is what I have in mind from discussions on Discord so far:

  • setting up a baseline example that uses serial I/O to allow the user to interact with micropython
  • bringing this up on my stm32f407vet6, raspberry pi 5 or rpi pico.
  • exploring how MicroPython can be used to access RTEMS APIs
2

Hello! I have done a port on the icicle kit a year ago, it is here : GitHub - fcuzzocrea/micropython at mpfs-rtems-work

It is dirty and needs to be cleaned up

3

This looks great … What license is it under can you add a LICENSE file so we can make sure it’s compatible with RTEMS? Thank you!

4

added the BSD 2-clause license

5

Thank you @lzrd That message was also for @bosconovic since the repo he provided has no license.

6

I got my embedding example to work on STM32F407VET6

Screenshot_2025-03-15_01-57-56
Screenshot_2025-03-15_01-57-561265×645 25.5 KB

I had to make this change in the stm32f4 BSP linkcmds.stm32f4 file:

diff --git a/bsps/arm/stm32f4/start/linkcmds.stm32f4 b/bsps/arm/stm32f4/start/linkcmds.stm32f4
index 1d16cfdde9..448e169276 100644
--- a/bsps/arm/stm32f4/start/linkcmds.stm32f4
+++ b/bsps/arm/stm32f4/start/linkcmds.stm32f4
@@ -1,6 +1,6 @@
 MEMORY {
        RAM_INT : ORIGIN = 0x20000000, LENGTH = 128k
-       ROM_INT : ORIGIN = 0x00000000, LENGTH = 1M
+       ROM_INT : ORIGIN = 0x08000000, LENGTH = 1M
 }

 REGION_ALIAS ("REGION_START", ROM_INT);

Something confusing to me is that the board refused to work (I was testing with a blinky earlier) with ROM size set to 512, which is the actual size of flash on this chip.

What I am focusing on next is getting serial input working so this can be an interactive prompt.

Something else I need to figure out is why I had to comment out #define CONFIGURE_UNLIMITED_OBJECTS and #define CONFIGURE_UNIFIED_WORK_AREAS in my init.c to make this example work on the board. I followed the error that followed and added a #define CONFIGURE_MAXIMUM_TASKS 1 to make it compile.

7

Good job! Some BSPs have configuration settings to override the memory origins and length. Then the defaults can be set in a user config.ini file while building RTEMS or added as BSP variant with a different BSP name to reflect the model

@opticron what’s the best approach here?

8

I am trying to set MicroPython up as a custom command for the RTEMS shell. Does this make sense?

I have followed the RTEMS Shell Guide and had to add the extra option CONFIGURE_APPLICATION_NEEDS_LIBBLOCK to make it compile.

For now I am getting this output on serial:

creating task SHLL in shell_init() (status: RTEMS_UNSATISFIED)

for this call to rtems_shell_init:

  rtems_shell_init(
      "SHLL",                       /* task name */
      RTEMS_MINIMUM_STACK_SIZE * 4, /* task stack size */
      100,                          /* task priority */
      "/dev/console",               /* device name */
      true,                         /* run forever */
      true,                         /* wait for shell to terminate */
      NULL /* login check function, use NULL to disable a login check */
  );
9

The original STM32F4 BSP is set up for an STM32F407VGT6 which has 1MB of FLASH. Your VET6 only has 512K. What would that do? Umm, nothing. The FLASH is used low to high, so the unavailable 512K would just cause a hard fault if you tried to read it.
The FLASH sits at location 0 at run time, but you have to write it at location 0x0800’0000.

10

Have you tried the fileio sample?

Have you checked the size of the executable with the size program?

11

Sorry to reply to myself but you should probably ensure you can run fileio and your test on a simulator before moving to real hardware.

12

I tried changing it to 512k as I mentioned earlier, is this not the correct way to do it? Even with a simple blinky, it only works if I leave that at 1M. Also yes I am writing to 0x08000000.

13

My current MicroPython test (not interactive) works on both the SPARC simulator and the hardware. I will try the fileio example, thanks.

14

I’d set the quantity of FLASH to match your processor.

You’re working with a variant of the STM32F4 BSP. The original uses a VGT6 processor, you’ve got a VET6. By setting the FLASH size to match your processor, the linker can complain that you’ve run out of space. By leaving it at 1MB you can have a program that links, but when you try and program or read the FLASH above 512K on your processor, it will complain fatally.

In the BSP that I put together for the F767 I had to use 0x0800’0000. I don’t remember what triggered that change, since I wrote that BSP years ago but, yes, that alteration is cromulent.