Setting up a micropython editor with the BBC micro:bit v2 on Linux

This post follows on from my blog post that shows how to set up the mu-editor in Linux for v1 of the micro:bit. This blog post is here:

https://www.seismicmatt.com/2021/01/05/setting-up-mu-editor-with-the-bbc-microbit-on-linux/

I couldn’t get the mu-editor to work with micro:bit v2. This was frustrating as I wanted to check some existing code ran on v2 of the micro:bit as well as start to use some of the new feautures on board.

I solved this by following a tip from a comment on my first post. This recommended using a different editor and following some setup instructions for that editor.

I will call this editor the PythonEditor as this is the name of the project’s GitHub site:

https://github.com/bbcmicrobit/PythonEditor

The PythonEditor can be used online at:

https://python.microbit.org/v/2

Python Editor can also run offline. Initially, the editor would not recognise any micro:bits that were attached to my laptop. The information that I needed to follow to get PythonEditor working is here:

https://support.microbit.org/support/solutions/articles/19000105428-webusb-troubleshooting

In case this site is removed, I replicate this information below and add one or two tips of my own.

I use <user> to represent whatever user name you are using. I use Debian 10 on a Lenovo X260 and X230.

Create a udev rule to get the micro:bit to be recognised

Create the file:

/etc/udev/rules.d/50-microbit.rules

with this content:

SUBSYSTEM=="usb", ATTR{idVendor}=="0d28", MODE="0664", GROUP="plugdev"

To create this file you need to be root or use the sudo command. I created and edited the file using vim:

sudo vim /etc/udev/rules.d/50-microbit.rules

Add <user> to plugdev group

To add your username to the plugdev group:

sudo usermod -aG plugdev <user>

To have this change recognised by the system, we need to restart the udev rules:

sudo udevadm control --reload-rules 

The webpage I followed to get this far says to log out and back in. I did not do this and things worked out.

Using PythonEditor online.

The online PythonEditor only works in Chrome for me. The editor now connected with micro:bit v1 and v2 and would program them. The first time that I flashed code to the micro:bit v2 took a while, with a message saying that the initial flash could take a while, but subsequent flashes would be faster. This is the case. I suspected that the first flash copied a micropython hex file to the micro:bit.

Using PythonEditor offline

The PythonEditor source code can be downloaded from GitHub and run offline. The instructions on how to do this are on the GitHub site, linked at the start of this post. This is how I run the PythonEditor. If we look in our downloaded GitHub repository, in the folder:

PythonEditor/micropython

we find two .hex files:

microbit-micropython-v1.hex 
microbit-micropython-v2.hex

I suspected that copying the v2.hex file to the micro:bit v2 was necessary before it would work with either of the editors.

So I took my spare micro:bit v2, connected it and tried to look at it with the serial connection on the PythonEditor. Nothing – a blank screen. I dragged and dropped the microbit_micropython-v2.hex file onto it using the Nautilus file explorer. After the requisite 10 seconds or so of flashing on the micro:bit as it loaded the hex, I tried again with the serial connection on PythonEditor and saw this:

PythonEditor serial connection with micro:bit v2

I see something similar when I click the REPL button on the mu-editor. I also get a REPL when I use the cu command I talked about in my earlier blog:

cu -l /dev/ttyACM0 -s 115200

So copying over the .hex file is a necessary step. PythonEditor does this for us if we haven’t done it already.

So now I have some tools to program micropython on the micro:bit v2.

mu-editor with micro:bit v2

I can get this working with v2 of the micro:bit after getting PythonEditor up and running. But it is not stable for me. Sometimes it works, sometimes it doesn’t. If I can figure out a reliable way of making this run, I’ll edit this post.

There is some cryptic information in this post, which says that the UART buffer needs to be cleared to get the mu-editor to work.

https://github.com/mu-editor/mu/issues/1162

I like the mu-editor and hope that I can get it up and running. Right now, I am relying on a single tool to program the micro:bit v2.

Summary of how to get micro:bit v2 working with a micropython editor

  • Create the udev rule.
  • Add <user> to plugdev group.
  • Add .hex file to the micro:bit

To do

I use the uflash or pyboard scripts with v1 of the micro:bit to enable me to use e.g. vscode to edit micropython and have a script automagically load updated code to the micro:bit. So far I have not gotten anything like this set up for the micro:bit v2. I would like this. I’ve gotten used to the idea that setting up programming environments requires tenacity.

Setting up mu-editor with the BBC micro:bit v1 on Linux

I recently set up an installation of Debian 10 and set up a tool chain for programming the BBC micro:bit with micropython. I’d forgotten some of the stumbling blocks I had the last time I did this, so am recording them here. Hopefully, this post will help you avoid them.

I use <user> to represent the user name that I log in with.

The instructions in this blog get you set up to work with the micro:bit v1 using mu-editor.

Part 2 shows how to set up a different editor that works with both v1 and v2 of the micro:bit under Debian. The link for part 2 is at the end of this post. I tried and failed to get mu-editor to work reliably with the micro:bit v2.

Install mu-editor

Use your package manager! In my case:

sudo aptitude install mu-editor

Using the package manager installs a bushel of python3 libraries, which you may not like. I tried the clean method of setting up a virtual environment and downloading the mu repository from GitHub. I ended up trying to install various dependencies that have other dependencies… In the end I gave up and used the package manager. One line. Installed.

Many people use apt-get instead of aptitude. I think both commands use the same libraries under the hood.

Finding the micro:bit

Which port does the micro:bit mount under? In my case /dev/ttyACM0. One way to find the port is with this command:

sudo dmesg | grep tty
[  135.410510] cdc_acm 1-6:1.1: ttyACM0: USB ACM device

The last line of the output gives the game away. /dev/ttyACM0 it is.

Setup permissions

We need to add our user name to the dialout group in /etc/group

When I first setup Debain and then tried to connect to a micro:bit on port /dev/ttyACM0 using Debian 10, I could only do this as root. Why?

ls -al /dev/ttyACM0

displays:

crw-rw-rw- 1 root dialout 166, 0 Jan 5 16:13 /dev/ttyACM0

This indicates why we can access the port using sudo – the port is owned by root. It also shows why adding the non-root user to the dialout group allows access without being root. I added my user account to the dialout group in /etc/group using:

sudo usermod -a -G dialout <user>

Enabling the micro:bit to mount under /media/<user>

I still could not connect with the micro:bit using a serial port monitor without being root.

The micro:bit is mounted under /media/<user>/MICROBIT.

ls -al /media/<user>
drwxr-x---+  2 root  root  4096 Jan  5 12:44 <user>

This shows that the directory that the micro:bit is mounted on is owned by root. I needed to change the owner and group of this directory to <user>.

sudo chowner /media/<user>
sudo chgrp /media/<user>

Now I can mount the micro:bit under /media/<user>/MICROBIT. I found I had to get this set up for mu-editor to allow me to program the micro:bit and use the REPL.

I wrote a blog post a few years ago presenting a bash script to find and mount or dismount a micro:bit here.

Terminal monitors

I came across the cu terminal monitor. To install and use with the micro:bit:

sudo aptitude install cu
cu -l /dev/ttyACM0 -s 115200

Hit ctrl-c and you get a REPL. The way to exit it is using the cryptic characters:

~.

The tilda character ‘~’ stands for <escape> in this instance.

The nice people at micropython produced a script called pyboard.py which finds a connected micro: bit and opens a terminal to display the output from the micro:bit. This tool is detailed at: http://docs.micropython.org/en/latest/reference/pyboard.py.html.

gtkterm is another useful serial terminal monitor which runs in its own GUI. Install using:

sudo aptitude install gtkterm

micro:bit v2 issues

The above all works for micro:bit v1. When I tried to flash some code to the micro:bit v2 using the mu-editor, I get this pop-up:

I can now run the latest mu-editor from the mu GitHub repository at: https://github.com/mu-editor/mu. However, I still got the same error when trying to use it with a micro:bit v2.

To run the latest version, download the GitHub repository, then type:

python run.py

in the downloaded mu directory. I guess that installing mu-editor using aptitude also installed all of the necessary dependencies to enable the GitHub version to run. The GitHub version is 1.1.0.alpha.3. The version installed using aptitude is 1.0.2.

I tried programming the micro:bit v2 using pyboard.py. This also failed.

After posting this blog with these issues, Mark left the comment at the end of this post that helped me get a different editor working with v2 of the micro:bit. The comment came the same day that I posted the blog! I was well chuffed as I didn’t realise that anybody reads my blog posts, let alone the same day as I posted them. I guess a lot of people are searching for how to get micro:bit v2 running right now.

So I wrote a new post detailing how to setup and run a micropython editor with v2 of the micro:bit:

https://www.seismicmatt.com/2021/01/07/setting-up-a-micropython-editor-with-the-bbc-microbit-v2-on-linux/

Getting the login screen on hotel WiFi using Linux

Problem

I can see that I am connected to the hotel WiFi on my laptop, but the login screen does not come up on my browser. So I cannot access the Internet.

My laptop is connected to a private IP address on the hotel network, but I cannot access the login page on a browser to get access to the world wide web

I run Debian 10, using the i3 tiling manager. I use wicd as my network manager and Firefox as the browser.

My mobile phone automagically connects to the hotel WiFi and brings up the login screen. So I know that the WiFi is working and allows access to the Internet.

How do I get the WiFi login screen on my laptop?

Solution – short answers

Using iproute

Type:

ip route

Example output:

default via 192.168.96.1 dev wlp3s0 
192.168.96.0/20 dev wlp3s0 proto kernel scope link src 192.168.108.193

Look at the first line ‘default via 192.168.96.1’. Put the value 192.168.96.1, or whatever you have for that value in the first line, into your browser address bar. This should take you to the login screen.

Using /etc/resolv.conf

Look in the file /etc/resolv.conf after connecting to the WiFi and type the private IP address in this file into your browser.

To see the contents of this file, type:

more /etc/resolv.conf

Here’s the output I got. Yours will probably have a different content:

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 192.168.96.1
nameserver 8.8.8.8
nameserver 8.8.4.4

When I put the private IP value (192.168.96.1 in this example) into Firefox, the login screen appeared.

Victory looks like this – the hotel login page

Hopefully, one of these methods works for you. I put an expanded explanation and the background story below. I like background stories. Makes me feel like I’m not the only one who has trouble figuring things out.

I use a VPN when accessing the world wide web. This adds a layer of security when using public networks.

Background

Our internet connection use a domain name system(DNS) server to find out where to go to get the contents for the web addresses we ask it to access. The file /etc/resolv.conf contains the IP addresses of the DNS servers in use by the current connection. This file is automatically created when you set up a new connection.

Looking at the contents of /etc/resolv.conf after I connected with the hotel WiFi, I recognise the IP addresses 8.8.8.8 and 8.8.4.4 as Google DNS addresses. This makes sense. Google will have a database of what website is where if anybody does.

The IP addresses 192.168.0.0 to 192.168.255.255 are reserved for private network addresses.

The IP address of 192.168.96.1 in the file /etc/resolv.conf is one of the addresses reserved for private networks. So this looks to be the local access point. This makes sense. The IP address for the login page is a private address on the hotel network, not accessible on the world wide web where anybody could have a go at logging in to the hotel WiFi.

Putting this IP value (192.168.96.1) into Firefox has us directed to the local login page.

I finally got to grips with this during the Covid 19 pandemic. I spent some time quarantining in a hotel in Rio de Janeiro before joining a survey ship to work offshore Brazil.

It works, then doesn’t the next time you use it

Try clearing the browser cache.

Disable any VPN you are using while connecting, then re-enable the VPN.

I hope this post is of use to others. I welcome any comments and corrections.

ssh to a pi zero w from a linux box

There are many sites and YouTube videos explaining how to connect the pi zero to a laptop or desktop using a USB cable, then access the pi zero from the laptop using ssh. Here is a link to one guide.

I followed a guide on YouTube but had a few problems connecting to the pi zero w using ssh through Linux. Each time I put in:

ssh pi@raspberrypi.local -p22

I got a blank line which then timed out and displayed:

ssh: Could not resolve hostname raspberrypi.local: Name or service not known

I successfully connected to the pi zero w using putty on a Windows 8 machine. Putty is ssh with a nice GUI interface. Windows is ‘plug and play’. I run Linux without a GUI, so have ‘plug, learn and play’ instead. Time to learn.

I fired up nm-applet, using the command:

nm-applet

Then I went to ‘Edit connections’. The pi zero w will often be the highest numbered ‘Wired connection’. In my case it was ‘Wired connection 2’. Edit this. Go to the IPv4 Settings tab. Select Link-Local Only for the method. See a screenshot showing the setup below.

Raspberry pi zero w ssh connection configuration

After saving the updated configuration, the ssh command works.

Booting a new Lenovo Thinkpad from USB stick to use Clonezilla

All I wanted to do was boot from my trusty Clonezilla USB stick to make a system back up of my shiny new Thinkpad X260. Long story short, you need to disable the ‘Secure Boot’ option in the UEFI (what used to be called BIOS) to boot from a bootable Clonezilla USB stick.

 
I bought the X260 a couple of month’s ago. This is last year’s model, so I got it at a discount. Usually I’d buy a 2/3 year old Thinkpad and replace the drive and keyboard, but found I could buy a new laptop, albeit last year’s model for about half of what it would’ve cost a year ago. A quick cleansing of the OS by installing Linux Mint. The usual kerfuffle to configure the system and remember how to partition the drive, then try to remember how to mount said partitions. Time to make an image of the OS partition. I’ve learned this is a good idea the hard way. When I tried to boot from my Clonezilla USB sticks, none of them would work! Somehow I had made a bootable USB stick that would install Linux Mint. I spent a good hour before checking on the ‘Secure Boot’ option in the UEFI screen, which by default is Enabled. Flicking this to Disabled solved this issue. 
 
Now I have an image of my OS on an external drive for when I manage to destroy the installation. Not if. When. Still, that’s how we learn, by breaking and fixing. Probably a good thing that I don’t work in medicine.

Installing linux mint 18.1 onto a Lenovo 260 with an encrypted home drive

The simplest way I found to install Linux Mint 18.1 on to my Lenovo 260 with an encrypted home drive and a separate installation partition is to install the system using the simplest options, then afterwards encrypt your home drive and shrink down the installation partition using gparted. The rest of this post is how I failed to do this several times. Which is undoubtedly due to my lack of linux wisdom.
 
I tried and failed to install Linux Mint 18.1 on to custom partitions for my root, home and swap. The system would not boot after I completed the installation. I could not install grub to the /mnt partition to fix this. I tried some stackoverflow solutions with no joy.
 
So I did a simple install, clicking on the option to encrypt the home folder. Then I used gparted on the installation USB stick to shrink down the partition. However, my swap space was also encrypted, which I understand increases security. Every time I booted I was presented with message asking for a non-existent password to mount the encrypted swap space. No real issue, I just hit enter and carried on to the regular login screen. Then I tried updating the system. For each update I had to press enter to mount the encrypted swap space. A little tedious. So I went on stack overflow, found a ‘fix’ and rendered the system unbootable. This was getting a little tedious.
 
So I again installed Linux Mint 18.1 from my USB stick. This time I chose the vanilla, easiest options, no encryption. I used the instructions here to encrypt my home drive. I used the installation stick to run gparted and shrink down the partition. So now I have Linux Mint installed on a partition and an encrypted home drive.
 
Simple. Hind sight always is.