Midterm Analysis: What’s been done and what’s left

2026-07-05

Getting Started

Due to the upcoming midterm evaluation, I wanted to write out an outline of milestones that I’ve achieved, and many more that are to come following the rest of this GSoC.

All my work (which is all in demo files at the moment) is located in this branch of my RTEMS fork here.

The initial deliverables presented during my proposal (and later refined per mentor discussion) document included:

First Deliverable (two-way UART transport + Scrutiny integration)

This was my primary focus throughout the first half of GSoC. Making sure Scrutiny boots up with RTEMS through not only physical hardware, but emulation was my primary goal, on both little endian & big endian architectures. The focus on the emulator aspect is due to the easiness of testing the integration for maintainers.

So far, this integration effort has been tested on STM32F401RE physical hardware & LEON3 QEMU.

The first week introduced one roadblock in running Scrutiny with RTEMS via SIS. Before I chose QEMU, my initial idea was to test it through SIS (sparc instruction simulator). Unfortunately, this is the only target (so far) which this integration does not work on. My first week was spent constantly debugging through the emulated firmware handshaking with the Scrutiny server whilst using socat as a middleman. Thankfully, it is not required for this integration to work on all targets due to the nature of it being an optional experience. However, I will still raise an issue after GSoC to look into this, more info on my blog post from the first week.

The rest of the process that went on for the following 2 weeks involved a lot of research. Mainly research into the best timestamp methodology to use from RTEMS and how to initialize RTEMS tasks in a seamless manner. I took a lot of inspiration from existing testsuites, aswell as discussion with my mentors. For getting timestamps for Scrutiny, I settled on using CLOCK_MONOTONIC with clock_gettime(). For setting up RTEMS tasks to hook onto Scrutiny datalogging, I followed through the implementation of RTEMS tasks from the testsuite ticker.c.

The final bit of this deliverable was to ensure variable from my RTEMS demo file are actually available to instrument to Scrutiny. This involved either initializing runtime published variables (which the user does themselves) or postbuild generation of an SFD, which is a Scrutiny Firmware Description file. The SFD contains important information like the firmware id, variable map, and aliases in order to tell the Scrutiny GUI what to instrument. I integrated this postbuild integration to my demo file and was able to successfully instrument variables from my demo file.

After all this, we successfully got RTEMS running with Scrutiny.

Second Deliverable (Exposing metrics)

The Metrics I decided to implement for the core of this GSoC project are interrupt count (across all vectors or one), cpu utilization usage, stack usage, & heap usage. If time permits, I will also look into other metrics like networking and device I/O.

Interrupt count took me awhile to tackle, namely because I had to do a lot of research with trial & error. My initial approach was using deprecated old functions from the RTEMS interrupt directive, but over the week I was working on this function I was able to settle on the best approach using the handler install directive. I was able to successfully extract an interrupt count, across all possible working vectors.

At the time of writing, the current metric I’m working towards is CPU usage. This is actually not as hard as I thought it would be, however, there is still a lot of trial & error with determining the best method in accordance to RTEMS conventions. The approach I’m settling on is to measure CPU usage during the idle task, and using that to calculate the usage when it isn’t in the idle task (henceforth, getting the CPU load when active). I’m also contemplating adding another additional metric for CPU time elapsed in seconds, which won’t be too difficult to add (I hope).

The next metrics to follow are stack usage & heap usage, which I will approach following the completion of CPU usage in the following week. Can’t wait.

One thing that I will need to discuss with my mentors is how the implementation of the metrics will be merged to RTEMS. I intended to add some sort of library and expose these as Scrutiny-agnostic functions. I don’t know if this approach is right. I will need to look into how “glue” code like this is typically implemented in RTEMS more in-depth, and to get advice from my mentors on the RTEMS side.

Third Deliverable (Documentation and testsuites)

I don’t expect this deliverable to be too lengthy. My testsuite will most likely just be the same as my demo file (which includes my rough work in my local fork), just polished and cleaned up, with the metrics implemented as function calls.

Fourth Deliverable (Build Recipe)

The current build recipe I have in my fork of the RSB works quite well. There are some small tweaks I need to make however. There is also the matter of integrating the postbuild activity (SFD stuff) with waf as it’s currently sitting around in CMakeList files.