Terminal 28

[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 prov...

The first thought that came to my mind when I read that was: “wow, that’s a remarkably complicated-sounding name for a simple blog post”. I’m looking for replacements, so please drop a few in the comments. Anyway, back to business. The point of this post is to outline the procedures involved in using nRF24 radios (by now, you’ve realized I must really like them ) on a Raspberry Pi via a bitbanged SPI connection. Normally, you’d simply compile and install Tmrh20’s RF24 library, wire up the module the Pi’s dedicated SPI pins, and then go forth from there. However in my last post, there was the possibility that the hardware/dedicated SPI pins would be used for some other purpose ( oh I don’t know, providing wired ethernet maybe? ) and would be unavailable to do this. I then talked about the moderately-involved process of providing a software-based/bitbanged SPI peripheral which could then be used for some other purpose. This post aims to illustrate one such possibility. The RF24 librar...

[Deprecated - Updated post is  here ] *sigh* The saga continues. So, I did some googling around, and found a blog where a guy recommended installing a tool called valgrind. Apparently valgrind is a memory leak detector amongst many other things. Was a bit skeptical but I went right ahead, apt-get install'd valgrind and then invoked my new program under valgrind as follows; valgrind ./program After about a minute or two, valgrind shows me an error at some memory location, explaining that it encountered an illegal/invalid instruction at that location and gave me two reasons why that could happen. Following the...stack trace....it printed, the problem seemed to be coming from code in the librf24-bcm.so file. Strange. After some more Google-fu, which eventually led me to Wikipedia, I found that the Quark X1000 SoC used on the Galileo did not support SSE or MMX instructions, and was instruction-set architecture compatible with the i586 family. I thought about it, and it seemed ...

[Deprecated - Updated post is  here ] Hey all, So, today I continue my little anecdote about getting the RF24 library up and running on the Ubilinux distro running on the Intel Galileo. From the last post, I ran: make -B RF24_MRAA=1 but got an error about WProgram.h not being found. After some knocking about, I figured that editing the RF24_config.h file and adding these defines: #define MRAA #define RF24_LINUX To the section titled "/***** User Defines*****/" Would make it possible to compile it. Thus, after editing the file, I ran make -B RF24_MRAA=1 again, and the compilation began in earnest. Please note that at this point, I had downloaded, compiled and installed the MRAA library as described in  this post . Sadly, I didn't set the CC and CXX variables in the make invocation, so make defaulted to using gcc and g++, and I got the "illegal compiler instruction" error once again. Re-running make as: make CC=clang CXX=clang++ -B RF24_MRAA=1 still en...

[Deprecated - Updated Post is  here ] Hey all, A few months ago, I had the opportunity to play with a couple of nRF24L01+ 2.4GHz radios from Nordic Semiconductor. Xbee radios from Digi are cool but rather pricey, and in all fairness I've only ever used them in simple point-to-point networks. The cheap 433MHz radios pick up waaaaay too much noise to be useful in high-throughput scenarios IMHO, so I was surprised to see how well the nRF24s performed. They're also really cheap (check 'em out on Aliexpress), interface to the host controller over SPI, and have some impressive features like configurable radio channels, communication rates, transmit power and a flexible addressing scheme, in that each radio has a number of "Pipes" which are like slots for sending or receiving data. Basically, the Pipes are numbered 0-5, and Pipe 0 is used for transmission (when transmitting) by default, while all other pipes are strictly reception pipes. Pipe 0 and Pipe 1 can unique h...