Terminal 28

[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

Hey all, Having fixed my compiler trouble (as described in my previous two posts), I then decided to look at MRAA. MRAA (pronounced em-raa) is a hardware-abstraction library, which in English means it provides a means of using the hardware peripherals (GPIO, UART, SPI, I2C, etc) on a given board. Currently MRAA supports the Intel Galileo and Edison, and apparently also the Raspberry Pi and BeagleBone Black amongst others. MRAA aims to provide a standard interface for accessing those peripherals across these boards (and hopefully more as time wears on). Naturally MRAA is essentially C/C++ based, with Python, Node.JS and (apparently) Java bindings. The usual way of installing MRAA is to pull it from Github, create a 'build' folder in the source tree, run cmake to generate the relevant Makefiles, and then run make and make install from the root of the source tree. However, the git version available on Ubilinux doesn't seem to work quite right on the Galileo, so I simply down

Hello again, So, from my last post, I explained (in too many words) that I had trouble with gcc on the Ubilinux distro running on an Intel Galileo Gen 1. Now, I'd read about an alternate...compiler....called Clang. For the experienced readers out there, please don't spit in disgust! Clang isn't just a compiler...its....uh.............a compiler front-end that uses LLVM as its backend.......... For the purposes of this post, think of Clang as a gcc replacement. This is acceptable, and it is actually designed to be a drop-in replacement for gcc in that the invocation and command-line flags are identical between the two. I thought that this would be a good thing to try to circumvent gcc's issues. I was in luck, as I found Clang version 3.5 in the Ubilinux repos (via apt-cache search) and so I went ahead and installed that. You get two compilers...Clang for C (like gcc), and Clang++ for C++ (like g++). Now, when using Makefiles, it is possible to explicitly specify the

Hey all, I'm not sure if I mentioned this at some point (probably didn't....), but I got my hands on an Intel Galileo Gen 1 board. As a quick summary, its an Embedded Linux development board - think Raspberry Pi and BeagleBone Black. However, its a rather monster from those two for two primary reasons: 1 - Coming from Intel, it actually sports an x86-class processor as opposed ARM processors that more common in dev boards today. Specifically, it uses the Intel Quark X1000 SoC running at 400MHz which (according to Wikipedia) has is architecture-similar to the i586 proc family. However, it doesn't support MMX or SSE instructions (these are special machine instructions to make certain operations faster) 2 - Oddly, or perhaps not so oddly, it is programmable from the Arduino IDE out of the box. I personally think its weird to treat an x86-class proc like an 8-bit micro, but that's just me. Like most other Embedded Linux dev boards on the market, it boots from an SD ca