Super-cheap replacement bed for a K40 laser cutter

I recently bought a (comparatively) cheap K40 laser engravercutter and am slowly getting to know it, whilst also getting ready to heavily mod it. I have plans to improve (slightly) the cutting area, to add air assist, to replace the controller board and upgrade the bed (pretty much all the usual stuff) and I plan to blog about it as I go.

Laser beams... Laser... Laser... Laser... Yay!

However here at the very beginning of the journey my machine is freshly calibrated and almost, but not quite stock. The bed was causing a few problems, not least that, when cutting large sheet material, the lip of the clamp brought the material too close to the laser. That was easily remedied by unscrewing the clamp and dropping it into the bottom of the machine (its metal, it will be quite safe down there). However the means the cut pieces drop to the bottom of the machine where they are at risk of damage from the laser working overhead… and small pieces can be hard to find because some idiot left a big metal clamp down there.

The solution turned out be a very cheap anti-splater guard for a frying pan. It cost me £1 (since Brexit that’s dropped to about $1.20) from a local discount store and for now I’ve just gaffer taped it to the underside of the existing bed. Since it’s working so well I’m thinking of driving a couple of self tapping screws into a couple of cable clips to hold the frame in place without any sticky residue.

An alternative bed for my K40! It's an anti-splater guard for a frying pan and came from my local pound shop (or, for an international audience my local $1.20 shop). For some basic testing I just taped it to the underside of the existing bed!

This is working great for small items, catching any components that are cut from the middle of the bed and with absolutely no signs of backscatter. Amoung other things I’ve used this simple bed to build a case for my Carbon board (a 96Boards IoT edition micro-controller board) and the results are, I think, pretty awesome.

Laser cut acrylic case for 96Boards IoT edition

So a very, very simple mod but more than enough to allow the whole family to have a bit of fun with our new toy. Whilst its not quite as much fun just to watch I would still invite you to watch the video below showing the cutter creating the case for the Carbon. I find it oddly hypnotic!


Getting started with GStreamer 1.0 and Python 3.x

Way back in the mists of time (or a little over nine years ago if you prefer). Jono Bacon wrote a very detailed blog post describing how to use GStreamer with Python.

Getting started with GStreamer with Python

Mr. Bacon went into a lot of detail, so much so that now, almost ten years later it is still widely credited in other blog posts and remains highly ranked by search engines.

However both Python and GStreamer have moved on a bit over the last decade. The bindings too have moved on a lot as they now use the almost unspeakably awesome PyGObject to automatically generate most of the bindings by introspection.

In short, Jono’s code doesn’t work any more. However it doesn’t take much work to massage the first example until it does.

#!/usr/bin/env python3

import gi
gi.require_version('Gst', '1.0')
gi.require_version('GstBase', '1.0')
gi.require_version('Gtk', '3.0')
from gi.repository import GObject, Gst, GstBase, Gtk, GObject

class Main:
 def __init__(self):

 self.pipeline = Gst.Pipeline("mypipeline")

 self.audiotestsrc = Gst.ElementFactory.make("audiotestsrc", "audio")

 self.sink = Gst.ElementFactory.make("autoaudiosink", "sink")



Roughly speaking “all” we have had to do to update this example:

  1. Update the imports to gather everything we need from the gi module.
  2. Add: Gst.init(None) (this should probably be Gst.init(sys.argv) but that’s not how the original code behaves so it’s not in this port either)
  3. Replace the lowercase g with an uppercase G in both Gst and Gtk.
  4. Tweak the Gst.ElementFactory and Gst.State calls; these were in a flatter namespace in the older PyGst bindings.
  5. Replace alsasink with autoaudiosink. Strictly speaking this is not required; alsasink will still work just fine. However autoaudiosink can adopt pulseaudio when available. Something else that has changed since this code was originally written.

… and that’s it. Not much to it really. Hopefully its enough to set you on your way if you want to grab ideas from old tutorials and blog posts into your own shiny new GStreamer application.

Happy hacking!


How to make a Dragonboard 410c run “headless”

The Dragonboard 410c is a great platform but currently there is a problem with the wireless driver that makes it very hard to run it headless and connect to services running on the board via wifi.

At present the board does not respond correctly to broadcast packets. This results in a number of issues but by far the most significant is that the board cannot reply to ARP requests and this prevents other devices from opening connections to it. From the client machines point of view it knows the board is there, and it can look it up using DNS, but it can’t take the final steps needed to communicate with the board.

In the example below we have a client machine, birch.lan, unable to access dragonboard.lan, because it cannot find the right MAC address.

birch# arp -e
Address         HWtype HWaddress
router.lan      ether  40:ba:fa:xx:xx:xx
dragonboard.lan        (incomplete)
wychelm.lan     ether  fc:aa:14:xx:xx:xx

If only we could get the MAC address into birch’s ARP cache then there would be no problem doing basic network activity like connecting an SSH server. Thankfully there is a fairly easy way to automate this…

Get the Dragonboard to do a nmap ping-sweep of the subnet.

To be clear this is a hack of such huge proportions that it deserves more than just those four letters! It is a bodge, a sticking plaster, a nasty solution stuck together with sticky tape and glue, it does not make me feel warm and snuggly inside… however… it does work.

Not only does it work but it can also be trivially hooked up to systemd so that the device can periodically shout out its presence.

Firstly we need to create a simple service to launch the ping sweep (actually it will be much more like an arping sweep):

# /etc/systemd/system/share-mac.service
# Running an nmap ARP ping sweep will encourage other
# devices to cache this boards MAC address. This
# works around a problem where the Dragonboard
# 410c does not correctly respond to ARP
# requests.
# Note that although nmap's port scanning is
# disabled it remains possible that the host
# discovery protocol (which is not *actually*
# as simple as a ping sweep) may still trigger
# an IDS if run on a corporate network.
# Take care!

Description=Send our MAC address to other devices

# Change the IP address range as needed...
ExecStart=/usr/bin/nmap -PR -sn -n -e wlan0

The above service runs just once and it would be enough to get the board noticed after it boots but eventually the other devices would evict the ‘410c from their ARP caches and it would fall off the network again. To solve this we can use a systemd timer to ensure we always keep poking the other devices:

# /etc/systemd/system/share-mac.timer

Description=Repeatedly send out our MAC address

Finally we need to run a few commands on the ‘410c to install nmap and ensure systemd runs the above files:

apt-get update
apt-get install nmap
systemctl enable share-mac.timer
systemctl start share-mac.timer

With these changes in place the ‘410c should announce its existence to all hosts on the network shortly (~30 seconds) after booting and it will repeat the sweep every 5 minutes to ensure the ARP caches stay nice and hot going forward.

The results of the above scripts showed up straight away in birch.lan‘s ARP cache:

birch# arp -e
Address         HWtype HWaddress
router.lan      ether  40:b0:fa:xx:xx:xx
dragonboard.lan ether  02:00:7d:xx:xx:xx
wychelm.lan     ether  fc:aa:14:xx:xx:xx

Share and enjoy!

Update #1 (2016-01-15):  Updated the nmap command with -PR (ensure pure ARP ping sweep), -n (no reverse DNS lookup) and -e wlan0 (only deploy workaround on a specific network interface). Reduced the interval between sweeps from 5 mins to 3 mins to better handle congested networks (10 minutes ARP cache timeouts are common). Thanks to snowbird and ldts-jro for their feedback with this.


Laser cut acrylic cases for 96Boards Consumer Edition

TL;DR: There are some tried and tested CAD files and the DXF files can zipped and sent directly to the Seeed Studio laser cutting service.

Simple case for 96Boards Consumer EditionI have amassed a modest collection of 96Boards. They come as plain circuit boards with nothing to keep them safe from damage during handling. Its not just static discharge we have to worry about! Many of the boards have fairly large components on the underside and these can be knocked off by careless handling (I admit that I’m tempted to say “Hi” to a colleague at this point, but I won’t). Since, I’m at least as careless about handling as the next software engineer so I decided a case was needed.

I’m not aware of anyone selling cases for the 96Boards Consumer Edition so I decided to get my own laser cut. As it happens between ordering the boards and writing this post I have started to come across a couple of other folks at Linaro who are experimenting with cases but nevertheless I think I’m still the first to blog about it!

There is a hackspace in Bristol, UK where I live which could be a great place to get involved in laser cutting but it’s right on the other side of the city and I’ve not really found the time to get very involved there. Instead I decided to try out the Seeed Studio online laser cutting service: 100mm x 100mm, cut to your own design for $6 for five (plus postage).

Having something of a plan the only remaining problem is that I know absolutely nothing about CAD/CAM. The only information on the Seeed Studio website about file formats is that I must send in .zip or .rar files and the only blog posts I could dig up wanted me to use the Google Sketchup which is non-free and partially discontinued.

In the end I just asked myself, “How hard can it be?” and fired up LibreCAD. After working through a couple of tutorials I learned how to round off corners and how to add dimension information. Armed with this, and the 96Boards CE Specification which has very clear diagrams of the physical layout of the board, I draw a basic top/bottom plate. I wasn’t happy with the 35mm of “wasted” material due to the minimum panel size of the manufacturer so I added a half-top component as well. The half-top should work very nicely with the 96Boards UART board.

Combo case for 96Boards Consumer Edition

Influenced by this blog post I decided to export from LibreCAD as an SVG. This turned out not to be such a great idea. The resulting SVG uses curves that are quantized to pixelish boundaries. The friendly folk at Seeed Studio declined to use it and askeld me for DXF files instead. Since DXF is the native file format for LibreCAD this was not much of a hardship.

And that’s it… I got a bunch of cases made in a couple of colours. The glowing neon green in the photo above is sooooo my favourite. I’ve hurled my design files at github and, because I’ve had so much fun with this, I’ve given the project a nice generic name. Maybe there are more cases to come. If that happens, you’ll read about it here first!


A USB relay controller from cheap off-the-shelf parts

This is an old project that I’ve been meaning to blog about for some time and, over a year later, am finally finding the time to write up. The project is a USB controlled (and powered) bank of relays assembled from cheap boards that can be purchased from ebay. The total cost a controller board and a bank of eight relays is about £6.50 (or $10 USD if you prefer to count like that).

STM32F103C8T6 controller board

The controller board is an STM32F103C8T6 breakout board which provides the USB hardware and an ARM Cortex M3 CPU combined with enough FLASH and on-board RAM to make writing software fairly easy. These terrific little boards can be found on eBay for a whisker over £3 and are just perfect for hacking together all kinds of USB toys and tools (some of which may be the subject to further blog posts).

8 channel relay board
8 channel relay board

The only other components needed is the relay board and a bunch of jumper wires. Relay boards can be bought on eBay in single, dual, quad or octo configurations depending the complexity of your projects.

I use this project to automate things on my rather modest pool of development boards but definitely need all eight relays (and then some). My relays control power delivery and, for some boards, they are also used to automate changes to jumper configuration. The HiSilicon HiKey board (from is especially needy in this department. To automatically test its debrick/recovery process requires three relays. One for power control and a further two to manipulate the jumper configuration.

Both boards connected with jumper wires
Both boards connected with jumper wires

The completed system is fully USB powered with the relay board taking a 5V feed from the controller. Eight relays can be pretty hungry when they are all energised at once but we do just about manage to sneak in below the 500mA USB current limit.

So… the hardware in this build is very simple and can be assembled even by someone with no electronics knowledge. What about the software?

There is a complete firmware for the device which can be FLASHed to the controller board without much fuss. The firmware contains a simple command interpreter which is present to the host as a CDC/ADM class compliant device. This allows the device to operate without drivers on more or less any operating system.

> help
Available commands:
> relay1
Usage: relay1 on|off|toggle|pulse
> relay1 on
> relay1 off

Like any command interpreter the firmware can be automatically driven using an expect-like system. However on GNU/Linux (and I suspect any other Unix-like OS) it is sufficient just to hurl commands at the device node using shell scripts:

echo relay1 on > /dev/ttyACM0

The firmware has a couple of extra bits of polish to make it more practical. In particular the unique serial number embedded into all STM32 devices during manufacturing is extracted and persented as the USB serial number. This allows udev to be configured to recognise specific devices and give them stable device names regardless of any rearrangements of the USB bus topology. This allows a single host PC to (reliably) support a very large number of relays. Also included in the firmware package is a tiny shell scripted called targetctl which allows individual relays to be named, even across multiple usb-relay devices.

The firmware consists of a bootloader and the main image. The bootloader can be downloaded either using the UART bootloader included in the ROM of almost all STM32 devices. However I prefer to hook up an ST-Link (these are also easily found on eBay) to the controller boards JTAG pins to FLASH to bootloader. Once the bootloader is in place its easy to install the main image using a DFU programmer such as dfu-util. After the main image has been installed the device reboot and enumerate as a CDC/ACM device and is ready to use. With the main image installed the board will launch into it automatically. However pressing the reset button will force the device back into DFU mode ready for a firmware update.

For more information on how to install the firmware see .

Finally to finish up I would really like to thank all the folks who work on libopencm3. The USB code in usb-relay comes from libopencm3 and without it then usb-relay probably wouldn’t exist in its current form.


Debugging ARM kernels using fast interrupts []

I suspect that there are relatively few regular readers of this blog. However if you are one of them and are feed up with hastily written articles with inadequate proof reading then may I recommend you take a look at my recent article for describing some of my recent Linux kernel work:

Debugging ARM kernels using fast interrupts

Not only did I proof read it, proof read it and proof read it again but the terrific folks over at did the same resulting in an article I’m really proud of.

PS if you are not an subscriber then you’ll have to wait until next week to read it…


How loop optimization in GCC uses undefined behaviour to make inferences

There are many ways to try and understand how an optimizing C compiler might transform your code.

Lets start by thinking about the goal of an optimizing compiler. Its goal is to manipulate the code that it is presented with, making modifications to cause it to execute more quickly and without altering the observable behaviour of a correctly formed program.

It is very important when describing the effects of an optimizer to remember that its only obligation it to preserve the behaviour of a correctly formed program. If your program is not correctly formed (normally expressed by compiler writers as relying upon undefined behaviour) then the optimizer is allowed to make modifications. That’s it! These modifications need not  preserve observable behaviour. They don’t have to execute more quickly. They don’t have to try to guess the programmer’s intent. The compiler is allowed to make modifications of more or less any form.

Over the years optimizing compilers have come to make inferences based on undefined behaviour. One of the simplest ones occurs when a pointer is dereferenced. In this case the compiler knows that the pointer cannot be NULL (because it has already been dereferenced and dereferencing a NULL pointer results in undefined behaviour). As a result it can the treat any later checks for pointer validity as unreachable code and remove it.

Recently GCC gained a much more powerful mechanism to track undefined behaviour that occurs due to out of range loop indicies. Having read about this and looked at a few spurious compiler bug reports I settled down and wrote the following plausible but buggy code.

Note: If you like puzzles then don’t scroll down past the return 0; statement and closing brace. That way you can try and spot the bug yourself. As far as I know there is only one in there!

int is_whitespace(char c)
    const char lookup_table[] = { ' ', '\t', '\n' };

    for (int i=0; i<=sizeof(lookup_table); i++)
        if (c == lookup_table[i])
            return 1;

    return 0;

Spotting the error is hopefully the easy part.

If you need a clue then be reassured that the lookup table contains three elements (it is initialized from character literals rather than a string literal so it does not get nil-terminated).

If you just want to know what the bug is so you can keep reading this article then have a look at the loop exit condition. It uses <= rather than < meaning the loop exit condition is reached after four cycles round the loop. This results in reading after the end of the array leading to undefined behaviour.

Now for the hard bit. What do you expect to happen when you run this code?

One answer, and one that I might have given had I been asked this question instead of writing it is: “strictly speaking this is undefined so it needs fixing, however the padding put in by the linker means that on most systems lookup_table[3] will evaluate to ‘\0’ and so the function will work more of less as intended (assuming the caller never cares whether the ‘\0’ character is whitespace or not)”.

That answer might even have been adequate two years ago. However with modern compilers it is better to rely on the simpler answer regarding what can happen: “anything”.

Nevertheless, even knowing all of the above the transformation the compiler actually makes may still yet surprise you. Unconditionally the code comes out as:

int is_whitespace(char c)
    return 1;

If you don’t believe me look at the assembler (generated using gcc-4.8.2 with -O2 -std=c99 -S on x86-64).

        .file   "g.c"
        .p2align 4,,15
        .globl  is_whitespace
        .type   is_whitespace, @function
        movl    $1, %eax
        .size   is_whitespace, .-is_whitespace
        .ident  "GCC: (GNU) 4.8.2 20131212 (Red Hat 4.8.2-7)"
        .section        .note.GNU-stack,"",@progbits

What has happens is the compiler has realized that when i == 3 the code makes an undefined memory read. From this the compiler infers that i must always remain strictly less than three during execution of the function and that, for this reason, the end condition is unreachable. It can be optimized away and, because this change means the loop can never exit then we also know that the function can only return 1 so we can get rid of the loop itself as well.

As a further exercise imagine what happens if the loop contains a function call that is opaque to the optimizer (meaning that the compiler doesn’t know what side effects the function has and therefore cannot remove it). Now we still know that the end condition is unreachable but we need to call the function a data dependant number of times. Of course the compiler still believes the end condition is unreachable and can optimize it away. This results an infinite loop!

If you’re currently busy moaning about arrogant out-of-touch compiler writers who don’t understand the real world then please stop. Compiler writers tend to dog food (by compiling their compilers using their own compilers) and are just as in touch with the real world as every other working programmer. Perhaps instead you could thank them for transforming a rare, hard to tickle bug that could easily slip into production, into a deterministic one that should be caught by even the most simple of tests. That’s much easier to debug.

Of course the other thing you get out of the dedication of your compiler writer is faster code. In a system where there is heavy inlining of defensively written code (for example the C++ standard library) then, in principle, throwing away unreachable loop end conditions could pay significant dividends.


Fifteen minutes using a Boss Micro BR

The fifteen minute figure is a slight poetic license. I did record this track during my first fifteen minutes playing about with the recorder. However after that it took me nearly twenty minutes to figure out how to master it into a format I can share with the world!

Recording is an Epiphone Dot plugged directly into a Boss Micro BR using the P01 “SuperCln” preset. The preset has been changed from the factory setting only by turning off the chorus.

To be honest the chorus effect sounds pretty terrific but, with such a naked guitar part it makes it sound like I have something to hide.



Use “#!/usr/bin/env hbcxx” to make C++ source code executable

#! C++I normally write some kind of personal toy during the holiday season. For example last year I wrote a toy fibre scheduler to go with a microcontroller project I was working on. This year however I’ve cooked up something and can’t quite decide if its a great idea, a pointless idea or a stupid idea. One thing is clear however, to find out which of the three possibilities it is, this bit of code needed packaging up properly as a product and shared with the wider world. Basically hbcxx uses the Unix #!/path/to/interpreter technique to make C++ source code directly executable.I’ve been taking a new look at C++. There is a palpable sense of “buzz” in the C++ community as they realize that, with C++11, they are sitting on something pretty special. The advocacy from the presenters at Going Native this year was remarkably effective (although if you take my advice you won’t watch Scott Meyer’s brilliant Effective C++14 Sampler until you know what std::move is for).
Quoting Bjarne Stroustrup: Surprisingly, C++11 feels like a new language. Considering its source it is not at all surprising that this quote is absolutely on the money: modern C++, meaning C++11 or later, does feel like another language. This is not because the language has been changed massively but because the new features encourage a different, and slightly higher level way to think about writing C++. It’s faster and more fun, supports lambdas, has tools to simplify memory management and includes regular expressions out-of-the-box.I was actually pretty amazed to see regular expressions in the standard C++ libraries, so that coupled with humane memory management (albeit humanity where you have to explicitly opt-in) and the auto keyword really got me thinking differently about writing C++. auto even encouraged me to write a template (generic programming is so much easier when you don’t have to explicitly declare the type of every expression). All this and without losing type safety…So my great/pointless/stupid idea (delete whichever is inappropriate) is a tool to keep things fast and fun by putting off the moment you have to write a build system and install script. For simple programs, especially for quick and dirty personal toys and scripts, the day you have to write a proper build system may never come. You no longer want the distraction of making a separate directory and a Makefile and you’ll find that pkg-config to just work.Instead I just copy your C++ source code into $HOME/bin. Try it. It works.Features include:

  • Automatically uses ccache to reduce program startup times (for build avoidance).
  • Enables -std=c++11 by defualt.
  • Parses #include directives to automatically discover and compile other source code files.
  • Recognises the inclusion of boost header files and, where needed automatically links the relevant boost library.
  • pkg-config integration.
  • Direct access to underlying compiler flags (-O3, -fsanitize=address, -g).
  • Honours the CXX environemnt variable to ensure clean integration with tools such as clang-analyzer’s scan-build.

To learn more about hbcxx take a look at:

Then have fun.