IWP9 and SAMD51

At the start of April the power supply on my desktop PC failed, tripping one of the apartment's circuit breakers. This disrupted any activities around personal software development, making it necessary to move a subset of projects to the laptop I use for work. One of those activities was to prepare a presentation for the 9th International Workshop on Plan 9. The other developed as a result of my temporary computing environment.


My paper, “Hell Freezes Over: Freezing Limbo modules to reduce Inferno's memory footprint”, had been accepted earlier in the year. I was aware that I would probably have to present something to the workshop, although I wasn't able to attend. As the workshop approached, I discovered that I was expected to prepare a set of slides and record a video presentation. Given that the work was done some time earlier, it was a challenge to recall all the details of the project. Plus, I had to record something using a laptop while away from home.

Ultimately, the video wasn't used, though it was probably useful to have rehearsed the presentation when the time came to present it in late April. I can't say that I was too happy with my performance, but there wasn't much in the way of guidance or feedback from the other end of the video link, so I just had to work with what there was. Maybe I'll upload my original video at some point. The paper and presentation slides can be found in this repository.


Although my usual development environment was unavailable from early April until early June, and I was busy with work for a lot of that time, I still wanted to be able to do something a bit more interesting than the run-of-the-mill daytime stuff. Before I got going on a port of Inferno to the STM32F405 microcontroller, I had originally wanted to target the SAMD51 MCU, and it seemed like a good time to revisit that.

I originally chose the SAMD51 because it has slightly more RAM than the STM32F405 – 256K vs. 192K – and it seemed like a good idea to aim high then squeeze the system requirements lower. Reading the datasheet, however, I found it hard to get started. It didn't help when I looked at the source code for various systems with ports to the SAMD51 and found a lot of code to set up clocks that I found confusing. Turning to the STM32F405, I found it easier to get started with.

Revisiting the SAM51 after some experience, things seemed clearer, and it took surprisingly little time to get something up and running. Ultimately, there's not much more to see than what you get with the STM32 port, other than the presence of more RAM to play with:

Initial Dis: "/osinit.dis"
** Inferno
** Vita Nuova
samd51$ cat /dev/memory
      39008      121932       39232         596         206          35       82912 main
      19392       99763       19392         144          20          12       80359 heap
          0           0           0           0           0           0           0 image

As with the STM32 port, I haven't looked at floating point handling, though they will probably share the same code for that. So far, this port has been simply a proof of concept, without much experimentation with peripherals. However, it may be interesting to focus on this port for a while because the USB peripheral is possibly more approachable than the one on the STM32.

You can find the code for the port in the samd51 branch of this repository.

David Boddie
28 June 2023