Terminal 28

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

Hey all, Been a while since my last post. I'm currently embarking on a one-year compulsory Youth Service program, which for academic purposes means I'm going to be serving my country (Nigeria) for one year by working in an organization. Its formally called the National Youth Service Corps (NYSC) and it begins with a three-week orientation course in the state one has been posted to. The orientation camp was really fun. Met some really amazing people..(I'm thinking of you as I write this, B...) *ahem* Shortly after the formal end of the orientation camp I returned home, and some time later I saw the announcement for the Raspberry Pi Zero (which for those who don't know is a single-board computer sporting an ARMv6/ARM11 SoC running at 1GHz with 512MB of RAM, no network options by default and one microUSB host port....for $5..yes, five US dollars). Naturally I was intrigued - I mean, its not exactly monster hardware, but the cost is certainly compelling. Sadly it was sol

[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

Hello all, Been a while. I know I say this all the time, but I really will try to post more stuff with more regularity as well. Thus, I've returned with this comeback post! *evil laugh* A couple of months ago, I stumbled on IteadStudio's Nextion IndieGoGo campaign. Their pitch was simple: we all know how much of a pain it is getting GUIs onto embedded systems in a reasonably-priced and sensible manner, so we've come up with our Nextion HMI (human machine interface). I was intrigued by the idea and paid for one of the cheaper perks. I received the screen two or three months ago but hadn't really gotten round to examining it properly, not until a few days ago. Essentially, the Nextion line is a series of resistive touch-capable TFT screens bundled with a UI development environment, making it possible to design flexible UIs on your computer, then deploy them to the screen itself over a simple serial connection (to clarify, you'll need a USB to Serial adapter to co