My first weeks at Tweede golf

Embedded software engineer
Let me introduce myself, I'm Dion Dokter, 24 years old (as of writing) and the newest member at Tweede golf (TG). I've always been into computers and started writing desktop software and games in 2013, embedded software in 2015, and started with Rust in 2019.

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.

Signing my contract with Tweede golf

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


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.


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.

First Embassy PR merged

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!


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.

Stay up-to-date

Stay up-to-date with our work and blog posts?

Related articles

June 10, 2024

Tock binary size

Tock is a powerful and secure embedded operating system. While Tock was designed with resource constraints in mind, years of additional features, generalizing to more platforms, and security improvements have brought resource, and in particular, code size bloat.

While using a full-blown filesystem for storing your data in non-volatile memory is common practice, those filesystems are often too big, not to mention annoying to use, for the things I want to do. My solution?

I've been hard at work creating the sequential-storage crate. In this blog post I'd like to go over what it is, why I created it and what it does.

At Tweede golf we're big fans of creating applications on embedded devices with Rust and we've written a lot about it.

But if you're a hardware vendor (be it chips or full devices/systems), should you give your users Rust support in addition to your C support?

In this blog I argue that the answer to the question is yes.