Up close with the Banana Pi
GPIO
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).
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.
Overclocking
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
overclock.sh
#!/bin/sh 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\ /cpu0/cpufreq/scaling_cur_freq
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
Pages: 8
(incl. VAT)