Up close with the Banana Pi


According to the Banana Pi team, the GPIO pins on the P1 header of the Raspberry Pi are pin compatible with the GPIO pins on the GPIO CON3 of the Banana Pi (Figure 4).

Figure 4: Banana Pi pin layout.

In theory, this pin compatibility means your existing Raspberry Pi add-on boards will also work on the Banana Pi, Unfortunately, because of the dimensional differences between the two Pis, your existing add-on boards might not actually physically fit onto the GPIO header (see the later section on add-ons and accessories). The boards should work electrically though, so if you want to move to the Banana Pi from the Raspberry Pi, you can still use them, and if they don't physically fit, you will just have to use a 2x13 pin cable to connect any ill-fitting add-on boards to the Banana Pi.

According to the specifications provided by the manufacturer, the Banana Pi is also capable of CAN bus connections (CAN bus is an automotive communications network) and hardware PWM, which are not available on the Raspberry Pi and are two quite useful features. The GPIO J12 header on the Banana Pi is in a similar position to the P5 header on the Raspberry Pi; however, they are not pin compatible.

Unfortunately, I have not been able to test the functionality of the Banana Pi GPIO pins or any of the additional functionality because of the lack of GPIO software support. A number of forum posts on the LeMaker Banana Pi forums imply that they have some form of functioning GPIO access available on the board. However, at the time of writing, the forum posts gave no information on how they have achieved GPIO access. They appear to have taken Gordon Henderson's WiringPi [11] and Ben Croston's RPi.GPIO [12] and are modifying the source code so that these tools will work on the Banana Pi.

Apparently, these tools are scheduled for a late June release [13], but because no further information has surfaced yet, it would seem that the schedule is experiencing some delays. I tried inquiring about this functionality, but the support network behind the Banana Pi is quite lacking, and the support that did materialize was delivered in broken English by a technician who did not seem to understand my requests. Apparently, the Banana Pi makers are also testing SPI, I2C, and UART, and I would guess that these would be available at the same time as the other GPIO functionality.


The Banana Pi, like the Raspberry Pi, lets you adjust the CPU frequency in real time using the on-demand scaling governor. (The governor is a driver that regulates the CPU frequency [14].) Unfortunately, Banana Pi does not come with a tool for setting up overclocking like the one included in raspi-config for the Raspberry Pi, so you have to do it manually. Overclocking is safer on the Raspberry Pi because of a feature that starts the Raspberry Pi using the powersave CPU governor and lets you press shift during the boot sequence to stop any overclock settings you have applied. If you have accidentally overclocked too much, you have a chance to easily correct the issue. The Banana Pi does not have this feature, so you have to be more careful and test the overclock settings more thoroughly.

To manually enable overclock, you need to create a shell script using the nano text editor. Type the following command into an LXTerminal session:

sudo nano overclock.sh

This command will open a new document called overclock.sh in the nano text editor. You will then need to type the code shown in Listing 1. Then save the file. This new file will appear in the /home/pi directory. See the box titled "Overclock Script" for more on the contents of overclock.sh.

Overclock Script

To give you a basic idea of what the code in Listing 1 is doing, the first line tells the system that the script is a shell script. The second sets the CPU to an on-demand scaling governor, which allows it to change frequency on the fly – this means when there is not much load on the CPU, it will go to its minimum allowed frequency (set in line 4 of this script), and when it is under a large amount of CPU load, the clock frequency will increase to its maximum. The third line sets the maximum CPU frequency, and the fourth line sets the minimum CPU frequency.

The fifth line sets the up_threshold parameter, which tells the system the CPU percentage usage limit you need to reach before the CPU frequency is increased – the higher you put this value, the longer it will stay in the low frequency state, which can be a good thing if you are trying to save power in a battery-powered application. The final line sets the sampling_down_factor, which is a setting to effectively determine how frequently the CPU usage is polled – a higher setting will poll the CPU less frequently (by multiplying the standard time by the applied factor) and therefore will allow the CPU to spend more time doing real work. On the other hand, if the CPU goes above the up_threshold level set in line 5, the CPU will stay in an overclocked state for a longer period, which could cause your CPU to run hotter. In that case, it might be beneficial to employ some kind of heat management technique, such as a heat sink, if you are planning on some serious overclocking!

Listing 1


echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
echo 1000000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
echo 600000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
echo 25 > /sys/devices/system/cpu/cpufreq/ondemand/up_threshold
echo 10 > /sys/devices/system/cpu/cpufreq/ondemand/sampling_down_factor

The default values for the overclock parameters are set as follows:

scaling_governor:  fantasy
scaling_max_freq: 384000
scaling_min_freq:  912000
up_threshold: 95
sampling_down_factor: 1

This default scaling_governer setting of "fantasy" on the Allwinner A20 keeps the speed at a minimum of 384MHz up to a maximum of 912MHz. Apparently, the fantasy governor is a hybrid of the smartass and interactive scaling governors.

Once the script is created, you need to run it in order to enable overclock, and then perform some tests to check stability.

Type the following command:

sudo bash overclock.sh

A good way to test the stability of the system is to run the following command in an LXTerminal session:

for i in {1..100000} ; do set X 1; done && cat /sys/devices/system/cpu\

This code will run a loop, which, on my Banana Pi, puts the CPU up to 53 percent. This should be enough to kick in the overclock if you, like me, set the up_threshold setting to 25. At the end of the loop, the system will print out the maximum CPU setting reached, which, with default settings, is 912MHz. If your system behaves normally under an overclock setting, you can try a higher set ting. If your system starts displaying some odd behaviors, such as a flickering screen or freezes, you have overclocked too much and you need to go back down to a lower setting. If the system has frozen, I recommend pressing and holding the power button or, alternatively, just pulling the power cord.

You can then restart the system, and it will have returned back to the default settings. You can then try to overclock at a lower level. I recommend starting with 1GHz as the maximum frequency (as in the above script) and gradually working your way up in intervals of 0.025GHz or 25MHz. In the preceding shell script, you would therefore start with a value of 1000000 and work your way up in intervals of 25000.

Once you have reached the highest stability level possible with your CPU, you can then apply these settings permanently during boot with a call to overclock.sh in the /etc/rc.local file.

Once the system is back up and running, you can then check that the overclock settings have been applied correctly at boot by typing the following command into an LXTerminal session:

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq

If you have used the same settings as me and the system is idle, you should receive an output of 600000; otherwise, with an idle system, you should receive the same number you set for the scaling_min_freq parameter.

Please be careful doing this overclocking work – if you apply an overclock setting at boot that is not stability checked and the system can't handle it, you will no longer be able to boot from that SD card and will need to either begin with a fresh SD card image or try to edit the overclock.sh shell script using another Linux device.

I was able to overclock the dual-core Allwinner A20 at the heart of the Banana Pi to 1.2GHz while still maintaining an acceptable level of stability. The level of achievable overclock will vary from chip to chip, though, so you might be able to achieve more or less using your own Banana Pi.

Buy this article as PDF

Express-Checkout as PDF

Pages: 8

Price $2.95
(incl. VAT)

Buy Raspberry Pi Geek

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Banana Pi M3 vs. the LeMaker HiKey

    When you need plenty of power, a Raspberry Pi might not be enough. We tried our luck with a couple of souped-up single-board systems: the Banana Pi M3 and the LeMaker HiKey.

  • Testing the Odroid-C2 and LeMaker Guitar

    The LeMaker Guitar and Odroid-C2 are hobby computers that were created as competitors for the Raspberry Pi 2, but we discovered they can even challenge the Raspberry Pi 3.

  • Welcome

    Our cover says "Boards Galore!", and we're not kidding. Last issue, we reviewed the LeMaker HiKey and the Banana Pi M3. This issue we add the Odroid-C2, Pine A64+, LeMaker Guitar, BBC micro:bit, and C.H.I.P. Each of these small-board computers (SBCs) have strengths and weaknesses, so you have to understand the needs of your project to choose wisely.

  • A Banana Pi-based router

    The BPi-R1 is an attractive and affordable combination of switch, access point, and server. We look at how this Banana Pi-based router performs.

  • Raspberry Pi 1 and 2 compared

    The Raspberry Pi 2 looks just like its predecessor, the Rasp Pi 1 B+, and has lots of similarities. However, the freshly hatched second generation is much faster.