How to backup a Raspberry Pi SD card on a Mac

One thing that is quite appealing about the Raspberry Pi is that the entire state of the system is on one tiny SD card. Clone the card and you clone the system. Copy the card and you have backed up the system. Re-flash the card with an old image and you have returned the system to a known good state. There are lots of possibilities here.

Being able to write an image to a card is pretty much an essential in the Raspberry Pi world (unless you resort to only buying pre-written NOOBS SD cards). Luckily writing an image to a card is really easy with the elegant, free Etcher.

Creating an image from a card seems slightly more challenging. A bit of Duck Duck Going (or Googling if you are into that sort of thing) will lead to a number of sites explaining how to do this from the command line with dd. I found only one site suggesting using Disk Utility and suggesting a process that would allow me to use Etcher with the resulting file. Sadly following the instructions didn’t work for me.

After a fair bit of fiddling around I managed to get this working for me. It is a simple process, but there are two little wrinkles to be aware of:

1.    Make an image of the entire “drive” not just the partition.
2.    Format the image as “DVD/CD Master” and then rename the .cdr file to .iso for use with Etcher.

So here is how to do it in a little more detail:

1.    Insert the SD card into the card reader.

2.   Open Disk Utility and locate your card reader. Using the internal reader in my Mac and a freshly minted Raspbian card this is what I see:


3.    Select the drive (not the boot partition) and select File | New Image | Image from “Untitled”.

4.    In the Save As dialog set the format to “DVD/CD Master”. This will create a .cdr file.

5.    Save the new image. This could take a while (~20 mins on my machine for a 16Gb disk). If this only takes a minute or less you have probably selected the boot partition and not the whole card.

6.    Rename the .cdr to .iso and it is ready for use with Etcher.

To be frank, I am not convinced that this is the optimal way to do this. It is a slow process as you spend a lot of time carefully copying blank space. I will experiment some more, but in the meantime this process works for me.

Happy copying and flashing!

Reawakening the inner geek

I have always been a Lego person. It was one of my favourite toys as a child and still has a place in my life as an adult and a Dad (although sharing might not be my strong suit).

As a bit of a geek I was always taken with the idea of Mindstorms. I got the original Mindstorm kit (with the big yellow RCX brick and the IR transmitter) and played around with it a little, but never really got into it. When EV3 was released I lusted after it but hesitated because of my earlier experience. Eventually my wonderful wife gave me a set as a present. Again I played around for a while, but it never really grabbed me.

Recently I dragged it back out and started to play, and this time I got hooked. The key thing for me was finding ev3dev!

I had always quickly become frustrated with the block-based programming tools that Lego provides. Perhaps they are great for kids (although I have my doubts), but for me they are painfully cumbersome and limited. I wanted a command line, an IDE and the concise power of a full function textual language.

I knew that it was possible to use a custom Linux instal on the EV3 brick and use a range of ‘real’ languages. When I investigated this in the past I was put off by the idea of changing the firmware. This seemed like a great way of potentially bricking my brick, and then needing to invest significant time in getting it back to a working state.

This time when I investigated the options I found ev3dev. The thing that immediately caught my eye was that it ran off a microSD card rather than requiring a firmware change. As soon as I saw this I was off. Within an hour I had downloaded ev3Dev, flashed it to a card, had the brick up and running, and connected to it with SSH.

Just seeing the “robot@ev3dev:~$” prompt on the terminal window of my Mac was a complete game changer. Imaging the possibilities! It is the same feeling I had as a kid when I found that the TRS-80 BASIC could do 3-D arrays, or when playing with 6502 assembler on the Apple ][. This is why I love technology.

I decided to start with Python, a language I do not know well and want to know better. I grabbed a copy of PyCharm Edu, set-up a GIT project on the brick and started coding (see note 1 below). I had been playing with a basic robot based on the Lego Educator Vehicle (modified because I do not have the EV3 Education kit) and had been doing simple line following using the block based system. I quickly had a Python version running, and was able to refine it without all of he frustrations that I had been hitting.

My next project was to build a plotter. As a teenager on work experience at a computer centre in the 80’s I spent many happy hours watching a plotter at work, and have never lost the fascination with them. It took a few hours to build a basic working version, and a few more hours to refine and extend it, and generally tinker. It was all highly satisfying.

Thank you EV3 for reminding me what it feels like to be a geeky kid again!

1. With hindsight, GIT was probably overkill and I would have been better off just using scp to push the single python files from Mac to brick.

When does Auto Layout kick in?

In my usual loveable (perhaps somewhat annoying) style, this is a rambling story of my struggles with Auto Layout. If you want to cut to the chase, feel free to skip to the last few paragraphs.

I must admit that I have long resisted the charms of Auto Layout. When I tried to use it I felt as though I was fighting it to get it to do what I wanted, and that it was a liability rather than an assistance. Of course this is often the way when you first start using a powerful feature. It takes time to learn enough to be productive.

Recently I sat myself down and gave myself a stern talking to about this situation. Having mulled over the wisdom of my words I buckled down to come to grips with Auto Layout.

I created a small testbed app to simulate the main behaviours I wanted to implement in an existing app. Within a couple of hours I had that working fine, so I started to implement it in the existing app. That went pretty smoothly but one seemingly strange behaviour kept bugging me …

I laid out my UI in the standard 600x600 view that Interface Builder presents. Of course this meant that many of the UI elements were a different size than would be the case on an actual device. But that’s OK because that is the entire point of Auto Layout. Right ? Put the UI on a device and Auto Layout does it’s thing and all is well.

The problem was that “the first time around” my code was seeing sizes for UI elements that were appropriate for the 600x600 layout, but not for the device. At “some later point” in the code Auto Layout seemingly kicked in and the sizes were as expected. It wasn’t immediately clear when this happened.

On the whole the app was working fine, which in itself was a bit confusing if it was initially thinking it was on a 600x600 view. The issue showed up in some minor ways, but not enough to stop me cold. Nevertheless this niggled at me. Obviously all was not working as I expected or could explain - never a good situation if you want stable code.

My first thought was to force Auto Layout to kick in earlier in the process. I played around with a few options until in desperation I resurrected a real kludge that was commented out in my code, left over from trying to troubleshoot a rotation problem a few years ago. This involved presenting and dismissing a modal view controller with no view (yes, yes, I know).

This came up with a warning about presenting a view on view controller that was not in the view hierarchy. Bingo! Everything suddenly clicked into place.

The code that was seeing the non-updated layout was being called from viewDidLoad, so was occurring before the view was added to the window. Without being part of the view hierarchy Auto Layout had no overall size to play with so could do nothing. When I moved the code from loadView to viewDidAppear: it worked as expected.

So the moral of this story is do not interrogate sizes and positions of UI elements that you expect Auto Layout to manage until after the view is in the view hierarchy (ie. viewDidAppear or later).

A corollary to this is do not remove a view from the hierarchy and expect it to keep it's Auto Layout controlled attributes. I had a bit of logic that swapped a view out of the hierarchy to rebuild the subviews and then swapped it back in. Under Auto Layout it appeared to get a zero size when swapped out.

The other moral of this story is never accept unexplained behaviour in your code. It can be monumentally frustrating at times but when the lightbulb goes on, all becomes clear and it is marvellous. These moments are what I love about being a developer.