A while ago, we were talking about my desire to write a tutorial about "Perl and Raspberry Pi". To kick it off, I thought I'd write a blog post covering some of the aspects of how I ensure full automatic unit test coverage of the software, and its core functionality.

I posted it over on my blog, so for now, I'm just going to link to it as it's just a one-off that I quickly put together. If anyone is interested in how this software is tested, have a look. If you have feedback, all the better. Questions? That's the best I could ask for.

How RPi::WiringPi distribution gets tested


  • Comment on How RPi::WiringPi suite is automagically unit tested

Replies are listed 'Best First'.
Re: How RPi::WiringPi suite is automagically unit tested
by zentara (Archbishop) on Aug 18, 2017 at 15:30 UTC
    Very well done, my hats off to you. You are quite the genius. I printed out a pdf, and I'm sure your page will be referenced to quite often as people ask about the Raspberry-pi-Perl connection. Now all you need to do is sell a kit of all the parts. :-)

    Besides auto-testing of software, what other use could your invention do? Could it flash eeproms on Androids? :-)

    I'm not really a human, but I play one on earth. ..... an animated JAPH

      Thanks zentara!

      Well, this specific "invention" is pretty much sole-purpose... solely to test the software. However, each component is acting on its own, just like one would do in smaller projects. It's just a culmination of hardware so that I can thoroughly test all of the various software components.

      If you removed all of the pieces except for the Pi and the Arduino and the two I2C connections, the software on the Pi side (RPi::I2C) and the current test Arduino sketch combined actually does write to the Arduino EEPROM (and read from it), so that's definitely possible. That said, I'm not familiar with Android, but if it has a Serial or other reasonable API-type interface, then yes, the software could definitely be used to flash the device. If you can provide a link to an example you're thinking about, I'll test it ;)

      The testing software I'm using on this project is one I've spent about three years designing, and until recently, the Pi was not related to it at all. It just fits perfectly for this project :)

      If you were to remove all of the components less the LCD, the test software can be used to dispatch the unit tests from *any* Perl distribution to the Pi, and the results will be displayed on the LCD (the dist has to be on Github though, as that's how it calculates whether a run is needed or not (amongst other things due to it being a literal network run even though both the listener and dispatcher are both localhost).

      I've got about 50 different types of sensors and other things that can all be used by the software I've already written. I'm always on the hunt for a new sensor/IC that doesn't have Perl code yet, and I thoroughly enjoy writing the C/XS, then the Perl wrapper. That's what I enjoy most (reading and navigating datasheets, and turning that into code that operates the devices).

      Currently, I have a full-blown single-page jQuery web UI that controls one of my entire test indoor grow rooms (fans, lights, humidity, medium moisture levels/auto-drip feed system etc). It's backed up by Dancer2. It's incomplete as I haven't worked on it for quite some time, but that dist that does this is App::RPi::EnvUI. The documentation is very lacking at this time as well.

      The only other product I've built that's completed (well the prototype anyway) isn't directly related to Perl other than the knowledge gained allowed me to learn how to do it, is my GPS take me home device.

      Let me know about the Android flash thing. I've got a spare phone which I don't care if I brick if you really want me to play around.

        Hi stevieb. This really adds to my understanding of the Raspberry-pi. I was thinking that you could sell these as multipurpose network-connected sensors. Say something like monitoring temperatures and sunlight on a bank of industrial solar panels, then analyze each panel's efficiency.

        What I really like is your indoor growroom. :-) In that case, you could have light, temp, co2 level sensors all being controlled, and would currently sell good in the marketplace.

        As far as the Android thing goes, I'm not sure exactly how to proceed. In my desire to get a x86-64 bit operating system on a real Intel tablet, I semi-bricked an Onda, chinese made tablet, that dual booted a Chinese Android system and Windows 10. They are selling quite cheap now, as Windows 10 tablets failed to sell. The problem is it's a 64-bit system, but the bootloader is only 32-bit, and it uses EUFI. (F**k I despise EUFI :-) ) Anyways, now it sits in what is called the EUFI Shell, awaiting commands. An additional problem is that without the original Android system in it, it's charging circuits won't run, meaning I only have 1 full battery life to figure it out. I'm considering canabalizing it, and hope the battery will fit in my old Nexxus, which I have the new Open Source Android on it, Nitrogen. It runs great. I wanted to use it watch network cameras setup on a private local network.

        If you would like the Onda tablet, to experiment with, I would gladly mail it to you for free, at no charge.

        I'm not really a human, but I play one on earth. ..... an animated JAPH

      zentara, et-al;

      Here's a pic of the hardware layout that I test against. Please forgive the low quality image.

      I was ready to have PCBs printed, but had to back out at the last minute, so currently, the test platform is still breadboarded, *usually* enclosed in a water/dust-tight container until I can get the custom boards developed.

      As far as the LCD, top-row: date, time, previous unit test run status. Bottom row, run count and the git commit checksum of the last run performed. I've been toying with the layout, but this is adequate for now as this unit *only* tests a single software distribution. I have plans and provisions to use a 20 column by 4 row LCD (as soon as I acquire one), so that I can have distribution name along with other information for situations where I may want other Pis testing other distributions for me.

        Hi again stevieb, might I ask a few questions?

        How many different types of sensors have you got working for the Pi? Is there a list by application type?

        And even though it's not needed, why do you do I2C bus testing with the Arduino?

        I'm not really a human, but I play one on earth. ..... an animated JAPH