Setting up PiDuino with Raspbian Buster

Years ago I bought myself a PiDuino from SK Pang with the original intention of using it as a power management board for my digital cluster project (ended up using a SleepyPi 2 in the end) and so hadn’t touched it for a few years, below are my notes on getting it working under Raspbian Buster on a RPi 3B+ in April 2020.

The original assembly guide is still relevant for soldering the board together, as well as the instructions for setting up and testing the software, especially Gordons instructions

In summary I performed the following:

Install Arduino and installed a modified version of avrdude (this might not be needed anymore as the standard avrdude could work, but didn’t test).

sudo apt-get update && sudo apt-get upgrade
sudo apt-get install arduino

cd /tmp
sudo dpkg -i avrdude_5.10-4_armhf.deb
sudo chmod 4755 /usr/bin/avrdude

Next regain control of the serial port by removing console=ttyAMA0,115200 from ‘/boot/cmdline.txt’

sudo nano /boot/cmdline.txt

We also need to edit ‘/boot/config’ and add a couple lines to reconfigure the serial port

sudo nano /boot/config.txt

And then add at the bottom:

Then stop the Systemd getty service and disable it from starting on boot with, followed by a reboot

sudo systemctl stop serial-getty@ttyAMA0.service
sudo systemctl disable serial-getty@ttyAMA0.service
sudo reboot

Then following more instructions from Gordon, add the custom board and programmer entries into Arduino (you might be able to get away with just adding the custom programmer entry if you’re just interested in flashing the PiDuino using the RPi pins).

cd /tmp
cd /usr/share/arduino/hardware/arduino
sudo mv boards.txt board.txt.bak
sudo mv /tmp/boards.txt .
sudo mv programmers.txt programmers.txt.bak
sudo mv /tmp/programmers.txt .

With that all the software should be setup ready for use, connect the Piduino to the RPi header and fire up Arduino.

Set Tools -> Board -> Arduino Pro or Pro Mini (3.3v, 8 MHz) w/ ATmega328

Set Tools -> Programmer -> Raspberry Pi GPIO

You can now upload example programs such as ‘Blink’ to test that the upload functionality is working okay, be sure to use upload using programmer instead of just clicking the regular upload button

Select File -> Upload using programmer

When I did this I found that the example ‘blink’ project was running but very very slow, taking approximately 5 sec’s for the LED to blink. This can occur when the bootloader hasn’t been set, this is easy to fix by burning the boot loader.

Select Tools -> Burn Bootloader

With that the blink project should blink at the correct speed and everything is all setup and ready to go.


Using Buildroot for IoT Projects

Buildroot RPi Yocto Logos

Early on in my effort to build a digital dash for my car I quickly realised I needed to run a stripped down version of Linux if I was to have any chance of getting the dash to boot up quickly on the Raspberry Pi. A dash that kept you waiting for tens of seconds or at worst minutes to turn on wouldn’t exactly be the most practical of solutions (especially if you want to avoid speeding fines hehe).

So I was faced with the situation of taking one of the existing distributions available for the RPi and modding it for my own use, or having a crack at making something myself that would do the job. Initially I did start tinkering around with seeing how fast I could get stripped down versions of Raspbian and Arch booting up, which although was interesting did feel as though I was spending a lot of time and effort digging down in the dirt and undoing a lot of work someone else had already spent a lot of time doing. Therefor instead of trying to tear something down to suit my needs, I decided to focus my attention to incrementally building something useful from the ground up. I figured doing it this was would be a great source of learning as I would no doubt begin to run into obstacles other people have already created solutions for, meaning I would appreciate the open source communities hard work even more so.

After a bit of searching I found a couple of promising looking projects to base my dash on (I really didn’t feel like totally reinventing the wheel). Both Buildroot and the Yocto Project share the common goal of creating a complete, easy to customise, embedded Linux system. Both compile Linux from source using cross-compilation (which should cover most performance requirements), are well documented, actively maintained and already used within the embedded systems industry. In fact I had already been exposed to the Yocto project before without even realising when I attended an Intel Edison workshop at the London FabLab, as the Linux image supplied by Intel for use on the Edison is a Yocto build.

Whilst I already had some experience with Yocto I decided to kickstart my digital dash using using Buildroot. Namely in the effort of simplicity as to get started with Buildroot is just so easy. The documentation available is awesome and provides a steady learning curve. I also found a pretty good short book on using Buildroot with the RPi which was neat primer. After a bit of tinkering I had the environment setup in a Ubuntu VM as well as a working filesystem that booted in seconds on my RPi2. I quickly appreciated the number of tools available out of the box in major Linux distributions as theres really not much to do in a basic buildroot build other than logging in and a few system utils to work with.

It was not before long I had my buildroot environment stored under Git and had automated a few of the basic build commands, such as copying over custom apps after a successful build and flashing the filesystem to SD card. All in all it didn’t take a ton of effort to get a simple enough system working that booted up fast, was capable of connecting to the Internet and launched my prototype app on boot. My prototype app is built using QT with PyQT bindings, both of which buildroot supports although not the latest versions.
I would happily recommend Buildroot to anyone who wants to learn more about Linux targeted for embedded devices and IoT projects, it really is a pleasure to work with and the community behind it is very resourceful and helpful.

Looking towards the future for my digital dash there may come a time where I may have to look to migrating towards other projects like Yocto. Buildroot is great and pretty much does everything I need at this point in time, however it does have what I consider to be quite a big no-go – especially in the IoT community. There is no package management system and no binary packages, meaning updates to the system are not possible via packages. If a future release of the Linux kernel fixes a security vulnerability, a full system update would be required which would involve physically removing the SD card and updating the software manually. Best practices for building IoT devices include having an inbuilt mechanism from the word go, allowing for critical updates to be issued that threaten to compromise the device without having to rely on the end user to manually update their device.

All of this is subject to change I guess, Buildroot could one day change how they do things. For now I’m sticking with them as I’m the only one working on the dash project, but being the responsible security guy I am if I open up the project for others to tinker with I would want to switch to another project that supported some form of inbuilt updating.

Anyway it’s about time I get back to finishing rebuilding the engine for the Mk1 so I can actually test the dash in-car for once instead of on my desk!


Which slice of Pi to try?

Raspberry Pi Logo SVG

I was one of the lucky few to get hold of my Raspberry PI during it’s initial release earlier this year. Since then I haven’t really done much with it, apart from tinkering around with the different OS’s available for installation.

I plan to use my Pi for a future project named “open-dash” (project details coming soon), which will essentially require the Pi to boot ASAP and run a simple GUI application in fullscreen upon startup. The application will simply display statistical data and will not require the use of a keyboard or mouse.

So this weekend I have been experimenting with the different OS’s easily available to install on the Pi, from

  • Raspbian “wheezy”
  • Soft-float Debian “wheezy”
  • Arch Linux ARM
  • QtonPi

Straight away from just looking at the list I can rule out the “Soft-float Debian Distribution”, as it is not utilising the full capacity of the Pi’s hardware by relying on software to perform tasks that instead of using the hardware that will be quicker.

1 down, 3 to go.
I propose a simple test to help me draw an initial conclusion. I will create a simple test application to be executed upon system boot, and time how long it takes until execution occurs. I will begin research into using minimal based installation images, to strip use of any unwanted packages that would be otherwise unnecessarily loaded, in effort to reduce overall boot time. Without looking at other users benchmarks, I am aiming for a sub 10 second boot time.

UPDATE 18.11.12

After trying numerous distro’s, I was struggling to find a sub-10 second boot time. Official releases of Raspbian boot in about 20 seconds, un-official stripped down releases of Raspbian¬†claiming to be ‘minimal’, didn’t prove to be much quicker. However the official release of Arch Linux boots in near enough damn it 10 seconds, which seems to be promising. Hopefully with a little tweaking I can reduce the boot time even more by removing unnecessary services, as well as looking into a re-building a custom kernel.