GSoC Project Updates, Week Four

We are about to enter the 4th week of GSoC, and my project is definitely starting to take shape! I couldn’t post updates here because I had my third year end-term exams from May 29th to June 20th. Future GSoC contributors should note that this sort of thing is not a problem, given that you discuss this with your potential mentors during the Application Period and mention it in your proposal.

I didn’t stop completely, though. I continued to participate in the weekly Organization meeting to share progress and the one I’ve set up with my mentors for project discussions. Progress was slow, and this post documents everything (I think), but here are the highlights of work after the first blog post:

Just to recap, during the application period I took the MicroPython embed port that gives us the function mp_embed_exec_str which can execute strings containing Python code. This is easy to use because the MicroPython implementation here is just a bunch of C source files without any external dependencies.

However, it’s not very useful if we want to interact with the hardware RTEMS is running on. So, I moved away from the embed port and followed MicroPython’s porting documentation that asks us to implement a few functions like readline (yes I know, the signature here is readline(vstr_t *vstr), where vstr_t is MicroPython’s variable-length string type), etc. and then we have a very minimal port.

Here’s what that looks like:

MicroPython v1.26.0-preview.135.g5139cedab on 2025-06-23; rtems-i386/pc686 with unknown-cpu
>>>

Initially my readline (heh) implementation was broken so I wasn’t able to input anything, because of two reasons:

First, I didn’t look at the function header closely and was trying to write the characters being read directly to the vstr_t* pointer.

Second. Interestingly, input functionality on the serial device (a console on QEMU in this case) was not being initialized, so my fgets() calls wouldn’t block and I got an endless stream of >>>. I looked through the fileio sample and found:

rtems_shell_wait_for_input(
    STDIN_FILENO,
    20,
    notification,
    NULL
  );

For context, this sample has a little loop that presents a menu of actions to the user, and this function is called before that menu is first printed. I found that if I remove this call, I get similar behavior in the fileio sample, i.e., it just keeps printing the menu repeatedly and doesn’t block to read user input.

I placed the call

rtems_shell_wait_for_input(STDIN_FILENO, 0, NULL, NULL);

in my example application, and got input to work! I was now able to write Python code:

MicroPython v1.26.0-preview.135.g5139cedab on 2025-06-23; rtems-i386/pc686 with unknown-cpu
>>> def test(x, y):
...     return x + y
... 
>>> test(1, 2)
3
>>> import gc
>>> dir(gc)
['__class__', '__name__', '__dict__', 'collect', 'disable', 'enable', 'isenabled', 'mem_alloc', 'mem_free', 'threshold']
>>> gc.mem_free()
3024
>>>

This nice REPL is printed by the MicroPython function pyexec_friendly_repl(), and it has a weird limitation where a single expression/statement (anything, including functions like test above) should fit within 32 characters, not a lot!

A limit made sense to me, but I wasn’t sure why this wasn’t configurable. One of my mentors pointed out the mpremote utility that is used to interact with MicroPython, so we tried to point it to the QEMU virtual console. Expectedly, it couldn’t connect to it, but we saw something interesting - the utility was trying to open something called a “Raw REPL” over the port. It would send ^A (Ctrl+A) and expect a Raw REPL to be available. After looking through the implementation of pyexec_friendly_repl a bit more, I also expected it to connect because the function does have code to handle codes like ^A (among others). Sending ^A to the function should make it execute pyexec_raw_repl, but that wasn’t happening.

I’m still trying to figure this out. It could something related to how we expose the console through QEMU. Unlikely (to me, because this is just an fgets() call under the hood, and also, I see the actual characters “^A” appear on the REPL), but RTEMS could be consuming the input. Something I’m currently inspecting is the termios flags used in rtems_shell_wait_for_input to see if there’s any flags to enable Ctrl+key combinations that are missing. This is of interest to others, including the Organization Admin as well because these flags could be used globally so people don’t have to struggle to get input working.

Mid-Term Deliverables

I have set up weekly meetings with my mentors on Mondays. Last week we finalized these deliverables for the mid-term.

This is similar to what I mentioned in my proposal: “Partial support for using RTEMS APIs through MicroPython”. In the previous post I talked about configuration across BSPs, but focusing on some support (that is general enough, like the time module) first gives us some surface area to to figure out better ways of configuration other than mpconfigport.h (if there are any).

Build System

There seems to be some confusion about it so I’ll document it here too - my current MicroPython “port” in my fork has an init.c with some startup configuration and an mpy.c with an Init task. I am aware that these two files are found in applications, not libraries.

During the Application Period I went through the Quickstart Guide in the RTEMS Documentation, that uses the Waf build system to build a “Hello, World!” application. So, when I set up my MicroPython port, I compiled the MicroPython objects using a Makefile (Micropython makes heavy use of make), compiled mphalport.c, a file that implements the input/output functions I mentioned above, using Waf, and then finally linked everything together with the application.

To package MicroPython for RTEMS, we need an RSB (RTEMS Source Builder) Recipe, and I’ll be doing that with some help from one of my mentors. The first step here is to have a script that can build MicroPython, and we cannot use Waf.

This is what I did today. Earlier I had a simple Bash script that used the old approach that kind of mixes the MicroPython Makefile and RTEMS Application wscript because of the port file, but now there is a single Makefile that generates the whole “library” (all the required object files, including the one for mphalport.c). An RTEMS application just need to link against these.

Next Steps

Progress was slow during exams, but now I’ll be able to focus more on this project. I’m hoping to make progress with some of the modules this week.

Other than the listed mid-term deliverables:

I’ll try to post these more frequently now. Thank you for your time!