Autumn in Canada: PicoMite version

more leaves

So I ported autumn in canada from OpenProcessing to PicoMite BASIC on the Raspberry Pi Pico:

a small black screen images with text in the centre: autumn in canada scruss, 2021-11 just watch ...
no leaves
a small black screen images with text in the centre: autumn in canada scruss, 2021-11 just watch ... with one red and one orange maple leaf sitting on top of it
a couple of leaves
a small black screen images with text in the centre: autumn in canada scruss, 2021-11 just watch ... with four red/yellow/orange maple leaves sitting on top of it
more leaves
a small black screen images with text in the centre: autumn in canada scruss, 2021-11 just watch ... with sixteen simulated fallen maple leaves mostly covering it
plenty of leaves
a small black screen image completely covered with many simulated fallen maple leaves
far too many leaves

The biggest thing that tripped me up was that PicoMite BASIC starts arrays at 0. OPTION BASE 1 fixes that oversight. It would have been nice to have OpenProcessing’s HSV colour space, and an editor that could handle lines longer than 80 characters that didn’t threaten to bomb out if you hit the End key, but it’ll serve.

Source below:

' autumn in canada
' scruss, 2021-11
' a take on my https://openprocessing.org/sketch/995420 for picomite

OPTION base 1
RANDOMIZE TIMER
' *** initialize polar coords of leaf polygon and colour array
DIM leaf_rad(24), leaf_ang(24), px%(24), py%(24)
FOR i=1 TO 24
    READ leaf_rad(i)
NEXT i
FOR i=1 TO 24
    READ x
    leaf_ang(i)=RAD(x)
NEXT i

DIM integer c%(8)
FOR i=1 TO 8
    READ r%, g%, b%
    c%(i)=RGB(r%,g%,b%)
NEXT i

' *** set up some limits
min_scale%=INT(MIN(MM.HRES, MM.VRES)/8)
max_scale%=INT(MIN(MM.HRES, MM.VRES)/6)
min_angle=-30
max_angle=30
min_x%=min_scale%
min_y%=min_x%
max_x%=MM.HRES - min_x%
max_y%=MM.VRES - min_y%

CLS
TEXT MM.HRES/2, INT(MM.VRES/3), "autumn in canada", "CM"
TEXT MM.HRES/2, INT(MM.VRES/2), "scruss, 2021-11", "CM"
TEXT MM.HRES/2, INT(2*MM.VRES/3), "just watch ...", "CM"

kt%=0
DO
    cx% = min_x% + INT(RND * (max_x% - min_x%))
    cy% = min_y% + INT(RND * (max_y% - min_y%))
    angle = min_angle + RND * (max_angle - min_angle)
    sc% = min_scale% + INT(RND * (max_scale% - min_scale%))
    col% = 1 + INT(RND * 7)
    leaf cx%, cy%, sc%, angle, c%(7), c%(col%)
    kt% = kt% + 1
LOOP UNTIL kt% >= 1024

END

SUB leaf x%, y%, scale%, angle, outline%, fill%
    FOR i=1 TO 24
        px%(i) = INT(x% + scale% * leaf_rad(i) * COS(RAD(angle)+leaf_ang(i)))
        py%(i) = INT(y% - scale% * leaf_rad(i) * SIN(RAD(angle)+leaf_ang(i)))
    NEXT i
    POLYGON 24, px%(), py%(), outline%, fill%
END SUB

' radii
DATA 0.536, 0.744, 0.608, 0.850, 0.719
DATA 0.836, 0.565, 0.589, 0.211, 0.660, 0.515
DATA 0.801, 0.515, 0.660, 0.211, 0.589, 0.565
DATA 0.836, 0.719, 0.850, 0.608, 0.744, 0.536, 1.000
' angles
DATA 270.000, 307.249, 312.110, 353.267, 356.540
DATA 16.530, 18.774, 33.215, 3.497, 60.659, 72.514
DATA 90.000, 107.486, 119.341, 176.503, 146.785, 161.226
DATA 163.470, 183.460, 186.733, 227.890, 232.751, 270.000, 270.000
' leaf colours
DATA 255,0,0, 255,36,0, 255,72,0, 255,109,0
DATA 255,145,0, 255,182,0, 255,218,0, 255,255,0

You could probably use AUTOSAVE and paste the text into the PicoMite REPL. I used an ILI9341 SPI TFT LCD Touch Panel with my Raspberry Pi Pico along with some rather messy breadboard wiring.

Fun fact: the maple leaf polygon points are derived from the official definition of the flag of Canada.

Raspberry Pi Zero 2 W: slides and thermals

2 out of 4 cores burning, 32-bit mode: time to overheat = basically never

Slides from last night’s talk:

It’s impossible to have a Raspberry Pi Zero overheat unless you overclock it. That’s why you don’t get any cases for it with fans or heat sinks. The quad-core Raspberry Pi Zero 2 W, though, has the potential to do so. Here are some numbers:

  • Used official case with lid fitted: increases SoC temperature +3 °C over free air
  • Test – CPUBurn: https://github.com/pmylund/cpuburn
  • Tested 4, 3 and 2 cores burning in 32-bit and 64-bit modes: time from idle to throttling (80 °C) measured
  • GPU overheat not tested.
line graph of cpu temperature against time. Temperature rises sharply from about 47 degrees C to 82 degrees C in around four minutes
All 4 cores burning, 64-bit mode: time to overheat = under 3½ minutes
line graph of cpu temperature against time. Temperature rises sharply from about 47 degrees C to 82 degrees C in just over four minutes
All 4 cores burning, 32-bit mode: time to overheat = just over 4 minutes
line graph of cpu temperature against time. Temperature rises moderately from about 47 degrees C to 81 degrees C in around seven minutes
3 out of 4 cores burning, 64-bit mode: time to overheat = just over 7 minutes
line graph of cpu temperature against time. Temperature rises slowly from about 47 degrees C to 81 degrees C in around ten minutes
3 out of 4 cores burning, 32-bit mode: time to overheat = 9½ minutes
line graph of cpu temperature against time. Temperature rises very slowly, reach 70 degrees C in 40 minutes and then only rising very slightly to about 73 degrees C in the entire run time of 3 hours 20 minutes
2 out of 4 cores burning, 32-bit mode: time to overheat = basically never

Unless you’re doing things that might indicate you should be using a bigger computer, a Raspberry Pi Zero 2 W won’t overheat and doesn’t need any form of cooling. If you’re overclocking, well … it’s your choice to have cooling equipment worth more than the computer it’s trying to cool.

Raspberry Pi Zero 2 W: initial performance

Running A Pi Pie Chart turned out some useful performance numbers. It’s almost, but not quite, a Raspberry Pi 3B in a Raspberry Pi Zero form factor.

32-bit mode

Running stock Raspberry Pi OS with desktop, compiled with stock options:

pie chart comparing multi-thread numeric performance of Raspberry Pi Zero 2 W: slightly faster than a Raspberry Pi 2B
multi-thread results
pie chart comparing single-thread numeric performance of Raspberry Pi Zero 2 W: slightly faster than a Raspberry Pi 2B
single-thread results
time ./pichart-openmp -t "Zero 2W, OpenMP"
pichart -- Raspberry Pi Performance OPENMP version 36

Prime Sieve          P=14630843 Workers=4 Sec=2.18676 Mops=427.266
Merge Sort           N=16777216 Workers=8 Sec=1.9341 Mops=208.186
Fourier Transform    N=4194304 Workers=8 Sec=3.10982 Mflops=148.36
Lorenz 96            N=32768 K=16384 Workers=4 Sec=4.56845 Mflops=705.102

The Zero 2W, OpenMP has Raspberry Pi ratio=8.72113
Making pie charts...done.

real	8m20.245s
user	15m27.197s
sys	0m3.752s

-----------------------------

time ./pichart-serial -t "Zero 2W, Serial"
pichart -- Raspberry Pi Performance Serial version 36

Prime Sieve          P=14630843 Workers=1 Sec=8.77047 Mops=106.531
Merge Sort           N=16777216 Workers=2 Sec=7.02049 Mops=57.354
Fourier Transform    N=4194304 Workers=2 Sec=8.58785 Mflops=53.724
Lorenz 96            N=32768 K=16384 Workers=1 Sec=17.1408 Mflops=187.927

The Zero 2W, Serial has Raspberry Pi ratio=2.48852
Making pie charts...done.

real	7m50.524s
user	7m48.854s
sys	0m1.370s

64-bit

Running stock/beta 64-bit Raspberry Pi OS with desktop. Curiously, these ran out of memory (at least, in oom-kill‘s opinion) with the desktop running, so I had to run from console. This also meant it was harder to capture the program run times.

The firmware required to run in this mode should be in the official distribution by now.

pie chart comparing 64 bit multi-thread numeric performance of Raspberry Pi Zero 2 W: slightly faster than a Raspberry Pi 2B
multi-thread, 64 bit: no, I can’t explain why Lorenz is better than a 3B+
pie chart comparing 64 bit single-thread numeric performance of Raspberry Pi Zero 2 W: slightly faster than a Raspberry Pi 2B
single thread, again with the bump in Lorenz performance
pichart -- Raspberry Pi Performance OPENMP version 36

Prime Sieve          P=14630843 Workers=4 Sec=1.78173 Mops=524.395
Merge Sort           N=16777216 Workers=8 Sec=1.83854 Mops=219.007
Fourier Transform    N=4194304 Workers=4 Sec=2.83797 Mflops=162.572
Lorenz 96            N=32768 K=16384 Workers=4 Sec=2.66808 Mflops=1207.32

The Zero2W-64bit has Raspberry Pi ratio=10.8802
Making pie charts...done.

-------------------------

pichart -- Raspberry Pi Performance Serial version 36

Prime Sieve          P=14630843 Workers=1 Sec=7.06226 Mops=132.299
Merge Sort           N=16777216 Workers=2 Sec=6.75762 Mops=59.5851
Fourier Transform    N=4194304 Workers=2 Sec=7.73993 Mflops=59.6095
Lorenz 96            N=32768 K=16384 Workers=1 Sec=9.00538 Mflops=357.7

The Zero2W-64bit has Raspberry Pi ratio=3.19724
Making pie charts...done.

The main reason for the Raspberry Pi Zero 2 W appearing slower than the 3B and 3B+ is likely that it uses LPDDR2 memory instead of LPDDR3. 64-bit mode provides is a useful performance increase, offset by increased memory use. I found desktop apps to be almost unusably swappy in 64-bit mode, but there might be some tweaking I can do to avoid this.

Unlike the single core Raspberry Pi Zero, the Raspberry Pi Zero 2 W can be made to go into thermal throttling if you’re really, really determined. Like “3 or more cores running flat-out“-determined. In my testing, two cores at 100% (as you might get in emulation) won’t put it into thermal throttling, even in the snug official case closed up tight. More on this later.

(And a great big raspberry blown at Make, who leaked the Raspberry Pi Zero 2 W release a couple of days ago. Not classy.)

Another Raspberry Pi Pico language: MMBasic

It’s very much a work in progress, but Geoff Graham and Peter Mather’s MMBasic runs nicely on the Raspberry Pi Pico. Development is mostly coordinated on TheBackShed.com forum.

It supports an impressive range of displays and peripherals. The project gives me a very distinct “This is how we do things” vibe, and it’s quite unlike any other Raspberry Pi Pico project.

To show you what MMBasic code looks like, here’s a little demo that uses one of those “Open Smart” LED traffic lights on physical pins 14-16 which cycles through the phases every few seconds:

' traffic light on gp10-12 (green, yellow, red), pins 14-16

' set up ports for output
FOR i=14 TO 16
  SETPIN i, DOUT
  PIN(i)=0
NEXT i

red=16
amber=15
green=14

DO
  ' green on for 5 seconds
  PIN(red)=0
  PIN(green)=1
  PAUSE 5000
  ' amber on for 3 seconds
  PIN(green)=0
  PIN(amber)=1
  PAUSE 3000
  ' red on for 5 seconds
  PIN(amber)=0
  PIN(red)=1
  PAUSE 5000
LOOP

Raspberry Pi Pico with TTP223 Touch Sensor

This is almost too trivial to write up, as the TTP223 does exactly what you’d expect it to do with no other components.

breadboard with Raspberry Pi Pico and small blue capacitive touch sensor
TTP223 sensor board connected to GP22 / physical pin 29

Breakout boards for the TTP223 capacitive touch sensor come in a whole variety of sizes. The ones I got from Simcoe DIY are much smaller, have a different connection order, and don’t have an indicator LED. What they all give you, though, is a single touch/proximity switch for about $1.50

Trivial code to light the Raspberry Pi Pico’s LED when a touch event is detected looks like this:

import machine
touch = machine.Pin(22, machine.Pin.IN)
led = machine.Pin(25, machine.Pin.OUT)

while True:
    led.value(touch.value())

For the default configuration, the sensor’s output goes high while a touch is detected, then goes low. This might not be the ideal configuration for you, so these sensor boards have a couple of solder links you can modify:

  1. Active Low — sometimes you want a switch to indicate a touch with a low / 0 V signal. On the boards I have, the A link controls that: put a blob of solder across it to reverse the switch’s sense.
  2. Toggle — if you want the output to stay latched at one level until you touch it again, a blob of solder across the T link will do that. Unlike a mechanical switch, this won’t stay latched after a power cycle, though.

And that’s all it does. Sometimes it’s nice to have a sensor that does exactly one thing perfectly well.

Happy Birthday Alvin Lucier

Happy Birthday Alvin Lucier - spectrogram of ten generations of re-recordings
Happy Birthday Alvin Lucier – spectrogram of ten generations of re-recordings

Just over 50 years ago, Alvin Lucier turned on his tape recorder and started to recite. This wasn’t an entirely unusual thing to do, but what he did next was a little different: he played that tape back, while recording it on another device. He kept doing this until all there was left was the ringing resonant frequency of the room, his voice smeared out of any recognizable sound. He called this piece I am sitting in a room, and it’s still a stunning work of sound art.

Alvin Lucier just turned 90 years old, so in recognition, I made this:

Many Happy Returns: for Alvin Lucier at 90

I don’t have a quiet room with two tape decks, but I do have a large plastic tote in which I can fit a whole bunch of battery-powered recording gubbins:

computer-based recording and playback equipment in plastic tote
my studio in a box. From L to R: Raspberry Pi 3A+, backup audio recorder, microphone stand, battery pack, microphone, USB audio interface, kalimba (for added resonance) and bluetooth speaker

After setting everything up and running, I put the box on my bed and covered it with several layers of blankets to keep our noisy neighbourhood sounds out. The initial audio was made in PicoTTS, and then playback and recording were controlled over wifi and VNC. I (or more accurately, the bash script I wrote) made 90 generations of recordings. I’ve only included the first 10 due to time constraints.

What I did

I guess I’ve been lucky with whatever audio system Raspberry Pi OS is using, because it recognized and used both my ancient Griffin iMic USB microphone adapter and my Sony Bluetooth speaker as default input/output devices.

One annoyance was having to build PicoTTS from source. Raspberry Pi OS doesn’t provide packages for it, but does have the source package. Building it goes something like this: Compile Pico TTS on Raspbian. You might prefer trying flite or espeak-ng, both of which have binary packages available.

I used this script, which may be rather too specific to my particular goal:

#!/bin/bash

parent=/home/pi/Desktop/sitting_in_a_box
gen0="$parent/box0.wav"
dest=${1:-$(date +%y%m%d%H%M)}
outdir="$parent/$dest"
mkdir -p "$outdir" && echo Created "$outdir"
n=0
outfile=$(printf "%s/%s_%03d.wav" "$outdir" "$dest" "$n")
tmpfile=$(printf "%s/%s_TMP.wav" "$outdir" "$dest")

# copy source file
sox -q --norm=-3 "$gen0" "$outfile"
while
    [ ! -f "$parent/STOP" ]
do
    infile="$outfile"
    n=$((n + 1))
    outfile=$(printf "%s/%s_%03d.wav" "$outdir" "$dest" "$n")
    echo Recording "$outfile" . . .
    arecord -f cd -q "$tmpfile" &
    rec_pid=$!
    echo Playing "$infile" . . .
    aplay -q "$infile"
    sleep 0.5
    kill -SIGINT "$rec_pid"
    echo Normalizing "$tmpfile" to "$outfile" . . .
    sox --norm=-3 "$tmpfile" -c 2 "$outfile" && rm "$tmpfile"
    echo ""
done
echo '***' Process stopped after "$n" iterations.

Some notes on the code:

  1. the script creates a folder for the output files, either as specified on the command line, or if not, from the current date/time
  2. I didn’t really know how many iterations I’d want, so I monitored occasional files by pulling them down using scp and listening. When I was satisfied, I’d create a file called STOP in the project folder that would make the loop exit
  3. $gen0 is the name of the source recording
  4. sox -q –norm=-3 infile outfile is a way of normalizing the audio so that it won’t clip
  5. We start the recording in the background (arecord … &) and immediately grab its process ID using $!. This allows us to stop the recording using kill after the audio file has played. arecord doesn’t update the file header when a process is stopped like this, so sox will complain quietly every time
  6. The sleep 0.5 after aplay is to prevent the recording cutting off. Both aplay and sox/play seem to exit as soon as the last block of audio data has been sent to the audio device, and not when the sound has stopped playing. This means you have to edit out increasingly longer gaps from your recordings, but at least you get everything.

What I’d do differently next time

  • Probably not used a Bluetooth speaker. Sure, they’re self-powered and you can’t complain about the number of wires, but they’re noisy and low quality
  • Done more work on the microphone interface. The pair of binaural mics I used to use with the Griffin interface (it’s stereo, unlike most USB interfaces) had a dead channel, so I had to fish around for other microphones. Somewhere I have a nice microphone from a Sony Pro Walkman, and I should have used that
  • Maybe considered a band-pass filter to cut the very high frequency ringing. Yes, I know the whole point of I am sitting in a room is to capture the room dynamics, but when you’re recording in a tiny space with very hard walls, the dynamics take over almost too quickly to be interesting
  • Spent more time on playback and record levels beyond the “hey, it works!” settings I used here
  • Used a higher bitrate recording. This might have resulted in more wolf-tones and ringing, though.

Presentation: Getting Started with MicroPython on the Raspberry Pi Pico

I just gave this talk to the Toronto Raspberry Pi Meetup group: Getting Started with MicroPython on the Raspberry Pi Pico. Slides are here:

or, if you must, pptx:

If I were to do this again, I’d drop the messy thermistor code as an example and use a DS18x20, like here: Raspberry Pi Pico: DS18x20 in MicroPython

also, simple potentiometer demo I wrote during the talk: potentiometer.py

goodbye X10, hello trådfri …

scruss/ihsctrl: a package of bash scripts to control selected IKEA Home smart (aka “TRÅDFRI”) devices via their network gateway

The old X10 devices were getting really unreliable: seldom firing at all, getting far too hot, bringing a whole lot of not working to my life. So while it was kind of cool to have my lights controlled by an original 256 MB Raspberry Pi Model B from 2012, it was maybe working one schedule out of ten.

So it had to go: replaced by a Raspberry Pi Zero W and a whole lot of IKEA TRÃ…DFRI kit. I was deeply unimpressed with the IKEA Home smart app, though: you couldn’t use even basic schedules with more than one light cycle per day. So while I know there are lots of clever home automation systems, I wanted to replace my old cron scripts and set about writing some simple command tools. The result is ihsctrl: very limited, but good enough for me. It’s been working exactly as expected for the last week, so I’ll finally get to wade through 8 years of cobwebs and dismantle the old X10 setup. I already miss the 06:30 clonk of the X10 controller turning the front light on — that was my alarm clock (or alarm clonk) every morning.

(local copy: ihsctrl.zip)

Possibly Painless Network Printing from your Raspberry Pi

Printing from computers goes through waves of being difficult to being easy, then back to difficult again. This is likely due to the cycles of technology, complexity and user demand flow in and out of sync. I think we’re at peak annoyance right now.

It’s even harder with Raspberry Pis, as when printer drivers support Linux, 90% of them are for x86 or x86_64 computers only (Canon: ಠ_ಠ). ARM doesn’t get a look in. But one technology does actually seem to help: network printers that support IPP — Internet Printing Protocol.

We had an old Brother laser printer that just got slower and crankier and less useful as a printer, so yesterday I got a new Brother DCP-L2550DW to replace it. It says it supports Linux in the spec, but I knew not to be too optimistic with my Raspberry Pis. And indeed, it was seen on the network but no driver was found. I had a sad.

What turned my frown upside down was finding out about Raspbian’s cups-ipp-utils package. For desktop use, install it this way:

sudo apt install cups cups-ipp-utils system-config-printer

(leave off system-config-printer if you’re running from the terminal.)

Update: while you’re here, you might also want to install the print-to-PDF driver too. This allows you to print without wasting paper. Install it (and the IPP driver) with:

sudo apt install cups cups-ipp-utils system-config-printer printer-driver-cups-pdf

In many cases, this might be all you need to do: the network printers should be automatically found and added as devices.

Adding the new printer

On the desktop, open up Preferences → Print Settings and add a new printer. Yes, it prompts for your user password which you may have forgotten. I’ll wait while you try to remember it …

Now under Network Printers, you should see a device you recognize. Pick the one that says IPP network printer somewhere:

IPP network printer

Here’s where the magic happens: you actually want to pick the generic driver for once:

Select Generic (recommended) manufacturer

And again, the IPP utilities package will have picked the right driver for you:

Just go with what the driver suggests

Changing the name and location is optional:

Your new printer’s almost ready to go!

Hit Apply, and you should be printing!

(Hey, printer manufacturers have been known to be evil and make good, working stuff suddenly not work. IPP is supposed to make everything sparkly again, but I can’t guarantee that something wicked won’t come this way.)

Update: After a few months of using the Brother DCP-L2550DW, I don’t recommend you buy it. It’s a perfectly capable printer, but it takes ‘chipped’ toner cartridges that:

  1. stop dead when you hit their page count limit, wasting toner and preventing you from finishing the print job;
  2. can’t easily be refilled by local technicians, so are wasteful of resources.

To get around (1), select Continue instead of Stop in the Toner Out configuration menu.

Update, January 2020: with sales and all needing a printer for work, the DCP-L2550DW will go with me to the office. I now have a MFC-L2750DW at home that scans to network, amongst other things. IPP proved it was magic yet again by the new printer being found and just worked with all my machines as soon as I added it to the network.

eben’s bbc basic programmes

I wrote this as a comment to Learn to write games for the BBC Micro with Eben – Raspberry Pi, but it didn’t seem to save:

BeebEm? Lawks, that’s a bit old (2006). All the cool (*cough*) kids are running b-em – https://github.com/stardot/b-em – these days. It’s lovingly maintain by Stardot forum members. It’s a little crashy on some Linux platforms, but seems stable on the Raspberry Pi and Raspbian. You may need to install the liballegro5-dev and zlib1g-dev packages to get it to compile.

If you want a native version of BBC BASIC, Richard Russell’s version is pretty neat: http://www.bbcbasic.co.uk/bbcsdl/ . You’ll most likely need to change line 280 to use some variant of the WAIT command to make it playable.

Another native interpreter is Brandy. There’s an ancient one in the repos, but I’m completely taken with the Matrix Brandy fork: https://github.com/stardot/MatrixBrandy . It may need a few packages installed to get it to build (libsdl1.2-dev might be a good first try), but it’s really fast. For cross-platform happiness, change line 280 to WAIT 10. If you stick to using a FOR loop, you might have to have it as high as 2,000,000 on a fast computer!

Lastly, if you want to run the game in a browser, JSBeeb to the rescue: https://bbc.godbolt.org/?autorun&loadBasic=https://gist.githubusercontent.com/scruss/f5a8eb83f28b85d6399142cac460c806/raw/74c4e39de7661bb2e3dd7f435840dd8db7172589/helicopter.bbc
It’s a bit slow in Chromium on a Raspberry Pi, but it does work!

Eugene’s fishing line header hack for Raspberry Pi Zero

0.38 mm / 5.4 kg test Trilene threaded through Raspberry Pi Zero header holes
0.38 mm / 5.4 kg test Trilene threaded through Raspberry Pi Zero header holes holds jumper wires snugly without soldering

Eugene ‘thirtytwoteeth’ Andruszczenko (of Game Boy Zero – Handheld Edition fame) posted a neat idea to help your Raspberry Pi Zero take jumper wires without soldering. He threaded fishing line through the 40 hole header, making an interference fit for header pins. I tried it with 0.38 mm Trilene, which worked rather well.

Building (but not necessarily running) Amiberry on Raspberry Pi 3

I might not have Amiberry — an optimized Amiga emulator for Raspberry Pi — running quite yet, but the build instructions at midwan/amiberry are a bit lacking. If you want to compile it under Raspbian Stretch, you’ll need the following packages:
sudo apt install libsdl2-dev libxml2-dev libxml2-utils libsdl2-ttf-dev libsdl2-image-dev
This will at least allow you to get it to build correctly with:
make -j2 PLATFORM=rpi3-sdl2-dispmanx
More later when/if I get it working.

Raspblocks: Blocks-based Python coding for Raspberry Pi

Update, 2019-01: raspblocks.com appears to be dead, with an “Account Suspended” error from the host

Raspblocks is a new Blocks-based web programming environment for Raspberry Pi. You don’t even need to write the code on a Raspberry Pi, but the Python 3 code it produces will need to be transferred to a Raspberry Pi to run.

For maximum authenticity (and slowness), I fired up  http://www.raspblocks.com/ on a Raspberry Pi Zero over VNC. It took a minute or more to load up the site in Chromium, but creating a simple program was all easy dragging and dropping:

The code it produced was pretty much exactly what you’d write by hand:

import RPi.GPIO as GPIO
import time
GPIO.setmode(GPIO.BCM)
GPIO.setup(26, GPIO.OUT)

while True:
    GPIO.output(26,True)
    time.sleep(1)
    GPIO.output(26,False)
    time.sleep(1)

And, as you might expect, the code make an LED connected to GPIO 26 turn on and off. Science!

Raspblocks isn’t as polished as its more established rival  EduBlocks, but Raspblocks doesn’t need any software installed. Edublocks installs its own Node.js-based web service, which would be painfully slow on a Raspberry Pi Zero. Raspblocks’ code needs to be run manually from a terminal, but I’d put up with that any day over having yet another Node server distribution installed under /opt.

MQTT Talk tonight

I’m talking at the Raspberry Pi Toronto Meetup tonight, and if all goes well, the Net-Connected Cowbell will make an appearance:

My slides: MQTT.odp

Links:

Teensy USB Keypad

in which I finally learn about Fritzing’s wire alignment facility …

I’ve had a couple of Teensy boards for a while, but a misunderstanding that they needed a load of of extra software installed (they need one thing, and it’s easy) had kept me away. They’ve got really impressive specs, and they’re especially easy to turn into USB devices like keyboards.

Super-heavy CEECO keypad

Here’s a little demo that turns a phone keypad — in my case, a ridiculously solid CEECO solid metal keypad designed for institutional use — into a simple USB keyboard. Plug it into any machine (including a Raspberry Pi) and it will be identified as a keyboard. No drivers are required.

The code is based on the standard Arduino Keypad library basic demo. That code was meant for a different keypad, so I eventually found a configuration that worked in the Sparkfun 12 button keypad datasheet. Rather than printing characters to the serial port, I used calls to Teensy’s USB Keyboard library instead.

The pinout is (from left to right, key side up):

  1. do not connect
  2. Column 2
  3. Row 1
  4. Column 1
  5. Row 4
  6. Column 3
  7. Row 3
  8. Row 2
  9. n/c

There’s no reason why this wouldn’t work with those very cheap 4×4 button matrix keypads for Arduino too with only minor modifications. Those keypads use 8 data lines, and they’re arranged (I think) as rows 1-4 on pins 1-4 and columns 1-4 are pins 5-8. columns 4-1 then rows 1-4 from the top of the pin connector down:

The Teensy USB keyboard isn’t limited to sending single characters: a single button press could trigger sending a whole string. I haven’t yet thought out any major uses for this (except “Crypto!”, which is my usual idea when I have no idea what I’m doing), but you might have better plans.

Update, 2020-04: These keypads don’t have diodes on every key to prevent key ghosting if you press multiple keys. Despite what the Arduino Playground Keypad section might tell you, you can’t do useful multi-key/rollover detection with them.

Creating a systemd user service on your Raspberry Pi

Flushed with success from yesterday’s post where I made my first systemd service, I got carried away and wanted to show you how to create a service that runs as a regular user.

A fairly common question on the Raspberry Pi Forums is “How do I run a script every time I reboot?”. The traditional answer (and one I’ve given more than once) is to add a @reboot clause to your crontab. This will indeed run a command when the computer reboots, but it will run pretty early on in the boot sequence when there’s no guarantee of network or time services. So the usual remedy is a bit of a kludge:

@reboot sleep 60 && …

This waits a full minute after rebooting, then executes the command. Network and time services are really likely to be available, but it’s not very elegant. Cron also has some weird gotchas with PATH settings, so while it’s ubiquitous and has worked for decades, it’s not easy to get working. Systemd, however, has a much better way of doing it, and better yet, you can do it all without ever hitting sudo.

I’ll take as a basis for this post the forum query “python and crontab”. The asker wanted to log the time when their Raspberry Pi had rebooted, but they’ve hit the usual problem that the clock didn’t have the right time when their script was triggered, so the log was useless.

(I’m not going to do exactly what the forum poster did, but this is more a demo of a systemd user service than recreating their results.)

First off, here’s the script to log the time to a file (saved as ~/bin/boot_time.py):

#!/usr/bin/python3
from time import strftime
with open("/home/pi/logs/boot_time.txt", "a") as log:
 log.write(strftime("%d-%m-%Y,%H:%M:%S\n"))

I’d have done this as a shell script, but the OP used Python, so why fight it?

FUN FACT: Under most Linux flavours, if you create a bin folder in your home directory, it’s automatically added to your path. So I could just type boot_time.py and the shell would find it.
(You might have to log out and log back in again for the shell to review your path.)

In order to get that to run, I need to do a little housekeeping: make the script executable, and make sure the logs folder exits:

chmod +x ~/bin/boot_time.py
mkdir -p ~/logs

Now we need to do the bits that pertain to systemd. First off, you must make a folder for user services:

mkdir -p ~/.config/systemd/user

NOTE: mkdir -p … is useful here as it makes the directory and any parent directories that don’t exist. It also doesn’t complain if any of them already exist. It’s kind of a “make sure this directory exists” command. Make friends with it.

And here’s the service file, which I saved as ~/.config/systemd/user/boot_time_log.service:

[Unit]
Description=boot time log
DefaultDependencies=no
After=local-fs.target time-sync.target

[Service]
Type=oneshot
ExecStart=/home/pi/bin/boot_time.py

[Install]
WantedBy=default.target

The service file does the following (even if I’m slightly mystified by some of the headings …):

  • Unit
    • Description — a plain text name for the service. This appears in logs when it starts, stops or fails.
    • DefaultDependencies — as this service runs once at boot-up, it doesn’t need the normal systemd functions of restarting and shutting down on reboot. Most service files omit this line.
    • After — here we tell systemd what service targets must be running before this service is started. As we need to write to a file and have the right time, the local-fs.target and time-sync.target seem sensible.
  • Service
    • Type — this is run once, so it’s a oneshot rather than the usual simple service.
    • ExecStart — this is the command to run when the service is required.
  • Install
    • WantedBy — tbh no idea what this does, but if you omit it the service won’t install. Found the answer in this SE, and it works. So I guess what it does is make the service not fail …

Finally, you enable the service with:

systemctl --user enable boot_time_log.service

Next time you reboot, the time will be appended to the log file ~/logs/boot_time.txt.

Unlike most (that is, Type=simple) services, it’s perfectly fine if this one spends most of its time inactive:

$ systemctl status --user boot_time_log.service
● boot_time_log.service - boot time log
 Loaded: loaded (/home/pi/.config/systemd/user/boot_time_log.service; enabled;
 Active: inactive (dead) since Sun 2017-10-22 22:17:56 EDT; 1h 5min ago
 Process: 722 ExecStart=/home/pi/bin/boot_time.py (code=exited, status=0/SUCCES
 Main PID: 722 (code=exited, status=0/SUCCESS)

It has executed successfully, so the process doesn’t have to stick around.

Combined Restart / Shutdown Button for Raspberry Pi

Hey! This is obsolete. There are better solutions out there now. You should use the system-supplied and supported gpio-shutdown option instead.

A very simple systemd service for Raspberry Pi that provides a software-controlled restart / shutdown button. Code: scruss/shutdown_button

Use

Default behaviour is:

  • your Raspberry Pi will reset if the button is held for more than two seconds but fewer than five seconds;
  • your Raspberry Pi will shut down if the button is held for more than five seconds.

By default, the software assumes the switch is connected to pin BCM 27. Both the pin and the timing can be changed in the Python source file.

Requirements

Hardware

  • A Raspberry Pi (tested on a model 2B, 3B and Zero, and on a model B after minor software modification)
  • A normally open, momentary contact button. I use surplus ATX power buttons (as used on desktop PCs), as they’re cheap and come with a handy set of wires and header connectors. Virtually any button will do the job, though. Just make sure it’s normally open (push to close).

Software

  • A Debian-based operating system that uses systemd (tested on Raspbian Jessie and Stretch)
  • the python3-gpiozero package to provide GPIO Zero (tested on version 1.4.0)

Installation

Hardware

40-pin GPIO connector (B+, 2B, 3B, Zero)

Connect the button between GPIO 27 and GND. If you use an ATX power button and a Raspberry Pi with a 40-pin GPIO header, connect it across the seventh column from the left:

            -
· · · · · ·|·|· · · · · · · · · · · · · 
· · · · · ·|·|· · · · · · · · · · · · · 
            -

This shorts GPIO 27 (physical pin 13) to ground (physical pin 14) when the button is pressed.

26-pin GPIO connector (models B and A only)

GPIO 27 is not exposed on the original Raspberry Pi header, so GPIO 17 is a reasonable option. If you use an ATX power button and a Raspberry Pi with a 26-pin GPIO header, connect it across the fifth and sixth columns of the second row:

 . . . . ._. . . . . . . .
 . . . .|. .|. . . . . . .
          -

You will also need to change line 7 of shutdown_button.py to read:

use_button=17

Software

Download the software first. I prefer to use

git clone https://github.com/scruss/shutdown_button.git

but you can download the zip file. If you do that, though, make sure to

unzip shutdown_button-master
cd shutdown_button-master

The software is installed with the following commands:

sudo apt install python3-gpiozero
sudo mkdir -p /usr/local/bin
chmod +x shutdown_button.py
sudo cp shutdown_button.py /usr/local/bin
sudo cp shutdown_button.service /etc/systemd/system
sudo systemctl enable shutdown_button.service
sudo systemctl start shutdown_button.service

Troubleshooting

Enabling the service should produce output very similar to:

Created symlink /etc/systemd/system/multi-user.target.wants/shutdown_button.service → /etc/systemd/system/shutdown_button.service.

You can check the status of the program at any time with the command:

systemctl status shutdown_button.service

This should produce output similar to:

● shutdown_button.service - GPIO shutdown button
   Loaded: loaded (/etc/systemd/system/shutdown_button.service; enabled; vendor 
   Active: active (running) since Sat 2017-10-21 11:20:56 EDT; 27s ago
 Main PID: 3157 (python3)
   CGroup: /system.slice/shutdown_button.service
           └─3157 /usr/bin/python3 /usr/local/bin/shutdown_button.py

Oct 21 11:20:56 naan systemd[1]: Started GPIO shutdown button.

If you’re seeing anything other than Active: active (running), it’s not working. Does the Python script have the right permissions? Is it in the right place? If you modified the script, did you check it for syntax errors?

The output from dmesg will show you any error messages generated by the service.

Modifications

If you use a HAT/pHAT/Bonnet/etc. with your Raspberry Pi, check pinout.xyz to see if it uses BCM 27. If you do need to change the pin, best to pick one that doesn’t have a useful system service like serial I/O or SPI. If you’re using an ATX button with a two pin connector, make sure you choose a pin physically adjacent to a ground pin.

If you modify the timing, please ensure that you keep the shutdown button press duration longer than the reboot one. Otherwise you’ll only be able to shut down.

Notes

You should not need to reboot to enable the service. One machine of mine — a Raspberry Pi Zero running Raspbian Stretch — did need a reboot before the button worked.

The reboot code is based on the Shutdown button example from the GPIO Zero documentation.

This is not the only combined shutdown/reset button project to use GPIO Zero. gilyes/pi-shutdown also does so, but pre-dates the implementation of the various hold time functions in GPIO Zero.

GPIO 27 was used, as it’s broken out onto a physical button on the Adafruit PiTFT+ display I own.

This is my first systemd service, and I’m still at the “amazed it works at all” stage. The service file may not contain the ideal configuration.

Connector Pinouts

From GPIO Zero’s pinout command

40 pin

   3V3  (1) (2)  5V    
 GPIO2  (3) (4)  5V    
 GPIO3  (5) (6)  GND   
 GPIO4  (7) (8)  GPIO14
   GND  (9) (10) GPIO15
GPIO17 (11) (12) GPIO18
GPIO27 (13) (14) GND   
GPIO22 (15) (16) GPIO23
   3V3 (17) (18) GPIO24
GPIO10 (19) (20) GND   
 GPIO9 (21) (22) GPIO25
GPIO11 (23) (24) GPIO8 
   GND (25) (26) GPIO7 
 GPIO0 (27) (28) GPIO1 
 GPIO5 (29) (30) GND   
 GPIO6 (31) (32) GPIO12
GPIO13 (33) (34) GND   
GPIO19 (35) (36) GPIO16
GPIO26 (37) (38) GPIO20
   GND (39) (40) GPIO21

26 pin

   3V3  (1) (2)  5V    
 GPIO0  (3) (4)  5V    
 GPIO1  (5) (6)  GND   
 GPIO4  (7) (8)  GPIO14
   GND  (9) (10) GPIO15
GPIO17 (11) (12) GPIO18
GPIO21 (13) (14) GND   
GPIO22 (15) (16) GPIO23
   3V3 (17) (18) GPIO24
GPIO10 (19) (20) GND   
 GPIO9 (21) (22) GPIO25
GPIO11 (23) (24) GPIO8 
   GND (25) (26) GPIO7