Revisiting RF24 on Ubilinux

[TL;DR: In summary, we need to modify the “configure” script a little bit, then run the configure command with certain arguments, then edit the Makefile (comment three lines out) then run make install –B. Details/specifics below.]

Hello!

Although this post should be about the first impressions of the IoT pHAT unboxed last time, my attention was recently drawn to major changes in the RF24 compilation process, so I decided to revisit it and leave the IoT pHAT post for next time.

As before, the goal is to be able to use nRF24L01+ radios on Intel Galileo boards running the Ubilinux distro. We’ll be focusing on using the MRAA library as the HAL/backend (recall that RF24 can use SPIDEV or the bcm2708 library as well, the latter supported only on Raspberry Pi boards).

To get started, MRAA itself must naturally be installed. To do this, you’ll want to have the following installed: clang, cmake, python-dev, build-essential (things like make and all that). A full list of dependencies is provided here. Next, download the latest MRAA sources from GitHub and transfer them to the Galileo. Within the MRAA source tree (the directory containing folders such as “api”,”cmake”,etc), create a new directory called build, then enter that directory (cd build). While in that directory, execute the following command:

cmake –DCMAKE_C_COMPILER=clang –DCMAKE_CXX_COMPILER=clang++ –DCMAKE_C_FLAGS=-mno-sse –mno-mmx -march=i586 –DCMAKE_CXX_FLAGS=-mno-sse –mno-mmx -march=i586 –DBUILDSWIGPYTHON=off –DBUILDSWIGNODE=off ..

Essentially we’re telling cmake to produce a makefile which will use clang/clang++ as the compiler, specifically target the X1000 processor used on the Galileo (which does not support SSE and MMX instructions and conforms to the i586 ISA) and not build the support files/bindings for Python and Node. That should complete with a few warnings and no errors – producing a Makefile within the build directory (where you currently are). Next, execute a ‘make’ and ‘make install’ and then we’re good to go.

Next, transfer the RF24 sources to the board. After doing this, navigate into the RF24 source tree (the directory containing directories like “examples”,”tests”,”utility”, etc). You may need to make the configure script executable by executing:

chmod u+x configure

This will be necessary if you transferred the files from a Windows PC (which I did). After running the command is where things get sticky.

First off, we need to tweak the configure file a little bit. If we don’t, when we attempt to build RF24, it will default to using SPIDEV, but we don’t want that. As such, locate the function called detect_driver() (should be at line 177) and replace it with this:

configure_script

What we did was to change the order of comparisons such that the function would check for MRAA first before SPIDEV. At this point, recall that we need to compile this with clang and clang++ because Ubilinux on the Galileo doesn’t seem to like gcc/g++ much. In addition, we need to set the compilation flags to target the Galileo’s processor specifically. Luckily, all of this can be done in one fell swoop by executing the configure command as follows:

./configure --driver=MRAA --cpu-flags="-mno-sse -mno-mmx -march=i586" --c_compiler=clang --cxx_compiler=clang++

From this invocation, you can see that we’re specifying the CPU flags to –mno-sse –mno-mmx -march=i586 as required, as well as specifying which C and C++ compiler to use. Once this is done, we’ll need to make a final change to the Makefile itself. Here’s why.

For some reason, even after running the configure step separately, running the make step re-runs the configure step. This re-run causes a..reset (for lack of a better word) of the compilation variables. To cut a long story short, this re-run tells the compiler to revert to g++ and gcc and not use the compilation flags we’d already specified. This is because the configure command in the Makefile itself omits the flags we’d used earlier. The easiest workaround here is to locate the line “$(CONFIG_FILE):” (which is at line 67 on my PC) and comment it out, as well as the next two lines after it. That is, the section that looks like this in the Makefile:

makefile_unedited

Should be made to look like this:

makefile_edited

This way, when we run the “make install –B” command, it does not re-run the configure step and overwrite our settings. Running “make install –B” now should complete without any errors and we should be ready to hit the ground running. So in summary, we’ll need to run edit the configure script, then run the configure command specifying our custom flags. Next, we edit the Makefile (so it doesn’t re-run the configure step) and then run make install –B.

Two things to note:

1. The constructor used for the RF24 instance in code should specify the CE pin as the first argument, and the SPI bus number as the second e.g RF24 radio(9,1) – pin 9 on the Galileo is connects to the radio’s CE pin, and the Galileo exposes SPI bus 1 hence the second argument being 1.

2. As before, when compiling one’s own apps, remember to link against the rf24-bcm shared library e.g

clang++ myprogram.cpp –o binary_name –lrf24-bcm

The module connections are as below:

Pinout

Thanks to Alhassan Abdulkadir for pointing out the new perils involved and solving the configure script issue!

Comments

Popular posts from this blog

Bitbanging SPI on the Raspberry Pi (via spi-gpio)

Getting Started with Logic Analyzers and Pulseview

Enabling SPI1 on the Raspberry Pi B+/Zero/2/3