It’s mental health awareness week – and I wanted to write something on that topic. This is kind of difficult for me, as it’s not a topic I often speak openly about – but I live with chronic anxiety & depression.
I was first diagnosed some years ago in 2012 – and making that first trip to the doctor’s was one of the hardest things that I’ve ever done. There’s much less stigma about mental health conditions today than there was even fifteen years ago – but saying out loud that you’re not well is still very hard to do (made harder since that first doctor I saw wasn’t especially supportive).
Like so many other people, over the last few weeks of lockdown, I’ve been trying to use the extra time that I’m not spending commuting to work to learn some new skills that I’ve always meant to get around to learning. In particular, I been teaching myself ARM Assembly Language programming.
I’ve always been more interested in the low-level side of computer programming – than I have been in applications. I’ve always (even as a child) wanted to know how the magic box that is the computer actually works. I’m not new to assembly programming: I’ve done all kind of odds and ends of assembly over the years: from (emulated) 6502 on the KIM-Uno, to the real thing on a BBC model B; as well as more recently taking a course looking at the (also emulated) Atari 2600, and following along with Ben Eater’s fabulous breadboard 6502 series. The observant amongst you will note a common-thread there – the iconic 6502 processor (yes; I was an ‘80s kid). In addition to this, I have also done some assembly programming for PIC microcontrollers, and (rather more years ago than I’d care to admit!) back when I was doing my A-Levels in college I learnt a little x86 too; but I’ve never done anything much with ARM CPUs. Given my professional interests in the Internet of Things & cybersecurity, I thought that learning ARM assembler would be fun (and potentially useful in the future too, perhaps).
Interacting with the Operating System
Unlike some of the older computer systems that I mentioned earlier, the vast majority of microprocessors (and even some microcontrollers) today run some sort of operating system. The point of an operating system is easily missed today because of their ubiquity; but they essentially exist provide services to user programs. Without an OS, every application would have to include it’s own code to drive all of the peripheral devices: vital functionality such as reading a keyboard, displaying things on a screen, and providing an abstraction of storage devices to enable users to work with the concept of files.
In 2020 there are basically two types of OS in regular use. There are the POSIX (Portable Operating System Interface) standard compliant OS (as implemented in Linux, MacOS, BSD: and to some extent in iOS and Android too); and Windows. Given that I am not a Windows user (apart from for Office stuff at work) – the choice here was easy. So for my learning environment, I pulled out a Raspberry Pi (running Raspbian Linux): with its ARM Cortex-A72 processor.
I’ve heard it said that in order to learn to program in C, you need to understand everything – before you can do anything; I’m not sure that’s really true for C, but I’d argue that it’s undeniably for assembly language. When learning to program in a new language, the canonical introductory program is is Hello World; but in many assembler books it’s often one of the very last things you’ll see. There are some good reasons for that: not least of which is that because there’s almost no abstraction from the underlying OS when it comes to printing a message on the screen. Since we don’t have a handy print() function: we have to set about directly request that the OS shows our message to the user.
I’ve not actually written anything here for quite some time (it turns out that doing a part-time PhD really eats into your electronics project time… Who’d’ve thought!); so I thought I’d take advantage of the current isolation and a few days off over the Bank Holiday, to catch-up with some blogging…
The venerable NE555 timer IC was introduced in 1972; and due to its versatility is without doubt one of the most common integrated circuits ever made.
I finally got around to building it, and since I have to say that it’s a really nice kit; and it would make a great electronics project for kids (aged about 12-18) too. It’s a really well laid-out board; and the use of through-hole components makes it easy to assemble. It took me about 45-minutes to solder it – but you could easily do it in more like 30-minutes, if you were less fussy about how it looked; and it might take you anything up to a couple of hours if you’d never soldered before… The instructions are very clear; and the components are supplied fixed on to clearly marked cards, to make it trivial to identify which goes where.
Last time we looked at how to use Boost.Python to wrap a very simple piece of C++ code. This time we’re going to take that one step further along, and do the same thing for a more complex C++ example – which includes a C++ Class.
For the purposes of this example – let us assume that we have a “legacy” C++ class (i.e. one that we’re not going to change): which looks something like this:
This (deliberately, slightly contrived) class has three methods (and a constructor). We can set the three 8-bit unsigned integers (uint8_t) directly using the set_data() method; we can print the data to the screen; or we can either import from or export to an unsigned char*.
In order to be able to use the importer & exporter methods with Python (via Boost.Python) we’ll need to further wrap these – as Boost.Python won’t let us use unsigned char* directly.
Whilst this method makes our code on the C++ side slightly more complicated; it significantly simplifies the Python code – and it let’s us use some more powerful features.
To begin let’s start with a simple example.
char const* greet()
return "hello, world";
std::string multi_bob(int n)
std::string name = "Bob";
std::string r = "";
for (int i=0;i<n;i++)
r += name;
using namespace boost::python;
Everything above the BOOST_PYTHON_MODULE line is perfectly ordinary C++ code. The clever bit comes in when we call the BOOST_PYTHON_MODULE macro (which is defined within the Boost.Python header)…
In this case we’re creating a Python module – with two methods: one based on our very simple greet() function (which we’re also going to call greet); and one based on the more complex multi_bob(int) function. Note that for this second function, to show the fact that the linkage between the C++ & Python code can be very flexible, we give it a different name on the Python side. Also note that we don’t need to tell the macro about the signature of the function as this is handled for us by Boost.Python.
Tristate multiplexing (or Charlieplexing) is a simple to use technique to expand the number of LEDs that you can light from a simple microcontroller. This post explores the concept, and looks at some interesting calculations we can do when thinking about them.
I’ve been meaning to get around to writing something of a tutorial on the basics of assembly programming using a PIC microcontroller for a while: and this post stared off as the first part of that… But then, in the best traditions of geekery, I got distracted by the interesting mathematics behind the scenes, and instead this post was born. But I’ve not given up on the idea and I will get back to that. Eventually. (But don’t hold your breath). Instead this post is written without any reference to any specific microcontroller architecture, and so you can use the ideas described here on a PIC, an Arduino, and it should even work on a Raspberry Pi (though I’ve not actually tried that yet).
To begin, let’s think about a simple situation where we have a microcontroller which we wish to use to control two LEDs. The simplest implementation is to use one of the microcontroller’s GPIO pins for each LED. This works well for a small number of LEDs; but very quickly gets expensive in terms of the number of pins it uses if you want more than a handful of LEDs; and depending on what else your microcontroller needs to do (and/or how many pins it has available to begin with) it soon becomes unsuitable.
The solution is to multiplex the LEDs – that is to say connect more than one LED to each pin, and use a combination of multiple pins to select the one we want.
I recently found myself needing to call a C++ class from within Python. I didn’t want to call a separate process (as I had previously when using Thrift – see Using Apache Thrift for Python & C++); but rather to call a C++ library directly.
Before I go on I should say that there are a lot of different ways to do this is Python – and I’ve picked one that worked for me. Other techniques are available – and opinion seems quite divided as to which (if any) technique is ‘best’.
To start with we have our C++ class, written in the usual way.
I’ve recently got myself an Amazon Echo Dot; Amazon’s speech-based, voice-controlled device using Amazon’s Alexa, digital assistant. They’re pretty nice devices; and they’re quite fun to play with (and not too expensive either) – though I’ve not had it long enough to say if it’s actually useful yet…
Obviously the first thing that I did with it was to try to write some code for it. (Actually that’s not quite true – the actual first thing that I did with it was to run through all of the many, funny and often very geeky, easter eggs that have been baked into the system. I think my personal favourite is “Alexa who is the mother of Dragons?” – closely followed by “Alexa: Tea. Earl Grey. Hot.”). But I digress…
Coding for Alexa is actually pretty easy; and appealingly for an old-school back-end programmer like me: there are no visual user-interfaces to worry about. It’s all done with simple JSON; in the form of a pretty simple web application. Perhaps more interestingly there’s no need to worry about the server for that application – since it’s ideally suited for using Amazon’s AWS Lambda Functions.