CircuitPython is an Adafruit fork for MicroPython. Both are run-time environments for microcontrollers. Thanks to a compatibility layer, CircuitPython now also runs on various single-board computers (SBCs) like the Raspberry Pi.

MCU Scripting Languages

Traditionally, microcontroller units (MCUs), because of their extremely limited resources, where every byte can count, run either Assembler or C/C++. programs. Over the years, however, manufacturers have been improving their products, and powerful SBCs are now available for very little money that have sufficient reserves for interpreted languages.

Moreover, many typical applications do not exhaust an MCU (e.g., in education or home projects). The obvious approach then is to use an easier to learn scripting language instead of C/C++. Luckily, some processor families have Python, Lua, or JavaScript support (Figure 1).

Figure 1: Various MCUs with support for scripting languages. From left to right: Trinket M0, ESP32, and Espruino Pico.

Even small SBCs like Pi Zero have enough RAM and storage available to use scripting languages without problem. Python in particular impresses with innumerable ready-to-use modules for every imaginable purpose.

Like many other distributions, Raspbian is currently in the final transition phase from Python 2 to Python 3. The developers will soon stop maintaining version 2 because parallel support of two Python variants takes up too much time, raising the question as to why another Python dialect seems necessary or useful.

On the Raspberry Pi and other SBCs, CircuitPython does not use its own interpreter but requires Python 3. CircuitPython is not only an interpreter (on MCUs), but also a hardware abstraction layer in the form of a collection of system libraries. Although the Raspberry Pi already has available various libraries that abstract the hardware, they were designed to be Pi-centric so that the corresponding programs run only on Raspberry Pi without modifications. CircuitPython, on the other hand, promises compatibility across hardware boundaries.

Programming Models

The programming model of any microcomputer, no matter how minimal, is fundamentally different from that of a microcontroller. The computer runs an operating system that, simply put, manages the hardware, programs, and users.

The operating system allocates the available CPU(s) in sequence to all active programs. In this way, several programs run virtually in parallel, even if only one processor is available. However, only on real-time operating systems can a program rely on getting computing time reliably within a defined period. On conventional operating systems it simply has to wait its turn.

An MCU, on the other hand, has no operating system; the single-application program also controls all the resources, which makes it easy to implement time-critical applications that need to transmit bits across the wire within microseconds. Typical application programs here consist of three parts. The first initializes the MCU hardware, the second is an infinite loop, and the third deals with interrupts (i.e., interruptions of the normal process, for example by incoming data).

Apart from reliably allocating computing time and other resources, this programming model also exists for many Raspbian programs. Sensors are read and data is written in a regular cycle, which means it is also possible to use CircuitPython with its simpler programming model for these cases.

Blinka

If you want to prepare your Raspberry Pi for CircuitPython, you need the Blinka library, named after CircuitPython's mascot. Its installation, including all dependencies, is handled by the script in Listing 1. Raspbian also has many standard Python packages in the normal repository. However, the script uses the cross-platform Python package installer pip3. This tool downloads the packages, builds them from the sources, if required, and stores them in the /usr/lib/python3.6/dist-packages/ directory.

The script also activates the I2C and SPI interfaces immediately, because reading sensors is one of the tailor-made applications for CircuitPython. After a reboot, the interfaces are then available for your applications. If you have already enabled them on the system with raspi-config, then comment out the lines under the Activate SPI and I2C (as required) comment in Listing 1. You can see from the installation script itself that Blinka uses RPI.GPIO internally – but this only applies to the Raspberry Pi.

Depending on your application, you will need several libraries besides the Blinka layer. The example program presented here is intended to read the BME280 [1] temperature, humidity, and pressure sensor in an infinite loop and output the results on an old-fashioned display with two lines of 16 characters each. For this sensor, the last line of Listing 1 installs another CircuitPython library from Adafruit.

Although Adafruit has published many libraries, they do not cover every electronic component. The cheap LCDs with two to four display lines – you will find them on Ebay or Amazon – often work with the PCF8574T serial converter chip. However, Adafruit uses the MCP230xx for its displays. For this reason, the Adafruit LCD library is not used for the application example, but rather the library from my GitHub site [2]. To proceed, manually download the Python file lib/hd44780.py in the repository and copy it into the directory of your main program.

On MCUs, the process is slightly different because pip is missing. Adafruit provides library packages in ZIP format for each platform. After downloading, unpack the archive and copy the relevant libraries to the lib/ subdirectory.