My first weeks at Tweede golf

After my embedded Rust project at my previous employer ended and no new projects were lined up I decided to take up TG's offer for a job interview.

Three months later and here I am, about a month into my new job, so far without regrets. And this is partly due to it being a great workplace and partly due to the good onboarding process.

Me (on the left) signing my contract (notice my new boss seizing the moment to enjoy a kids ice cream)

Onboarding

The first day is always exciting because you don't quite know what to expect. In my case, it went pretty well. My PC was set up and I was given a bootstrapping checklist with all the accounts I needed to set up.

After that I was asked to do two introductory assignments:

• Create a simple web project using Rocket and React to learn about our tools
• Familiarize yourself with embedded Rust

I've never done React before so that was quite interesting to do. But as an embedded developer I'm most interested in the embedded assignment. There was no need for a lot of familiarization, as I've been working on embedded Rust for two years already. Instead, we looked at what I could do that could help the company in the future and the opensource community at the same time.

Embassy

TG has been doing some experiments with Embassy, an async runtime for embedded devices. It's a very promising prospect and I hope this way of programming will catch on for embedded. However, for now, it's mostly the ecosystem that is lacking.

For example, most of our projects use the nRF9160 microcontroller, but it was not yet supported. So to get to know Embassy myself, help pave the way to potentially using Embassy ourselves and helping the ecosystem, I decided I wanted to add support for the chip to Embassy.

Project setup

The first step was pretty easy. Embassy is built quite modularly. There's a core that implements the executor and defines all common abstractions and functionality. All supported devices are then split up by manufacturer which then implement all the abstractions for their peripherals.

Currently there's a crate for STM, nRF and RP (Raspberry Pi Pico).

Examining the nRF crate it had complete support for all nRF52 mcu's and theoretical support for the older nRF51's. All of the Nordic microcontrollers share pretty much the same peripherals give or take a couple of features.

Initial support

My first task was finding out how the nRF91 is different from the nRF52. And the good news was that they are very similar. The biggest differences are the new DPPI peripheral that replaces the old PPI peripheral and the way that security is implemented. The nRF91 has everything split between a secure and non-secure context.

After a discussion with the maintainer it was decided to just start with the non-secure side and go from there. The non-secure peripherals all have a _NS suffix. To make them work with the existing code, I reexported them all without the suffix. I stubbed out the PPI code and configured the chip file.

This was the first PR I made and it was quickly accepted.

Full support

But to make the full chip work, we needed DPPI support.

In principle, it's very similar to the older PPI peripheral, but in a way, it worked in the exact opposite way. The challenge here was to try and unify both so that any code on top wouldn't even have to know which peripheral it was using.

In the end it turned out that the maintainer had some different ideas on how that should be accomplished, but after a couple of review cycles, it was good enough to be merged as the second pull request!

Conclusion

The first weeks have been fun and helpful for me, the company, and the open source community. Couldn't have been much better.

I've now started completing the first 'real' tasks and with that my onboarding is officially over. It's nice to be in a place that acknowledges that people need time to get familiar with their new position and that there is value in contributing to open source.