I have been investigating the use of Free Pascal and Lazarus on the Raspberry Pi. The Pi is a minimal, low cost, ARM based computer, designed primarily for educational uses. As a Pascal advocate, I would love to see a modern Pascal compiler made widely available on a platform like this.
The official operating system for the Pi is called Raspbian which, as it’s name suggests, is a derivative of Debian Linux. Free Pascal and Lazarus packages are available on Debian, so I wanted to see if they had successfully transferred to Raspbian in a usable form.
I have one of the new Raspberry Pi Model B’s that has 512Mb of RAM and I have been using it with the current Raspbian image (2012-10-28). After spending a little while getting to grips with Raspbian, I was able to progress to the business of testing Free Pascal. The good news is that the standard Debian packaging commands worked a treat:
sudo apt-get update sudo apt-get upgrade sudo apt-get install fpc sudo apt-get install lazarus
The only snag from a visibility point of view is that there is no automatic integration of Lazarus into the LXDE menu. From the command-line though, ‘fpc’ will invoke the compiler and ‘lazarus’ the GTK2 based IDE. However, as with Debian, the versions of the available packages are a little behind the current releases. On my main Kubuntu system, I habitually build Free Pascal and Lazarus from source, using Subversion to obtain the latest changes. This process requires a seed compiler, which in this case, can easily be supplied from the default repository.
So I started again with a fresh Raspbian SD card, but this time, I only installed FPC from the repository. Free Pascal additionally requires the GNU build tools and fortunately these are already installed in Raspbian, so I only had to add Subversion before I could attempt to use my usual build process on the Pi with a few of the options tweaked for ARM output:
sudo apt-get install subversion
Whilst researching this I have found that others have already attempted this with varying degrees of success. Common problems encountered seem to be caused by running out of memory, or card storage space during the build process. Indeed, I hit both issues even with the Model B’s 512Mb RAM. In the case of RAM usage, I had to reduce the amount of RAM dedicated to the GPU from 128Mb to 64MB. I have seen reports for Model A Pi’s where this needed to be reduced to 16Mb to avoid problems. I also ran out of space on a 4Gb SD card and had to swap to an 8Gb one to provide enough head-room.
After a couple of hours solid processing I had a working build of Free Pascal 2.7.1 with ARM hard float support and Lazarus 1.1. For thoses interested in repeating this process you can download the scripts here: FPC Build Script and Lazarus Build Script. It is worth pointing out that the two scripts behave in slightly different ways. The Free Pascal process is more elaborate for two reasons. Firstly, it always makes a temporary working copy to perform the build, this is a brute force approach to preventing changes over time causing build issues for the compiler or runtime libraries (admittedly at the cost of build time). Secondly, it also performs a full install to the system to superceed the Raspbian 2.6.0 seed compiler. This means that it becomes the new default ‘fpc’ system command. The Lazarus script, by contrast, is a much simpler affair, building its binary in the subversion working folder. I usually run it from this personal folder, from which I can make changes such as installing additional packages, without having to use sudo permissions.
Now I wanted to evaluate the capability of this new setup. Firstly I built several of the standard example programs supplied with Lazarus. All of the ones I tested executed without problems and they looked pretty good on the LXDE desktop. It is worth commenting on the fact that the general operation feels sluggish compared to an Intel based system. However, it is not that slow that you would find it unusable and I have seen Eclipse run slower on a much more capable PC!
Much of my work with Lazarus involves creating graphical output, so I wanted to see how it coped with using some of the graphics libraries available. The built in FPGraphics and LCL TBitmap work without issue, but are often much slower than more specialised options. Next I tried the Lazarus OpenGL package. This unfortunately, did not compile. I will investigate this further and it will probably become the subject of my next post on the Raspberry Pi as the Pi has very good hardware support for OpenGL. I also tried Graphics32 and BGRABitmap which are both highly optimised software renderers for 32bit raster images. Unfortunately, both of them seem to have too many low-level Intel dependencies to port easily to an ARM based system.
To test the system’s graphics capability, I have written a small Mandelbrot set renderer, as shown below, (Source Code). This uses the simplest form of TCanvas.Pixels method for writing the image. This project takes around 2 seconds to generate the image shown below on my Intel i7 based system, but nearly 2 minutes on the Pi! I haven’t performed any detailed bench marking yet, but I will investigate this further.
There is a very interesting Mandelbrot set program called ‘triangle2.c’ supplied on the Raspbian SD image in the /opt/vc/src/hello_pi/ folder. This is written in C and uses OpenGL and fragment shaders to achieve very fast access to the Broadcom GPU hardware present on the Raspberry Pi. It produces stunning results, calculating a full screen Mandelbrot set with overlaid Julia set in real-time. So there should be plenty of scope to reduce my program’s 2 minute render times! It will be especially interesting to see how fast a pure ARM CPU program can operate before having to resort to direct GPU calls for further improvements.
One last comment about Free Pascal is to mention that it can be compiled as a cross compiler, meaning it can be an Intel based program that I can run on my desktop system, but generate ARM binary output for execution on the Pi. Whilst running a native Lazarus desktop on the Pi is perfectly feasible (in fact, it would be a very good platform for introducing people to visual programming in Pascal), large projects would certainly feel more comfortable when worked on with a much faster CPU, especially whilst compiling larger projects and I will definitely be looking into this over the coming weeks.