Ubilinux on the Intel Galileo: RF24Network


Hey all, been a while. Been surprisingly busy with work and other stuff….assuming “other stuff” turns out to actually work you’ll be hearing about it Winking smile
In other news, I had reason to look into structured sensor nets, and naturally I turned to the nRF24 radios Smile with tongue out. More importantly, Tmrh20 also wrote RF24Network, which is a network layer for ( n )RF24 radios, with tons of interesting features. Rather than recount everything here, more details can be found here. 
For a simple test, I decided to use the Intel Galileo as my “head” node (yeah, all RF24Network…networks need a master node which acts as the centre of the structure, which isn’t all that strange) and an Arduino as a single client node. I’d previously installed the RF24 library for Arduino via the Board Manager, and so I went down this route to get RF24Network as well. For the Galileo, I downloaded the RF24Network sources off of Github, extracted them, and transferred the resulting files to the Galileo.
If you’d seen the previous posts on RF24, you might remember that we needed to make certain changes to the Makefile (amongst other things…) so that RF24 could compile. There’s good news and bad news. Okay, bad news first, and that’s that some modifications are also needed to get RF24Network properly compiled as well. The good news is that the modifications are waay fewer and easier to implement. Without further ado, here are the relevant instructions:
1) Replace all occurrences of “g++” (no quotes) with “clang++” (no quotes). This is because there’s apparently some sort bug with g++ on Ubilinux (as discussed in previous posts) so we use clang++ as the compiler instead.
2) Go to line 40, which should look something like CCFLAGS=xxxxxxxxxxxxxxxxxx , or whatever line it is that the recommended compiler flags for the Raspberry Pi are being specified. Add the following text below that line (i.e CCFLAGS==-Ofast -mfpu=vfp…) and the line that reads “endif” (no quotes”") :
else
ARCH=i586
CCFLAGS=-mno-mmx -mno-sse -march=$(ARCH)
So the whole section should look like this:
ifeq "$(RPI)" "1"
# The recommended compiler flags for the Raspberry Pi
CCFLAGS=-Ofast -mfpu=vfp -mfloat-abi=hard -march=$(ARCH) -mtune=arm1176jzf-s -std=c++0x
else
ARCH=i586
CCFLAGS=-mno-mmx -mno-sse -march=$(ARCH)
endif
Essentially, we’re saying that if the RPI variable is not 1 (meaning that this device is not a Raspberry Pi), then set the ARCH variable to i586 (the Galileo’s processor architecture) and set the CCFLAGS variable to –mno-mmx –mno-sse -march=….yeah you get the gist. The ARCH and CCFLAGS variables will be used later on in the Makefile when creating the shared library, and by setting them this way we ensure that a binary that will work (without issue) on the Galileo is generated.
That’s it. Run a make and a make install and Bob should be your uncle that should complete with no errors whatsoever. You are now ready to run RF24Network-capable applications!
Of course, the proof is in the pudding, so I took the helloworld_rx example from the examples_Rpi folder in the RF24Network source tree, placed it in another folder, and modified it as a simple exercise. I had to make a few modifications here too (I know, I know).
1) Ensure that the RF24 object uses the right constructor: RF24 radio(9,10) in my case, not   RF24 radio(RPI_V2_GPIO_P1_15, BCM2835_SPI_CS0, BCM2835_SPI_SPEED_8MHZ) by default. In your case, the constructor arguments might be different so simply use what will fit your use case.
2) When compiling the app itself, use the following invocation:
clang++ <input filename> –lrf24network –lrf24-bcm –lmraa –o <output filename>
That is, compile using clang++ and link against the RF24Network, RF24 and MRAA libraries. My input filename was helloworld_rx.cpp, since I was using that example. It makes the Galileo the Master node by assigning it an address of 00 (which is the Master Node address). At this point you might want to setup the Arduino (install the RF24Network library, connect the radio, etc) and upload the helloworld_tx sketch to it. That particular sketch sends data to the Master Node, which will establish the most basic comms (which is what I was trying to do). On doing so, you can now run the program you just compiled, and you should see lines reading:

Received Payload # xxx at yyyyyy
Received Payload # xxx at yyyyyy
Received Payload # xxx at yyyyyy

Where xxx is the payload number, and yyyyy is the payload…payload, which in this case is the Arduino’s runtime (which should be increasing in increments of 2000).
Hopefully these steps should’ve worked for you. If you have any trouble you can reach out via the comments and I’ll do what I can to help.
At this point, you should be ready to take on the shadowy world of nRF24-based RF networks. Use the force, <insert name here> !

M.

Comments

Post a Comment

Popular posts from this blog

Getting Started with Logic Analyzers and Pulseview

Image
Hey all, Been a while. Hope you’ve been up to no good, hm? A couple of days ago, I had to do some low-level I2C work on a bare-metal ATMega328P. Digging out the datasheet, I cobbled a simple I2C driver together, the purpose of which was to permit me write a driver for the particular peripheral which would call the lower-level functions the driver provided (i.e things like i2c_start(), i2c_stop(), i2c_address(), etc etc). When I finished the I2C driver, I tested it out with an MMA8452Q I had lying about and it seemed to work just fine. Believing everything to be dandy, I went ahead and wrote the peripheral driver for the component I was working with. And that was when the funny stuff started. To cut that long story short, it wouldn’t work right when deployed to the hardware. At all. I was in a bit of a bind – the code looked great, no errors no nothing, so it was time to look at the hardware/wire-level end of things. Logic analyzers (in my limited understanding) are tools/instrume...
Read more

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

Image
Hello all and happy holidays to everyone! I’m taking a break off work for the holidays so I have a little bit of time on my hands. I will therefore regale you with tales of my exploits! From my last post, I talked about the somewhat “edge” case where you’d want to add (cheap) Ethernet to a Raspberry Pi, probably the A+ or Zero as the case may be. I haven’t figured out the fixed MAC thing just yet, but I’m working on it. Anyways, after some time, another edge-edge case came to me: The ENC28J60 takes up the only SPI peripheral available on the Pi, so what if you needed to use both the ENC28J60 AND some other SPI device? The Pi’s SPI peripheral has two chip selects, so it is theoretically possible to use the exact same bus while using the first chip select for the ENC28J60 (which it uses by default) and using the second chip select for the other device. However, it goes without saying that network communications require some serious computing firepower so it might cause a bit of a perfo...
Read more

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

Image
Me hearties, Let us plunder and pil.. Sorry, wrong blog. Ahem. Hey all, Its been a while. Been busy at work as usual, and haven’t really had much time to write much. As penance, I will post not one but two updates! This particular post is in relation to Raspberry Pi users specifically. I had earlier talked about the vagaries involved in emulating SPI over GPIO in order to get an additional SPI peripheral. It was a moderately involved process, but the rewards were great With the most recent release of the Raspbian Jessie distribution (2016-05-10), a number of improvements have been made to both the desktop parts and the “under-the-hood” parts, perhaps most significantly the kernel. This new release uses Kernel version 4.4, which now adds the ability to use the second hardware SPI peripheral, SPI1, on the Raspberry Pi. This is only available to devices with the 40-pin header (as seen from the title of this post) so users of the original model A and B will probably need to turn to...
Read more