August 2017 Archives

So I'm gearing up to write a "Howto Raspberry Pi with Perl" multi-chapter tutorial, and as I finalize a few last things, I thought I'd put together how all of the software is laid out and is continuously tested.

The RPi::WiringPi distribution is essentially a class that provides access to external sub distributions, and provides several benefits such as maintaining a registry of in-use GPIO pins, and ensuring your Pi is cleaned up back to default on exit, or if an error or signal is caught. The sub modules do none of those things.

I use the automation and dispatching capabilities of my Test::BrewBuild software to handle the test management. This software runs your unit tests on any/all Perlbrew and/or Berrybrew installed instances, with the ability to dispatch your test requests over the network to remote machines. I'm not getting into those details, just know I use the bbtester binary to listen for test requests, and the bbdispatch binary to send them, both on the same Raspberry Pi hardware.

I'll explain a couple of things. First, there are no "sensors" or the like being tested. I test the core aspects that do sensor work.

I'll start from top-left to top-right, circle down to bottom-right, then go back left. Top-right is an Arduino Uno. It's sole purpose is to test the I2C communication functionality, which is provided by the RPi::I2C distribution. There's a basic hardware-emulation Arduino sketch that presents a hardware-like situation, to allow testing of base I2C functions.

Next we have the Pi. I don't have the pins connected exactly like this, but this was the easiest method to portray it. Below to the bottom right, there's a 74HC595 shift register, which effectively turns three GPIO pins into eight, and can be cascaded four times, for a total of 32 extra GPIO using only three physical GPIO on the board. I have only one here for testing.

To the left of that is an MCP4922 Digital-to-Analog converter (DAC), which takes a single digital input, and translates that into two analog outputs. RPi::WiringPi provides the RPi::MCP4922 object for this.

Then we've got an MCP3008 Analog-to-Digital converter (ADC), which does the opposite of the DAC, it provides eight analog inputs that can be read through a single digital channel. RPi::WiringPi handles this via the RPi::ADC::MCP3008 distribution.

Then, next to that, the blue "breakout" is another ADC, the ADS1115 by Adafruit, which has four analog inputs (compared to the MCP3008 above which has eight). This is an I2C device, so it provides me further testing in that manner, and its also used for reading Pulse Width Modulation (PWM) testing from the Pi itself, and for the servo() method built into RPi::WiringPi. It's fronted by the RPi::ADC::ADS distribution.

To the breadboard left of the ADS1115 is a two row, 16 column LCD, managed by RPi::LCD. This distribution can handle both the 16x2 and 20x4 models. The purpose of this hardware is to test the output, but also displays overall test output provided by the Test::BrewBuild distribution, as it has a small hack in it specifically to do this not just for the RPi::WiringPi dist, but any distribution you send to the Test::BrewBuild tester.

Now, to how things are tested. First, I start the tester in auto mode:

bbtester start -a

That puts the test listener in the background as a service (although this is Unix, it also works on Windows), then I bbdispatch an automated test run to that tester, specifying the rpi-wiringpi Github repository in the most simplistic of ways (putting this in crontab is the way to go). I've got a single Perl instance installed, and the result line will repeat continuously when run from the CLI (default is wait 60 seconds between run checks). In the bbtester start line above, it will check Github to see if any new commits have been pushed, and only run the tests if there's been an update:

The Test::BrewBuild software is much more capable than these simple examples, but I digress. What I will say that running bbdispatch with the --rpi flag allows you to test any distribution (that's available on Github), and have your output displayed on an LCD screen (including date/time, PASS/FAIL, run count as well as the commit sum).

I run this setup 24 hours a day, seven days a week, and against eight versions of Perl, the Pi hardware test platform can do about 16-20 passes an hour (in a mode that tests regardless if new commits have been pushed).

Both the bbtester and bbdispatch software have extensive logging, and both can be run in "foreground" mode, particularly for troubleshooting. Here's a full-blown example of the dispatcher output, and the tester output.

I have not enabled debug levels for the actual brewbuild command which is the command that actually does the testing (called from within bbtester), as this output will be long enough for this example. In this run, I'm using the --csum flag to bbtester, so it tests on each pass, even if a new commit hasn't been pushed.

Of course, normally output isn't displayed in this regard, but that's a general overview of how my RPi::WiringPi collection of distributions is tested all day, every day, on my custom CI test platform.

Here's the full list of RPI:: related distributions:

RPi::ADC::ADS provides access to the ADS1xxx family of analog to digital converters