So, in this post, I’m reverse engineering the technology behind these games a bit. But first, let me explain how they work from a player’s perspective: The board contains a big plastic element in the shape of Merlin’s stone (King Arthur) or (somewhat) of a volcano (Die Insel), housing the electronics and a speaker. On the board itself you have several location fields for the player figures and a few fields with actions (e.g., interact, fight) located to the side. In both games, you have four figures in four colors available, one for each of the 1-4 players. Besides this, the games contain other typical board game components, such as cards and tokens.

To interact with the game, a player puts his figure on the relevant field on the board, and touches the head of the figure simultaneously with one of the action fields. This triggers some (actually stateful) game logic and some audio output, which is the main feedback channel from the game to the player.

Incorrect Theories

And this is actually the interesting part of it, because in touching the figure and the action, the game needs to determine three parameters:

• Which action was taken.
• The location field the figure is on.
• Which figure (color) is acting.

Sounds simple at first, but when you think about it, it is actually not that easy. If it was only two parameters, everything would be simple: Your body is conducting, you close an electrical circuit between the field and the action and the game knows what to do. And indeed, some kind of electrical circuit is closed, as you can clearly see electrical traces on the board leading towards the fields and actions. But how does the game get the third parameter?

Let’s begin with some initial (incorrect) theories I had on how this might have been implemented:

• Resistance measurement: The figures could have a specific resistor built-in, and the game measures the resistance between a location field and the action field. The issue here is that the body resistance of a player is pretty high (~8 MΩ between my arms), and it varies a lot (depending on your arm length, skin moisture, …). After measuring the “resistance” of the figures (~2 MΩ) it is safe to say: This isn’t how it is done.
• Capacitive measurement: Placing a capacitor in a figure and measuring the impedance between two fields? This has the same issues as above and was not used either.

Ok, why not ask Ravensburger directly? I sent them my question via their website, and to my outstanding amazement, I actually got an answer by the engineer that supervised the project back then - super cool! 😎👍. Unfortunately, he didn’t really know the details either, as the technology was done by an external company - but still very kind of him to answer!

So, let’s take a look at what’s inside Merlin’s stone!

Disassembly-Time

Opening the plastic stone is quite simple, it is just held by 12 Torx screws. Inside we can see the PCB and a bracket with an elastomeric connector to connect the PCB to the traces on the game. On the other side of the PCB we can find a switch, two seven segment displays, a touch knob (used to register players to the game), an uninteresting dip component (I think it was a shift register) and a daughter board with a blobbed IC. Behind the PCB we can find the speaker as expected.

Ok, this doesn’t give us a direct hint on how things work, but at least we can find the name of the company that created this technology on the PCB: Innovision. We’ll come back to this later. Maybe the figures themselves give us more insight?

Contrary to opening the “Stone”, the figures are actually not designed to be opened, but are plastic parts glued together. As I want to keep the game intact, let’s first check what we can find out from the outside. The figures contain a conductive rubbery pad at the bottom, and the head of the figure is made of some kind of conductive plastic.

Sigh, I guess I’ll have to open a figure. Fortunately, I got a second set of figures for ~5€ off eBay, so let’s sacrifice the blue knight - for science!

We find another small PCB by Innovision inside and the curious thing about it is, that this PCB contains a small antenna. Taking a second look at the “Merlin’s Stone” PCB, we can see an antenna on there as well. And that’s actually part of the answer to the question: Each figure sends the location and action information along with the color code via near-field radio. Looking up old versions of Innovision R&D’s website (they apparently have been acquired or so lately), this makes sense—the company is specialized on RFID and other near-field radio.

So upon touching the figure and an action field on the board, the player closes the circuit and powers the IC inside the figure, which then sends information to the main unit. Still, the question remains: How does the game know which action and location the player is on? Let’s grab the oscilloscope and investigate the fields on the board!

The capture of the oscilloscope reveals: “Merlin’s Stone” modulates a 20 Hz signal on all fields that encode the field ID. This signal differs from field to field and the action fields have a significantly different waveform than the location fields.

And this is the final solution to the mystery:

• An individual signal is modulated to each field.
• Touching the figure and the action field closes the circuit and the figure’s IC is powered through the player.
• The IC in the figure perceives the composition of the field and action signal and can thus determine the location and action chosen.
• The IC in the figure sends the combination of color, location and action via near-field communication to the main unit, which triggers the game logic.

Conclusion

One could go further from here and decompose the RF communication or decode the signal for the individual fields and actions, but I’m satisfied for now. Overall, I’m quite impressed how many smart ideas are below the surface of this at first glance simple game. Now my mind can rest, and I can finally start to actually play the game.

Simple Proxy

After a little research, I found a cheaper solution I’d like to share here: Use a cheap VPS as an IPv4 to IPv6 proxy.

Disclaimer: I don’t run this exact setup myself anymore, but I’m pretty sure that it still works.

A VPS is a cheap virtual machine in a data center you can easily configure online. The cheapest configuration should be sufficient, as long as there is a static IPv4 included. At least a few years ago, this was often available for around 3€/month.

So this is what the setup will look like:

The figure already reveals that all software we need to run on the VPS is socat. Socat is a stock-standard command line utility that can be installed on virtually any UNIX like operating system and is incredibly versatile.

To forward any traffic on a certain port to a different host, we can use the following command:

socat TCP4-LISTEN:80,fork,su=nobody,reuseaddr "TCP6:[1234:ab12::4321]:80"

So let’s decipher this a little bit:

• TCP4-LISTEN:80: socat should listen to any traffic on port 80
• fork: create a new process on every new connection. This is necessary to support multiple connections simultaneously.
• su=nobody: Not 100% sure, but I think this changes the newly created processes to the unprivileged nobody user, reducing the risk of security issues.
• reuseaddr: With this option, socat does not bind to port 80 exclusively. This is very helpful when restarting the script, as after killing a program using a socket, it takes several seconds, until it is available again.
• "TCP6:[1234:ab12:0:...:4321]:80": This tells socat to forward any traffic to the specified IPv6 address (e.g., 1234:ab12::4321) on port 80.

A script to rule it all

Ok, fairly simple, and for testing purposes it is sufficient to run the above command in a terminal on the VPS, but to automate this, I’ve written the following script:

#! /bin/bash

UPDATE_INTERVAL=15 # check for new IPv6 addresses every 15 seconds
IP_ADDR_FILE=/home/jonathan/ipv6address.txt

function start_socat {
        socat TCP4-LISTEN:80,fork,su=nobody,reuseaddr "TCP6:[$1]:80" &
        ID_SOCAT_80=$!
        socat TCP4-LISTEN:443,fork,su=nobody,reuseaddr "TCP6:[$1]:443" &
        ID_SOCAT_443=$!
}

SERVERADDR=$(cat $IP_ADDR_FILE)
start_socat $SERVERADDR

# recreate socat processes if necessary
while true; do
        SERVERADDR_NEW=$(cat $IP_ADDR_FILE)

        if [ "$SERVERADDR_NEW" != "$SERVERADDR" ]; then
                SERVERADDR=$SERVERADDR_NEW
                date
                echo "IP_difference: IP address: $SERVERADDR new IP address: $SERVERADDR_NEW"
                kill $ID_SOCAT_80 $ID_SOCAT_443
                sleep 5
                start_socat $SERVERADDR
        fi
        sleep $UPDATE_INTERVAL
done

What this script does is, that it reads my NAS’ IPv6 address from a file ipv6address.txt and starts two socat processes - one for port 80 (http) and one for port 443 (https). The remainder of the script is simply polling the file with the IPv6 address and recreates the socat processes with adjusted IPv6 addresses if necessary. At the same time, a cronjob on my NAS was constantly updating the IPv6 address file via SSH, something like:

IPv6_ADDRESS=$(ip -6 a | grep 'global' | grep -v 'deprecated'| \
               awk '{print $2}' | grep -v '^fd' | grep -v '^fc' | \
               sed 's|/.*||' | head -n1)
ssh user@vps-server 'echo IPv6_address > /home/jonathan/ipv6address.txt'

Systemd Service

Ok, last thing to do is to create a systemd service, so that the script above is started automatically and output is logged nicely with journald. Create /etc/systemd/socat_forward.service with the following content:

[Unit]
Description=Socat IPv4 to IPv6 forward

[Service]
ExecStart=/home/jonathan/socatscript.sh
Restart=on-failure

[Install]
WantedBy=multi-user.target

Execute systemctl enable socat_forward.service && systemctl start socat_forward.service, and the VPS forwards all port 80 & 443 traffic to the NAS.

I’d be happy to hear if you are using this technique or something similar! 🙂👍

Sure, this is an easy task to solve with mounting holes, but then you’d have the screw head or a nut sticking out the bottom, ruining the slick design and maybe providing a tempting piece for users to fiddle with. Also, one of the entities in this project contains 8 M4 threaded rods that need to be mounted on top of the PCB.

For this purpose, we have so far used Würth SMD screw terminals. These are basically some round pieces of metal with a screw terminal, that can be soldered onto a PCB and provide a way to screw something to the PCB. I believe, they are actually intended as an attachment point for some high amperage wires with ring terminals, but they serve our purpose as well. So far so good, but there is a drawback with this approach: The terminals are fucking expensive! Seriously, they cost 2.50 € per piece, so 18 € total for a PCB which otherwise contains fairly cheap components.

Heat inserts to the rescue.

I don’t exactly recall the genesis, but a friend of mine and I had an idea on how to reduce these costs down to a few cents: Simply use brass heat-inserts instead. Heat-inserts not only occupy one of the top-places on my whish-I’d-known-this-earlier list when used as intended, but because they’re made of brass they can be soldered without any issues. Oh, and they cost basically nothing - you can get them for ~0.05€ per piece on AliExpress.

Evaluation

I had some scrap PCBs lying around, and coincidentally also one with a plated hole that was the perfect footprint for a M4 insert. So as you can see, we have tried that part, a piece of prototype board, and a normal PCB with a heat sink pad for a microcontroller.

So just add some solder paste, put it on a heat plate and -voilà- that worked pretty well. But does it hold?

So, that works surprisingly well. A little thrilled, we tried to push our luck even further:

We were completely blown away on how well this worked. And this was just a plain copper pad on the PCB. The insert that was sunk in the hole worked equally well (I forgot to take a photo). With enough force, we eventually broke off the insert, but this is definitely strong enough any normal applications. BTW, the prototype board did delaminate before the insert snapped off:

Summary

So TLDR: Heat-inserts are a cheap and solid way of attaching screws to a PCB. I’d be curious to hear if you can use this technique in a project, feel free to drop me a mail if you do! 😀

In could set up a Grafana/Telegraf stack for this and install some alerts, but this is a lot of work and I actually already have a monitoring system running, that can display nice time-series data and notify me conditionally: Home Assistant! So let’s integrate the probe there.

Adding a new MQTT Sensor in Home Assistant:

Probably the most straightforward communication interface to Home Assistant (HA) is most likely MQTT, and I’m already using it for some ESP-Home devices. In addition, it is pretty easy to send MQTT messages via the command line, using mosquitto_pub.

Ok, so what exactly do we need to send? Home Assistant has a device auto discovery mechanism for MQTT, meaning that whenever a certain message is posted to a certain topic, it will automatically create a device from that message’s body. This topic follows the schema <discovery_prefix>/<component>/[<node_id>/]<object_id>/config. discovery_prefix defaults to homeassistant and a list of possible component values hides in the device class documentation. node_id can be ignored and as we use restic_backup as object_id we get homeassistant/sensor/restic_backup/config as the discovery topic.

The payload of this message defines the device and the device we want should simply report whether a backup is currently running or not. Any additional logic such as last run can then be implemented in Home Assistant. Honestly, I found it pretty hard to understand how this payload has to look like, and it took me quite some trial-and-error, but this is how a working autodetect payload for this scenario looks like:

{
    "name": "Restic Backup",
    "device_class": "enum",
    "state_topic": "homeassistant/sensor/restic_backup/state",
    "unique_id": "restic_backup_mqtt1",
    "device": {
        "name": "Restic Backup",
        "identifiers": [ "restic_backup" ]
    }
}

• name is obvious, and as we just report a status, device_class should be enum.
• The state_topic tells Home Assistant, where the device will report the status, and it can be rather arbitrary.
• If you omit the unique_id, you can find the sensor in the Entities section, but the readings will not be listed in the according Device.
• The device part was quite confusing to me, as this is kind of inverted logic: You don’t specify this very sensor here, but the device that this sensor gets assigned to. If you have multiple sensors with the same device section, they are “grouped” together.

According to the documentation, there are other ways to write the payload, but, honestly, I had quite some trouble understanding the details. Anyway, the above configuration is good enough here.

Let’s send this to the broker and check if we have a new device now:

> mosquitto_pub -h 192.168.0.25 -p 1883 -r \
    -t "homeassistant/sensor/restic_backup/config" \
    -m '{ "name": "Restic Backup", "device_class": "enum",
        "state_topic": "homeassistant/sensor/restic_backup2/state",
        "unique_id": "restic_backup_mqtt1",
        "device": { "name": "Restic Backup", "identifiers": [ "restic_backup" ] } }'

Note, that we use -r here so that the device is persistent in Home Assistant (at least until the Broker has a restart). Anyway, we can now also send a message to state_topic and observe the status changing in the web UI:

> mosquitto_pub -h 192.168.0.25 -p 1883 -r \
    -t "homeassistant/sensor/restic_backup/config" -m ''

Integration with restic

Ok, now we have a proof-of-concept. The next step is to combine this with the backups. Fortunately, the restic container I’m using supports hooks for executing a script before and after the backup. But as the container doesn’t have mosquitto installed by default, we need to add this to the container first. As described in the previous post, we are using a custom Dockerfile anyway, so we just have to add one line to the file:

FROM lobaro/restic-backup-docker:latest
RUN mkdir -p /root/.ssh && ln -s /run/secrets/user_ssh_key /root/.ssh/id_rsa
RUN chown -R root:root /root/.ssh
RUN printf "Host 10.13.13.5\n\tStrictHostKeyChecking no\n" >> /root/.ssh/config
# Install mosquitto
RUN apk add mosquitto-clients

Ok, now we can finally create our hooks. We create a folder hooks and in this the two scripts pre_backup.sh and post_backup.sh: They are called before/after the backup and the logic we want is quite simple:

• Publish the auto-discovery message. (It doesn’t matter if it was already published, as we don’t alter it)
• The pre_backup.sh script publishes Running as status.
• The post_backup.sh script checks the exit code of restic to determine whether the backup was successful or not, and publishes Idle or Error as status.

So this is the resulting pre_backup.sh:

#!/bin/sh

mosquitto_pub -h $MQTT_SERVER -p $MQTT_PORT -r \
        -t "homeassistant/sensor/$NAME/config" \
        -m "{\
            \"name\": \"$NICE_NAME\", \
            \"device_class\": \"enum\", \
            \"unique_id\": \"$NAME-mqtt1\", \
            \"state_topic\": \"homeassistant/sensor/$NAME/state\", \
            \"device\": { \"name\": \"$NICE_NAME\", \"identifiers\": [ \"$NAME\" ] } \
        }"

mosquitto_pub -h $MQTT_SERVER -p $MQTT_PORT \
        -t "homeassistant/sensor/$NAME/state" \
        -m 'Running'

And post_backup.sh looks as follows:

#!/bin/sh

mosquitto_pub -h $MQTT_SERVER -p $MQTT_PORT -r \
        -t "homeassistant/sensor/$NAME/config" \
        -m "{ \
            \"name\": \"$NICE_NAME\", \
            \"device_class\": \"enum\", \
            \"unique_id\": \"$NAME-mqtt1\", \
            \"state_topic\": \"homeassistant/sensor/$NAME/state\", \
            \"device\": { \"name\": \"$NICE_NAME\", \"identifiers\": [ \"$NAME\" ] } \
        }"

# Check restics return code
if [ "${1:-0}" = "0" ]; then
    mosquitto_pub -h $MQTT_SERVER -p $MQTT_PORT \
            -t "homeassistant/sensor/$NAME/state" \
            -m 'Idle'
else
    mosquitto_pub -h $MQTT_SERVER -p $MQTT_PORT \
            -t "homeassistant/sensor/$NAME/state" \
            -m 'Error'
fi

And we shouldn’t forget to make the scripts executable:

chmod +x hooks/pre-backup.sh hooks/post-backup.sh

If you wonder where we have defined NAME, MQTT_SERVER, etc.: Congratulations, you’ve been paying attention. We set them in our docker-compose.yml!

The full compose file can be found in the first post on this setup, so here just the new bits:

---
services:
  wireguard:
    # ...

  restic-backup:
    container_name: restic_nas
    build:
      context: .
      dockerfile: Dockerfile
    environment:
      - RESTIC_REPOSITORY=sftp:jonathan@10.13.13.2:/data/backup/server
        # ...
      - RESTIC_FORGET_ARGS=--keep-last 2 --keep-monthly 3
        # The environment variables for the MQTT hook
      - MQTT_SERVER=192.168.0.25
      - MQTT_PORT=1883
      - NAME=restic_nas
      - NICE_NAME=Restic NAS
    volumes:
        # Mount the hook-scripts
      - ./hooks:/hooks:ro
      - /zstorage/git:/data/git:ro
        # ...
    # ...

We build the compose file and manually trigger a backup to check if it is working:

> docker-compose up --force-recreate --remove-orphans -d --build
> docker exec -ti restic-backup /bin/sh
/ > /bin/backup
Starting pre-backup
#...

Automations in Home Assistant

Ok, almost done. All that’s left is creating an automation in HA. I’m just running a simple one, and there is room for improvement, but at least I get a warning if there was no backup or the backup threw an error:

alias: Restic Backup Warning
description: ""
mode: single
triggers:
  # Backup sensor is in "Error" state
  - entity_id:
      - sensor.restic_backup
    to: Error
    id: Backup Error
    trigger: state
  # No backup has started in more than a day
  # (e.g., probe is offline, MQTT shenanigans)
  - entity_id:
      - sensor.restic_backup
    to: Idle
    for:
      hours: 25
      minutes: 0
      seconds: 0
    id: No backup
    trigger: state
conditions: []
actions:
  # Send a Signal message.
  - data:
      message: There is an issue with the backups! ()
    action: notify.signal

Additional sensors

But wait - there’s more! As we can input basically any measurements in Home Assistant, what about the status of the probe itself? Especially the disk usage would be very interesting for the backup probe. So I was about to tinker some shell scripts that read CPU temperature, but then I found the system_sensors project, which had it already done, just better than what I’d have tinkered.

Ok, then let’s set it up:

> git clone https://github.com/Sennevds/system_sensors.git
> sudo apt-get install python3-dev python3-apt
> cd system_sensors && pip3 install -r requirements.txt
> cp src/settings_example.yaml src/settings.yaml

Now we adapt the MQTT settings, deviceName and other settings to our liking, and try it out with:

python3 src/system_sensors.py src/settings.yaml

We should now see a new device with plenty of sensors in Home Assistant:

I leave it as an exercise to the reader to build some fancy automations with this data and end this post with a screenshot of my dashboard (yes, my NAS is also sending the status via MQTT).

Nobody likes them, few people do them, and you really only start to appreciate them once you need them but don’t have them. I’ve set up a kind of dual-stage backup system for my computers and my home-server which is working fine so far. There surely is room for improvement and more redundancy but nevertheless, I thought it is might be worth sharing.

General Idea

I already run daily backups to my home-server via Back in Time. Back in Time is using rsync under the hood, provides a quite usable GUI and has the cool features, that the backups are real files and folders on the remote. But the fancy thing is, that you have separate folders for each backup, but they don’t multiply the memory need by using Hard-links internally. What does that mean? Let’s imagine you have a file foo.txt which hasn’t changed between the backups. Back In Time would then create a folder for each backup and places the file inside. You’ll end up with something like 2022-01-20/foo.txt and 2022-01-21/foo.txt. The clever thing is, both file tree entries actually point to the same bytes on your hard drive and only once consume the memory.

backups
├── 2022-01-20
│   ├── foo1.txt   <------+
│   └── foo2.txt          |
└── 2022-01-21            |
    ├── foo1.txt   <------+----- no changes - same file on disk
    └── foo2.txt   <---- had changes - new file on disk

I like doing it this way in my LAN, because file restoration is really simple: You just mount the remote file system, navigate to the file and copy-paste it back where you want it. The drawback is missing encryption (even though Back In Time supports this) and no compression.

But this setup was missing an offsite component so far to protect the data from any kind of “misfortune” like fire, lightning or a wild horde of rhinos (better be prepared for this!). Many people seem to use cloud storage for such an application, but I didn’t like the idea of giving my most sensible data into some company’s hand (even though encrypted). For this, I decided to use a different tool: Restic. It is a very advanced command line based backup tool which support numerous storage back-ends. One of the common applications is to back up your data to cloud storage. In comparison to the first tool, restic has its own data storage format, and you also need restic to restore the backups again. (Of course, both are open-source tools).

The Probe

What I wanted was a device which I can give to a friend and tell him: “Can you please plug this to your router? Thanks!” and everything run’s automatically. I had an Odroid-XU4 lying around for some time collecting dust, and it seems that this project is a good opportunity to put it to real use. With it’s USB3 port it was a better choice for a storage application than e.g., a Raspberry < 4.

Hardware

Besides the Odroid, I of course needed a disk, and the largest 2.5” one I could find back then was the “Seagate Barracuda ST5000LM000” with 5 TB. I also picked the shortest SATA-USB3 adapter cable I could find for a reasonable price. (Update: The Seagate died after ~2 Years, now I’m trying a WD MyPassport, which does not require an addapter.)

It took me a few attempts to design the enclosure. I first tried something more compact, but then I’d end up with the HDD directly below the CPU, which was suboptimal. Also, the USB-SATA cable caused a lot of headache. But the final design is ok and I only need this once, so…

The HDD is located in a kind of pan, which I filled with silicone I had lying around. The small bracket you can see above the HDD keep it secured in the custom bed.

My original idea was to use some push rod mechanism for the Odroid’s button, but this didn’t work out (and I accidentally destroyed the button on the PCB), so instead I soldered the red button with some wires to the board, which worked fine.

Software

Disclaimer: It’s been a while since I set up the whole thing, so I couldn’t check all these commands upon writing again

So besides WireGuard, the probe isn’t really running any special software. The starting point is an Armbian-Focal (Ubuntu based) installation on that machine with ssh access and pubkey authentication. I assume that you are familiar with setting up such a system.

External Disk:

The external disk is configured with Btrfs. Of course, you can use different file systems, but I felt like this is the way to go.

To create the Btrfs partition on the disk (obviously, replace the aaaaa-bbb-… id with the one for your drive):

# create the mountpoint
> mkdir /data
# create the filesystem on the external disk
> mkfs.btrfs /dev/disk/by-uuid/aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee

To automatically mount the disk, the disk has to be added to to /etc/fstab as follows:

UUID=aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee /data btrfs defaults,compress,autodefrag,inode_cache  0   1

Now might be a good time for a reboot.

You can verify that everything worked with the following command:

> mount -l | grep /data
# should be like:
/dev/sda1 on /data type btrfs (rw,relatime,compress=zlib:3,...)

Unattended upgrades

As the probe won’t be maintained actively, it might be a good idea to enable unattended-upgrades. Unattended upgrades is already installed, we just have to enable it:

> sudo dpkg-reconfigure --priority=low unattended-upgrades
# ...
# Check if it worked:
> apt-config dump APT::Periodic::Unattended-Upgrade
APT::Periodic::Unattended-Upgrade "1";

Warning: beware that a power-outage during such an upgrade might render your installation useless. However, the backups *shouldn’t* be affected by this.

Power tweaking of the Odroid-XU4

The idle power use of a device running 24/7 is actually relevant. I measured the Odroid and it draws ~3.5W. A single watt you can save sums up to ~9 kWh over a year. It’s not that much but 2.5€ is at least something, especially if you give it away and let your friends pay the bill.

You can play around with the /sys filesystem and tweak the frequencies and governors of the system:

# Limit the frequency of the first 4 cores to 1GHz
> echo 1000000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
# Disable CPUs 4-7
> echo 0 > /sys/devices/system/cpu/cpu4/online

I found, that the minimum frequency is set to 600 MHz, which can be reduced to 200 MHz with scaling_min_freq (check scaling_available_frequencies).

The changes made with the commands above are not persistent. Multiple ways exist to make them persistent and I used the sysfsutils package and modified /etc/sysfs.conf:

devices/system/cpu/cpu0/cpufreq/scaling_governor = ondemand
devices/system/cpu/cpu0/cpufreq/scaling_min_freq = 200000
devices/system/cpu/cpu4/cpufreq/scaling_governor = ondemand
devices/system/cpu/cpu4/cpufreq/scaling_min_freq = 200000

You can also check the /boot/boot.ini to do more tweaks like clocking down the RAM.

WireGuard Server Setup

Ok, the Odroid is running for now and now we have to go back to the home-server and set up the WireGuard server. Not that I’m a Docker evangelist, but I found it actually pretty handy to use containers for the services on the home-server. So I also utilized it for the VPN and the backup routine, even though you surely can set it up without docker as well.

Please note: It is important that this machine is reachable from outside your network. Otherwise you’d need another server which is and acts as a VPN master.

So I’m using the linuxserver.io Dockerfile for this. Basically I’m mostly copying their docker_compose.yaml. I only adapted the SERVERURL to the one my home-server is using and of course made sure that the selected SERVERPORT port is reachable.

Running docker-compose up -d should be sufficient to start the server now!

If you take a look at the folder selected for the WireGuard config, you’ll see a number of folders peer1, peer2 … with predefined configs for the clients of the vpn - convenient, isn’t it?

WireGuard Client Setup

We now go back to the backup probe and install WireGuard:

> apt install wireguard

Easy! Now copy the content of one of the peerX.conf files mentioned before into /etc/wireguard/wg0.conf:

[Interface]
# The new wireguard IP of the probe
Address = 10.13.13.2
PrivateKey = XXXXXXXXX
ListenPort = 51820
DNS = 10.13.13.1

[Peer]
PublicKey = YYYYYYYYY
# My server's url
Endpoint = my.very-own.url.org:51820
AllowedIPs = 10.13.13.0/24
PersistentKeepalive = 25

Important: The PersistentKeepalive is required, as the Probe is most likely behind a NAT and thus not reachable from outside my friend’s home network. With that parameter set, the probe sends a keepalive package to the server every 25 seconds, which keeps the connection open and enables us to ssh and backup anytime.

Verify that it works with:

> wg-quick up wg0
# ...

Now we check on the home-server or another machine in the same WireGuard network if this works:

> ping 10.13.13.2 # the IP set in the peerX.conf
PING 10.13.13.2 (10.13.13.2) 56(84) bytes of data.
64 bytes from 10.13.13.2: icmp_seq=1 ttl=63 time=59.1 ms
64 bytes from 10.13.13.2: icmp_seq=2 ttl=63 time=44.3 ms
# nice!

> ssh jonathan@10.13.13.2
# ...

At the moment, VPN connection is lost after a reboot. But this can be changed with systemd. We just have to enable the corresponding service:

> systemctl enable wg-quick@wg0
> systemctl start wg-quick@wg0 # (Otherwise a reboot is required)

Now is a good time to reboot the probe and check if the setup works so far.

ExecStartPre=/bin/bash -c 'until host my.very-own.url.org; do sleep 1; done'

Restic Setup

You could now install various cloud storage systems as back-ends on the probe, but the most simple one at this point and for this use case is probably SFTP/SSHFS. We use the Dockerfile provided by lobaro. However, with the plain Dockerfile, we would have to store the password for the probe in plaintext in the compose file, and it would also appear in the logs. So we extend the Dockerfile a bit and utilize Docker secrets to mount an ssh key in the container, so we can use passwordless authentication.

FROM lobaro/restic-backup-docker:latest
# secrets are mounted at /run/secrets. Here we link the secret into the container's ssh config:
RUN mkdir -p /root/.ssh && ln -s /run/secrets/user_ssh_key /root/.ssh/backup_probe_key
# Ensure correct permissions. SSH won't work if these are incorrect.
RUN chown -R root:root /root/.ssh
# Disable the "trust host message" in the container.
RUN printf "Host 10.13.13.2\n\tStrictHostKeyChecking no\n" >> /root/.ssh/config

If you haven’t done before, at the latest now we need an ssh key to log into the probe:

# (Optional:) Generate a new key:
> ssh-keygen -t ed25519 -C "your_email@example.com"
# Copy the key (here: backup_probe_key) to the probe:
> ssh-copy-id -i ~/.ssh/backup_probe_key -o PreferredAuthentications=password -o PubkeyAuthentication=no jonathan@10.13.13.2

Ok, now we are ready to tackle the restic configuration: First we want to create a .env file to hold our backup’s password (the docker-compose.yml is really not the best place for these).

RESTIC_PASSWORD=asdfasdfasdf123412341234

Note: A handy way to generate passwords is pwgen: pwgen -n 30 1 generates a 30 character alphanumeric password.

Ok, now so here’s the section of the docker-compose.yml with the actual backup configuration:

---
version: "3.3"
services:
  restic-backup:
    depends_on:
      - wireguard
    container_name: restic-backup
    build:
      # use the local Dockerfile
      context: .
      dockerfile: Dockerfile
    secrets:
      - user_ssh_key
    environment:
      # repository location: /data/backup/server on the probe
      - RESTIC_REPOSITORY=sftp:jonathan@10.13.13.2:/data/backup/server
      # The name of the ssh key inside the container (not really necessary)
      - RESTIC_KEY_HINT=backup_probe_key
      # Every second day at 12:00
      - BACKUP_CRON= 0 12 2-30/2 * *
      # keep the last 2 backups plus one for the last 3 months.
      - RESTIC_FORGET_ARGS=--keep-last 2 --keep-monthly 3
    env_file:
      - .env
    volumes:
      # Backup the folders /zstorage/web and /home/jonathan
      - /zstorage/git:/data/git:ro
      - /home/jonathan/:/data/home:ro
      # ...
    restart: unless-stopped
    # Same network as the wireguard container so we can access the probe
    network_mode: service:wireguard

secrets:
  user_ssh_key:
    # create the secret for the ssh key (here: .ssh/backup_probe_key)
    file: /home/jonathan/.ssh/backup_probe_key

Note the addition of :ro in the volumes section to mount the folders as read-only. This ensures that anything wonky on your remote, backup configuration or in the wireguard network at least can’t change your files.

Final compose file

All that is left is to combine the two sections of the compose file and run docker-compose up -d.

---
version: "3.3"
services:
  wireguard:
    image: ghcr.io/linuxserver/wireguard
    container_name: wireguard
    cap_add:
      - NET_ADMIN
      - SYS_MODULE
    environment:
      - PUID=1000
      - PGID=1000
      - TZ=Europe/Berlin
      - SERVERURL=my.very-own.url.org
      - SERVERPORT=51820
      - PEERS=5
      - PEERDNS=auto
      - INTERNAL_SUBNET=10.13.13.0
      - ALLOWEDIPS=10.13.13.0/24
    volumes:
      - /home/jonathan/wireguard/config:/config
      - /lib/modules:/lib/modules
    ports:
      - 51820:51820/udp
    sysctls:
      - net.ipv4.conf.all.src_valid_mark=1
    restart: unless-stopped

  restic-backup:
    depends_on:
      - wireguard
    container_name: restic-backup
    build:
      context: .
      dockerfile: Dockerfile
    secrets:
      - user_ssh_key
    environment:
      - RESTIC_REPOSITORY=sftp:jonathan@10.13.13.2:/data/backup/server
      - RESTIC_KEY_HINT=backup_probe_key
      - BACKUP_CRON= 0 12 2-30/2 * *
      - RESTIC_FORGET_ARGS=--keep-last 2 --keep-monthly 3
    env_file:
      - .env
    volumes:
      - /zstorage/git:/data/git:ro
      - /home/jonathan/:/data/home:ro
      # ...
    restart: unless-stopped
    network_mode: service:wireguard

secrets:
  user_ssh_key:
    file: /home/jonathan/.ssh/backup_probe_key

Checking the Backup

Almost as important as creating a backup: Checking that you can restore from it. One way is, to mount the backup, so you can navigate it with a normal file manager:

> mkdir /tmp/restic
> restic -r sftp:jonathan@10.13.13.2:/data/backup/server mount /tmp/restic

After entering your RESTIC_PASSWORD, you should find your backup at /tmp/restic.

Happy Backuping!

I own an Artillery Genius 3D printer since now more than 1.5 years, and now the temperature sensor’s cable broke. This is unfortunate, because I’ve read multiple times that a strain relief for this cable is an upgrade you should definitely print. But I’ve constantly ignored it. Ok, lesson learned. (BTW: The ribbon cable of this printer also needs a strain relief!)

As a hotfix, I replaced the broken part of the cable, which surprisingly worked for a few prints but is certainly something from the do-not-try-this-at-home category. Be reminded that the heating bed of this printer operates at 230V! Looking at the picture, you will surely come to the same conclusion I did: This won’t last very long.

The Upgrade

You can just buy a new heat mat for ~35€, but since I’m on it anyway, I decided to directly go for an upgrade of the complete heat bed.

The stock glass surface is just fine, but the heat-matte is not doing a good job in heating the plate evenly. You can see from the following picture that the corners, above the mounting screws, the bed is significantly cooler than in the center. No problem for small prints, but this has ruined a few larger prints already.

It is rather difficult to find a different heat mat, at least if you don’t want to import something from the USA or China. The only thing I found was the Princore Genius Heat Mat from a German shop. There is more choice for aluminum beds, so I chose the following for no particular reason: ABS Maschinenschutz Heat Bed

The assembly was mostly straightforward. You need to shorten the cables and have to pay attention not to damage anything. Some remarks on this:

• It is advisable to use ring terminals to attach the new wires to the printer.
• ⚠️ Only do this if you know what you are doing! 230V are dangerous! ⚠️
• ⚠️ The bed MUST be connected to ground ⚠️

Ok, so does this improve the situation? I’m not doing a scientific level analysis here, but I do have some results:

First, I wanted to know if the mat heats more evenly than the stock one which has the cross shape heating characteristic. So I’ve taken a thermal camera picture of the bottom of the heat bed without any isolation:

It’s a bit hard to judge if the mat heats up more evenly, or we do mostly see the effects of the metal plate dissipating the heat more evenly, but it looks better than before!

But what about the obviously more important surface temperature?

I’d say, this looks quite nice. Definitely better than before! The plate also seems to be sticky enough, but I only did one short test-print so far.

The bottom is very smooth. You see small gaps, which I’ll tackle later on. So for now, in all I’m rather pleased. Is it worth the 100€? Hmm, time will tell. Let’s see how long this will last. But if you don’t want to spend the money, be sure to print and attach a strain relief, so your bed will last longer than mine!

• This one for the bed. You have to attach it to the metal plate which is holding the bed screws.
• I have printed this relief for the X-axis ribbon cable, but it needed some manual adaption since it is made for the Sidewinder X1 and not for the Genius.

Happy Printing 🖨

Preface

I didn’t found any time and motivation to write something here, but I guess it’s time for an updated version of my previous post on Rust on the STM32F1 I plan to make more shorter and more modular posts, but to get started, here is a short tutorial on how to get started:

🎉 Blink an LED in Rust on a cheap microcontroller. 🎉

What you need

• A PC with an installed Rust Toolchain (which also should involve cargo). I only run Linux, but the following is likely to run on MacOS as well, and maybe even on Windows.
• A Board with an STM32F103 microcontroller. The most common dev-boards with this controllers are probably the “BluePills” which you usually can get for less than 2€ (e.g. on Aliexpress). We use a BluePill, but other Boards should work very similar. Attention: Especially on Aliexpress there exists an incredible amount of counterfeit chips. If it does not work, this might be the reason.
• An Programmer. Among the cheapest programmers you can get for the STM chips is a ST-Link V2 Clone (AliExpress). The Programmer itself is a clone and often contains an “CS32” chip instead of an STM32. Again: Might be a source of trouble.

Software Preparation

At first, let’s make sure we have an up-to-date compiler and cargo:

> rustup update

Then we’ll install the cross-toolchain for the STM32F1, which runs a thumbv7m-none-eabi ARM core:

> rustup target install thumbv7m-none-eabi

For now, we use cargo flash to program the microcontroller. We can comfortably install this tool via cargo:

> cargo install cargo-flash

And finally we create a new Rust project in a directory of our choice with

> cargo init rusty-blink

Before we write any code, we configure the project, so that it compiles for our thumbv7m-none-eabi target by default and uses the correct linker script (more on that in a second). We do this by creating a file .cargo/config in our project root.

# .cargo/config
[build]
# Always compile for the instruction set of the STM32F1
target = "thumbv7m-none-eabi"

# use the Tlink.x scrip from the cortex-m-rt crate
rustflags = [ "-C", "link-arg=-Tlink.x"]

The next we need is the linker script which tells the linker about the memory layout of the chip. It must lay in the project root and is called memory.x. For the STM32F103C8 this looks as follows:

/* memory.x - Linker script for the STM32F103C8T6 */
MEMORY
{
  /* Flash memory begins at 0x80000000 and has a size of 64kB*/
  FLASH : ORIGIN = 0x08000000, LENGTH = 64K
  /* RAM begins at 0x20000000 and has a size of 20kB*/
  RAM : ORIGIN = 0x20000000, LENGTH = 20K
}

Ok, enough preparation, lets get to Rust/Cargo!

The Blinky Program

Of course, you need a Cargo.toml file to configure your project. There is already one present in your project folder, but we need to add some dependencies and configurations: (These are current versions as of mid July 2020).

# Cargo.toml
[package]
edition = "2018"
name = "blinky-rust"
version = "0.1.0"

[profile.release]
opt-level = 'z' # turn on maximum optimizations. We only have 64kB
lto = true      # Link-time-optimizations for further size reduction

[dependencies]
cortex-m = "^0.6.3"      # Access to the generic ARM peripherals
cortex-m-rt = "^0.6.12"  # Startup code for the ARM Core
embedded-hal = "^0.2.4"  # Access to generic embedded functions (`set_high`)
panic-halt = "^0.2.0"    # Panic handler

# Access to the stm32f103 HAL.
[dependencies.stm32f1xx-hal]
# Bluepill contains a 64kB flash variant which is called "medium density"
features = ["stm32f103", "rt", "medium"]
version = "^0.6.1"

And finally: Here is a simple blink program! Don’t be afraid, it only looks that long because I added the explanatory comments. Without it’s only ~30 lines 😉.

// src/main.rs

// std and main are not available for bare metal software
#![no_std]
#![no_main]

use cortex_m_rt::entry; // The runtime
use embedded_hal::digital::v2::OutputPin; // the `set_high/low`function
use stm32f1xx_hal::{delay::Delay, pac, prelude::*}; // STM32F1 specific functions
#[allow(unused_imports)]
use panic_halt; // When a panic occurs, stop the microcontroller

// This marks the entrypoint of our application. The cortex_m_rt creates some
// startup code before this, but we don't need to worry about this
#[entry]
fn main() -> ! {
    // Get handles to the hardware objects. These functions can only be called
    // once, so that the borrowchecker can ensure you don't reconfigure
    // something by accident.
    let dp = pac::Peripherals::take().unwrap();
    let cp = cortex_m::Peripherals::take().unwrap();

    // GPIO pins on the STM32F1 must be driven by the APB2 peripheral clock.
    // This must be enabled first. The HAL provides some abstractions for
    // us: First get a handle to the RCC peripheral:
    let mut rcc = dp.RCC.constrain();
    // Now we have access to the RCC's registers. The GPIOC can be enabled in
    // RCC_APB2ENR (Prog. Ref. Manual 8.3.7), therefore we must pass this
    // register to the `split` function.
    let mut gpioc = dp.GPIOC.split(&mut rcc.apb2);
    // This gives us an exclusive handle to the GPIOC peripheral. To get the
    // handle to a single pin, we need to configure the pin first. Pin C13
    // is usually connected to the Bluepills onboard LED.
    let mut led = gpioc.pc13.into_push_pull_output(&mut gpioc.crh);

    // Now we need a delay object. The delay is of course depending on the clock
    // frequency of the microcontroller, so we need to fix the frequency
    // first. The system frequency is set via the FLASH_ACR register, so we
    // need to get a handle to the FLASH peripheral first:
    let mut flash = dp.FLASH.constrain();
    // Now we can set the controllers frequency to 8 MHz:
    let clocks = rcc.cfgr.sysclk(8.mhz()).freeze(&mut flash.acr);
    // The `clocks` handle ensures that the clocks are now configured and gives
    // the `Delay::new` function access to the configured frequency. With
    // this information it can later calculate how many cycles it has to
    // wait. The function also consumes the System Timer peripheral, so that no
    // other function can access it. Otherwise the timer could be reset during a
    // delay.
    let mut delay = Delay::new(cp.SYST, clocks);

    // Now, enjoy the lightshow!
    loop {
        led.set_high().ok();
        delay.delay_ms(1_000_u16);
        led.set_low().ok();
        delay.delay_ms(1_000_u16);
    }
}

Let’s build it!

> cargo build --release
   Compiling semver-parser v0.7.0
   Compiling typenum v1.12.0
   [...]
   Compiling cortex-m-rt-macros v0.1.8
   Compiling stm32f1xx-hal v0.6.1
   Compiling blinky-rust v0.1.0 (/home/xxx/xxx/Rust/embedded/rusty-blink)
    Finished release [optimized] target(s) in 34.63s

For the blink example you can leave out the --release, but when you compile a more complicated program you will run out of device memory fast without optimization enabled.

My resulting program takes 864 bytes of memory (2,8kB without LTO). To check this, you have to convert the compiler output (an elf file) to hex/binary. You can for example use arm-none-eabi-objcopy -O binary target/thumbv7m-none-eabi/release/blinky-rust blinky-rust.bin and then ls.

Now you are ready to flash the controller with cargo flash. It should auto-detect your ST-Link and use it to program the microcontroller. You only have to specify the target chip (stm32f103C8).

> cargo flash --chip stm32f103C8 --release
    Finished release [optimized] target(s) in 0.02s
    Flashing /home/xxx/xxx/Rust/embedded/rusty-blink/target/thumbv7m-none-eabi/release/blinky-rust
        WARN probe_rs::architecture::arm::core::m4 > Reason for halt has changed, old reason was Halted(Request), new reason is Exception
        WARN probe_rs::architecture::arm::core::m4 > Reason for halt has changed, old reason was Halted(Breakpoint), new reason is Request
        WARN probe_rs::architecture::arm::core::m4 > Reason for halt has changed, old reason was Halted(Request), new reason is Exception
     Erasing sectors ✔ [00:00:00] [#############################]   1.00KB/  1.00KB @   1.49KB/s (eta 0s )
 Programming pages   ✔ [00:00:01] [#############################]   1.00KB/  1.00KB @     583B/s (eta 0s )

(The warnings can be ignored, cargo flash is still a young project and has some faults.)

You should now see the blinking onboard LED!

I’m hyped! What’s next?

Good you asked! I prepared some link’s for you:

• The stm32f1xx_hals documentation
• Plenty of examples for the stm32f1xx_hal
• You can find this example’s code on Gitlab

I also plan to do some more posts on this, but you know… time and motivation. If you have any questions or want to remind me to write some more posts, feel free to contact me! 🙂👍

DEPRECATED: I have created a more up-to-date version of this article. You can find it here !

GOAL: Blink the onboard LED on a BluePill board using Rust on a Linux Mint (Ubuntu based) machine.

Update/Information: The rustc version I used is rustc 1.31.1 (stable) and you need to install the ARM target with rustup target add thumbv7m-none-eabi beforehand.

I also put the code on Gitlab.

Preface

I have mainly used Atmel microcontrollers so far, but they are rather expensive, slow and have a totally confusing pinout. (And I think, they have no real future). So I wanted to use a better controller and setup the flow to program it on my Linux Mint machine (should work on Ubuntu as well). I assume, that the reader already has at least a little knowledge in Rust, Linux, and Microcontrollers

One of the possibly cheapest and general purpose boards is the STM32F103 board aka “BluePill”. These sell for less than 2€ on AliExpress, but I’d recommend you the more up-to-date version, the “BlackPill” (AliExpress), because the BluePill usually has a wrong resistor which causes trouble when using the USB port. Besides a slightly different pinout and the BlackPill being one row larger than the BluePill, they are basically the same.

Setting up the Cargo Project

First, we initialize a new Cargo project

> cargo init stm32_blink
> cd stm32_blink

We modify our Cargo.toml file as follows to include the required libraries:

[package]
name = "stm32_blink"
version = "0.1.0"
edition = "2018"

[profile.release]
# optimize for size ('z' would optimize even more)
opt-level = 's'
# link with link time optimization (lto).
lto = true
# enable debugging in release mode.
debug = true

[dependencies]
# Gives us access to the STM32F1 registers
stm32f1 = {version = "0.6.0", features = ["stm32f103", "rt"]}
# provides startup code for the ARM CPU
cortex-m-rt = "0.6.7"
# provides access to low level ARM CPU registers (used for delay)
cortex-m = "0.5.8"
# provies a panic-handler (halting cpu)
# (required when not using stdlib)
panic-halt = "0.2.0"

I the cortex-m-rt crate also requires a memory.x file, which specifies the memory layout of the board (See the documentation). The documentation already provides the file for the BluePill as an example, so we only have to create the file memory.x with the following content:

/* Linker script for the STM32F103C8T6 */
MEMORY
{
  FLASH : ORIGIN = 0x08000000, LENGTH = 64K
  RAM : ORIGIN = 0x20000000, LENGTH = 20K
}

We can now compile the program using cargo rustc --target thumbv7m-none-eabi -- -C link-arg=-Tlink.x, but that would be a bit inconvenient. Therefore, we create the file .cargo/config (and the folder .cargo) with the following content (based on this file):

[build]
# Instruction set of Cortex-M3 (used in BluePill)
target = "thumbv7m-none-eabi"

rustflags = [
  # use the Tlink.x scrip from the cortex-m-rt crate
  "-C", "link-arg=-Tlink.x",
]

Hoooray, now we can compile Rust code into an ARM elf file! (However, the code we have does not compile yet)

> cargo build --release
> file target/thumbv7m-none-eabi/release/stm32_blink
target/thumbv7m-none-eabi/release/stm32_blink:
ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV),
statically linked, with debug_info, not stripped

The Blink Program

This is the content of the src/main.rs file:

// std and main are not available for bare metal software
#![no_std]
#![no_main]

extern crate stm32f1;
extern crate panic_halt;
extern crate cortex_m_rt;

use cortex_m_rt::entry;
use stm32f1::stm32f103;

// use `main` as the entry point of this application
#[entry]
fn main() -> ! {
    // get handles to the hardware
    let peripherals = stm32f103::Peripherals::take().unwrap();
    let gpioc = &peripherals.GPIOC;
    let rcc = &peripherals.RCC;

    // enable the GPIO clock for IO port C
    rcc.apb2enr.write(|w| w.iopcen().set_bit());
    gpioc.crh.write(|w| unsafe{
        w.mode13().bits(0b11);
        w.cnf13().bits(0b00)
    });

    loop{
        gpioc.bsrr.write(|w| w.bs13().set_bit());
        cortex_m::asm::delay(2000000);
        gpioc.brr.write(|w| w.br13().set_bit());
        cortex_m::asm::delay(2000000);
    }
}

Explanation: #![no_std] is required, because we build a bare-metal application but the standard library requires an operating system. #![no_main] tells the compiler that we don’t use the default main function with the argument vector and return type. This wouldn’t make sense, since we don’t have an OS or other kind of runtime which would call the function and handle the return value. Instead, the cortex_m_rt crate contains a minimal runtime and the #[entry] macro, which specifies our custom entry function (fn main () -> ! {}), which we call main as well (don’t be confused). More information about bare metal software in Rust can be found for example in the “Writing an OS in Rust” Blog.

Inside the main function we create a handle to the peripheral object, which “owns” all the peripherals and registers with stm32f103::Peripherals::take(). rcc and gpioc are handles to the “reset and clock control” and GPIO register bank C (the onboard LED on my BluePill is connected to pin C13 but this might differ).

To use a pin as output we have to enable the clock for that specific GPIO pin bank by setting the IOPCEN bit in the APB2EN register. Writing a byte in a peripheral register using the stm32f1 crate is done by calling the write function on that register struct (rcc.apb2enr.write()). This function takes a FnOnce function as an argument. The parameter which is passed to this function is in the first case of type gpioc::crh::W which implements functions to access the single bit fields in that very register (here: w.iopcen()). This in turn has a function set_bit, which is used to set the bit in that hardware register and thus enabling the clock for the GPIO C bank.

The same applies for the CRH register, which is used to configure the pin as an output pin at highest speed (MODE=0b11 and CNF=00). The bits function of the mode13 and cnf13 bit field is unsafe, but I can’t tell you why. Therefore, we have to mark the functions inside the closure as unsafe as well.

Hint: To get a documentation of the stm32f1 crate, generate it yourself with cargo doc --open

In the infinite loop, we write to the Port bit set/reset register (BSRR) and the Port bit reset register (BRR) to set pin C13 to high respectively low.

The delay function busy waits for at least the given number of cycles. The number here was just randomly taken and represents around 250ms. The better approach would be to utilize the onboard timers, but for this simple example, delay is sufficient.

Creating the Binary

For the next steps, we need an ARM toolchain installed on our system. On Linux Mint (Ubuntu), this can be done with:

> sudo apt install binutils-arm-none-eabi

Update: I use the toolchain from the Ubuntu package manager. The toolchain which is installed with the thumbv7m target can also be invoked using Cargo (I’ll try this next time).

Optional: Disassembly

We can now view the disassembly of the elf file:

> arm-none-eabi-objdump --disassemble \
  target/thumbv7m-none-eabi/release/stm32_blink | less

So far, we only operated with the elf file. This format does not only contain the binary code but also some headers and stuff (see Wikipedia). This is useful, when another software like an operating system or bootloader launches the file. However, to run the program bare-metal we don’t need an elf file, but rather a bin file. This is an image of the software which can be written byte-by-byte into the memory of the microcontroller.

An elf file can be converted into a bin file with objcopy.

> arm-none-eabi-objcopy -O binary \
  target/thumbv7m-none-eabi/release/stm32_blink stm32_blink.bin

The stm32_blink.bin is now ready to flash.

Flashing the Binary

There are multiple ways to program the board, for example using the UART, using a USB bootloader (like the Arduino has), or using a programmer like an ST-Link. I’m using a ST-Link-V2 clone, which are almost as cheap as the Pill itself (AliExpress). You can even flash one yourself out of a BluePill/BlackPill.

Connect the 4 pins SWDIO, GND, SWCLK, and 3.3V on the programmer with the corresponding pins on the BluePill and plug it into your PC. Important: Disconnect any other power supply from the board, otherwise you can damage the board or in the worst case your PC.

There are other ways to program the board with the ST-Link, such as openocd, but I will use the open-source stlink tools. Unfortunately, this software is not available via the apt package manager, therefore we have to compile it from source.

# in a directory of your choice:
> sudo apt install libusb-1.0 libusb-1.0-0-dev
> git clone https://github.com/texane/stlink
> cd stlink
> make all

This creates the executables st-flash and st-info, which reside now in build/Release/. There are different approaches to “install” these executables. I will now copy them into a system folder. However, it may be desirable to only copy them into a folder in your home directory which is added to $PATH or simply prefix all commands with the full path to the executable instead.

> sudo cp build/Release/st-{flash,info} \
  build/Release/src/gdbserver/st-util /usr/local/bin
> which st-info
/usr/local/bin/st-info

Optional: Udev Rules

To access the ST-Link without root permissions, copy the udev rules from the source code to /etc/udev/rules.d/

> sudo cp etc/udev/rules.d/*.rules /etc/udev/rules.d
> sudo udevadm control --reload-rules && udevadm trigger

We can verify the connection:

> st-info --descr
F1 Medium-density device

Optional: Erase existing software/bootloaders:

I had a stm32duino bootloader running on my BluePill, which lead to errors like WARN common.c: unknown chip id! 0x5fa0004 upon flashing. To fix that, I had to erase the chip. This is done by executing the following command right after pressing the reset button on the board:

> st-flash erase

To flash the bin file, we execute:

> st-flash write stm32_blink.bin 0x8000000
st-flash 1.5.1-12-g30de1b3
2019-02-07T00:23:15 INFO common.c: Loading device parameters....
#[...]
2019-02-07T00:23:15 INFO common.c: Flash written and verified!
  jolly good!

Success!

Summary of Commands to Build and Flash the Software:

> cargo build --release
> arm-none-eabi-objcopy -O binary \
  target/thumbv7m-none-eabi/release/stm32_blink stm32_blink.bin
> st-flash write stm32_blink.bin 0x8000000

That’s it! Now the LED on the board is blinking!

On AliExpress I found a replacement part for around 50€. It arrived soon (about 1 week) and after I payed additional 10€ as import VAT, so the total costs were about 65€.

Step 1 - Open the Backside of the Laptop

The first step was to open the laptop.

Step 2 - Disassembly of the Laptop

Then I removed the battery and the fan to remove the mainboard. Unfortunately, two screws of the mainboard are located below the CPU’s heatpipes. So I had to remove the cooler as well.

Step 3 - Realize that you fucked up and revert everything

At this point I found out, that you can’t remove the keyboard because it is riveted to the case. Great! So I had do reassemble the Laptop. Removing the CPU-cooler was totally unnecessary. I applied some more heat-conducting paste to the cooler, but I only had the cheap one at home. This works, but I ordered some better one to ensure my CPU stays cool (which is a major issue with this laptop).

However, I can still change the layout by removing the key-caps and replacing them with the ones from the US-keyboard.

When you remove the caps you have to be very careful, the “scissors”-mechanism break extremely easy. In the whole project I broke two of them. (But I’ve still got a whole keyboard full of replacement parts 🤷)

Summary: I now have a nice US layout on my laptop, it has cost a lot of money for a rare use case and I have to apply new heat-conducting paste to my cooler 👍.

Dirk came around and joined the handicraft group. So we went out and bought the wood for it.

One long post (8cm * 8 cm I think), two boards for the cross-bars, and two for the upper and lower mount.

First, we cut the long post into the three pieces and laid everything out to draw the cut lines for the cross-bars. (It was a bit of a challenge, that the floor of the gallery was not parallel to the ceiling).

We decided to cut slots into the posts and stick the cross bars into it. This avoids the need for brackets and is probably more stable. I cut the slots with my router, Dirk cleaned up the slots with a chisel and Laura sanded the posts. I wanted to create a router jig, but I forgot the wood to do it, so we used scrap wood and clamps to create some guides for the router. It was not super precise, but as the cross bars overlap the cuts a little bit, this was OK.

Then we could assemble it and put it in place to validate it.

Laura doesn’t like the optics of light wood, so she painted it dark. Once the paint was dry, we drilled the holes into the ceiling and the floor (which was super loud and one drill broke) and screwed it in.