Data Collector

The data collection program (Listing 2) addresses the BME280 over the I2C interface of the Raspberry Pi. SDA is located on header pin 3 and SCL on pin 5, which only plays a role for the wiring; the program itself uses the platform-specific board package (line 11), which makes porting to other platforms easier. With board.<xxxx> you can access a whole range of symbolic constants for various hardware features. To reach this data, busio.I2C() creates an interface to access the standard I2C device and busio.SPI() the SPI interface.

In addition to the data lines, the sensor in this example requires 3.3V and a ground connection (although some sensors of this type are 5V; check your sensor specs). Thanks to the serial adapter, the LC display is controlled by the same data lines – but the display requires 5V operating voltage. Careful users will want to solder out the pullups of the PCF8574T, which boost the I2C bus to 5V. Because the Raspberry Pi has internal pullups on SDA and SCL, they are not necessary (Figure 2).

Figure 2: The test setup with a sensor and a display.

A breadboard allows both components to be connected simultaneously to the normal I2C connector of the Raspberry Pi. Both components usually use the addresses 0x27 and 0x76 on the I2C bus. Depending on the module, however, the addresses may differ. The i2cdetect program from the i2c-tools library provides this information (Figure 3).

Figure 3: The output from i2cdetect shows the two components at the addresses 0x27 and 0x76.

The program in Listing 2 creates the Python objects for the sensor, the display, and a button in lines 11 to 17. The sensor delivers the temperature, humidity, and either the air pressure or the altitude. The last two parameters depend on each other: If you specify the altitude, the sensor outputs the air pressure. If you specify the air pressure, the construct calculates the altitude. For a stationary system, the first option is more useful.

After initializing the components, the program runs in an infinite loop starting in line 25. The measurement is taken automatically by accessing attributes of the BME280 object. Lines 30 and 31 format the output to fit on the display being used, which has two lines of 16 characters each. At this point, the data could still be stored in a CSV file for later processing in LibreOffice Calc or for saving in a database. However, if you are looking for maximum compatibility, you will want to avoid this path because the program will then no longer run on a microcontroller unless modified.

Restrictions

For didactic reasons, the program from Listing 2 uses an optional button that switches the backlight of the display on or off. The button is connected to GPIO4, and the program accesses it with board.D4 (line 15). The query is quite simple with the value attribute (line 34).

The button, however, also shows what is currently CircuitPython's biggest limitation. The run-time environment does not support interrupts or any kind of asynchronous code processing. Therefore, the application program needs to constantly query the button. The more switches it has to manage, the higher the chance of missing a button. This approach unnecessarily inflates the rest of the application logic, as well. The sample program does not care and reads the sensor 10 times per second, which is not always possible or useful.

If you want to query the sensor at fixed intervals, you have to save the last reading time and regularly check whether enough time has elapsed. Because CircuitPython does not have its own interpreter on the Raspberry Pi, on this platform you could simply choose to ignore the limitation and work with threads; however, then the programs cannot be ported without customization.

Another restriction concerns the available libraries. The SAMD21/SAMD51 MCUs now have the displayio library for output on (small) displays. This library lets you display images, text, and graphics comfortably. The library has not yet been ported for the Raspberry Pi. The only option is to use libraries such as Pillow from the normal Python collection. Also, the UART interface works a bit differently with Raspberry Pi and uses the normal Python serial module.

Porting

Porting existing libraries to CircuitPython is comparatively simple. I created a MicroPython library for the small DFPlayer Mini MP3 Player chip and the LCDs used in the example. In the latter case, I left out almost half of the code lines, because the I2C abstraction of the CircuitPython libraries replaced the equivalent DIY functions.

The situation is different when porting Blinka to other platforms. Adafruit has a manual for installing on the Orange Pi R1, an even more compact SBC than the Pi Zero. The module is based on the Allwinner H2 chip and, thanks to its four CPU cores, is even better than the Pi Zero for many CPU-intensive tasks. The biggest disadvantage of these still fairly exotic SBCs is the lack of support for the various hardware add-ons available for the Raspberry Pi family. The future looks far rosier for Blinka. At least all boards that use standard interfaces like I2C, SPI, and UART are immediately ready for use with an available Blinka port.

A test port to the Orange Pi One Plus SBC, which uses the Allwinner H6, turned out to be more complex than expected. Additionally, a lack of documentation from the SBC manufacturer further complicates the work. To make things worse, Adafruit also does not have a porting guide, which adds complications.