Raspberry Pi vs BeagleBone Black - Expanding on a Review

Some time after I had evaluated the Raspberry Pi versus the BeagleBone Black I came across a really well done comparison of the two platforms by Michael Leonard.  It was originally posted on his blog here and then later it was re-posted to Make here.  There is nothing in the review that would have changed my recommendation, and there is little with which I disagree, but the following are points where my learnings over the past months augment Michael's review.

Unboxing

I had unboxed three Raspberry Pi's (RPi's) before I got my first  BeagleBone Black (BBB).   My first impression of the BBB was to be impressed by how much more professional it looks than the RPi.   Obviously this is a reflection of it being the latest in a family of devices.   I still like the look and feel of it better than the RPi which has a much more "hobbyist" look in my opinion.   I would give unboxing to the BeagleBone Black.  This is the only scoring difference that I would make in Michael's evaluation.

Ease of Setup

I strongly agree with Michael on the ease of initial setup with the BeagleBone Black but would caveat as follows.  There are probably a lot of applications that will never need to boot from the removable micro-SD card but I have one of them and this created some minor complexities similar to what one encounters with the RPi.   The ability to connect the BBB to a host computer using the included USB cable is a very nice feature and one that I am planning to use when the BBB is embedded in it's final home where it will not regularily be network attached.

Connections

Another caveat here could be important to someone wanting to use the BBB to talk to things via the built-in Analog Digital Convertor or AIN as called on the BBB:

• First, and most importantly, if your application is going to use an LCD cape you will not have physical access to the AIN pins, and, it won't matter as the LCD cape monopolizes the ADC chip so even if you had physical access to it...the AIN will still not work for you.
• Second, and this is minor compared to the above, the AIN being based on 1.7 volts is a pain in the butt!  Sure you can easily do a voltage divider to get your source, which is probably 5v, down to what the BBB needs, but it is a pain.  I have also read, but not verified myself, that the accuracy of the onboard AIN can be impacted by noise on the board.

My solution to the above was to implement an offboard ADC (the MCP3426) that communicates with the BBB via I2C.   Not only do I not have to do any voltage dividing but the device that I am using has the option of doing 12, 14, 16, or 18 bit accuracy (at reducing speeds).

This certainly does not change the BBB being a clear winner here as you would need an external ADC for the RPi in any case.

Graphical Showdown

I don't disagree with anything that Michael states here but I would give the BBB some points for the availability of three LCD capes of varying sizes at price points well below what I have found to be available for the RPi.   They integrate extremely easily, work well, and look great.  Yes, I know, credit for this is given in the expandability section.  Just sayin'

Expandability

I agree with the scoring on this area but not for the availability of the Arduino add on board (though I do think it is pretty cool).   I think the chances of needing an Arduino, if you have a BBB, are less than if you have an RPi but if you do need one to take advantage of a shield, there are lots of ways to connect said Arduino.   I would give the edge to the RPi simply because of the wide variety of accessories that have entered, or are entering, the market given the popularity of the RPi.   I think that some of the expansion boards for the BBB might be a little nicer, and in the case of the LCD, cheaper, than for the RPi but the size of the RPi ecosystem gives them an edge.

Community

The other areas where I agreed with Michael did not get a comment...but this one deserves a shout-out.  The community for the BeagleBone Black has been helpful but there just does not seem to be many folks out there.   On the other hand the RPi community is out there in droves and seem particularly happy to help with problems posted on their message boards.  I also greatly prefer the RPi forum which is based on phpbb rather than the Google Groups approach used by the BBB.

In any case, forum tools aside,  I hope that the dynamism of the BBB user community will improve over time as the BBB sells more units but for now it is, as Michael's review states, clearly a win for the Raspberry Pi.

Fragility

This is not something that Michael talked to but that I needed to add based on my experiences.   I will freely admit that this could be "just me".

You can fry any electronic device, and I am proof to this statement, but one of the strengths of the Arduino is it's ability to resist ham-fisted users like myself.

The Raspberry Pi is clearly more sensitive than the Arduino but I managed to fry one of them.  It turns out that it was a model that did not include the poly-fuses that newer boards now support.   On a later attempt to smoke another, newer RPi, the poly-fuse did it's thing and some hours later, when things cooled down, the RPi came back to life!

The BeagleBone Black, in my hands anyway, has been expensive.  Two of them have been into the Beagle Hospital and I am now a little gun shy.  I would strongly recommend that a high degree of caution be taken when working with a BBB connected to the external world.   Never connect and disconnect hardware with the power on (should probably go without saying)!   Never have the gear to which you are interfacing with powered on before the BBB (came as a little bit of a surprise)!

I am not a hardware guy, but, I can't help but wonder why the RPi would seemingly put poly-fuses to good use but they are not appropriate for the BBB (according to someone associated with the device)?   [Yes, I know, you can not protect against all forms of ham-fisted'ness but maybe against some would be nice.]

Conclusion

Interestingly, my original evaluation of the two boards leaned towards the BBB largely because of the lack of an ADC on the Raspberry Pi.  Learning that the ADC is not accessible when the LCD Cape is on the BBB defrayed that advantage but the quality of the LCD, and the integrated nature of the board and the LCD, have become the reason to continue my path to production on the BBB.

On the other hand, I have the code that I have written for the BeagleBone Black running pretty much seamlessly on the Raspberry Pi so if I needed to make a change I can do so.  This is a great testament to the open-source world within which both boards reside.  Cool eh?

Minimum Setup for a GitHub Software Repository

Previous projects have had me using subversion with SmartSvn as a GUI.  I had a server setup on my home network but wanted an external server but never got around to setting one up.   For this project I decided to go with GitHub.  It is, after all, the home of much open source software, is easy to use, is free for public repositories (and cheap for private ones), and has both graphical and command line utilities for the client.

Once you have setup your repository on GitHub the following commands will add your project to the new repository:

• touch README.me git init
• git add README.md
• git commit -m "First commit"
• git remote add origin https://github.com/ThamesWill/Physical-Interface-Demo
• git push -u origin master

Obviously replacing my name and project (ThamesWill and Physical-Interface-Demo) with your name and project!

Then to update your repository you do the following

• git add *.*
• git commit -m 'Initial adds'
• git push -u origin master

You will be asked for your GitHub username and password.  Once the push is complete you will see your code in the repository.   Subsequent pushes will result in the updates being change tracked so you can see what code changed when something goes boom in the night after an upgrade.

There are a lot of other features of both the local client and the remote repositories but the above are a minimum that I use to manage 'The App'.

Back with a (Big) New Project

There has been a period of silence over the past months as I had been given the opportunity to apply some of my new technical skills in the Computing Physical Interface space.   In particular a friend offered me the opportunity to build an instrument based on a single board computer with a physical interface to a piece of laboratory equipment.   No, there is not much danger of me making money here, and I have been interested enough in it to invest in a number of new pieces of kit, but this pro-bono project has 'def peaked my interest.

Over the coming weeks and months I will attempt to look back on the past several months to document some of my learnings.   I am going to backdate these posts to approximate when I actually might have gained the knowledge!

Prototype Hardware - BeagleBone Black and Raspberry Pi

Here are pictures of the hardware for the prototype of "The App" that I am building.  As you can see the BeagleBone Black is sporting an LCD while the Raspberry Pi is not.   On the other hand, the Raspberry Pi is decked out with a little joystick which the BeagleBone Black is missing.

The components that are shared by both computers are the:

• Real Time Clock (RTC)
• Analog Digital Converter (ADC)
• Variable Resistor

The wiring for RCT and ADC are discussed in an earlier post.    The variable resistor is part of a voltage dividing circuit that takes five volts and delivers a variable 0 to 2.5 volts as a simulation of the lab equipment 'The App' will talk to later.

The LCD display on the BeagleBone Black is the 3.5 inch cape (LCD3) from Circuitco.  It presents the Beaglebone Black's console in 320 by 240 pixels of resolution.  'The App' is presented by Chromium running in full screen kiosk mode and looks very sharp.

The 5v power supply from the Raspberry Pi is used for the simulated instrument while an external power supply is used in the case of the BeagleBone Black as it delivers a more stable voltage.

Finally, the Raspberry Pi has a joystick attached as a possible option for user input.  It is attached to the ADC with two outputs delivering a voltage from -2.5 to +2.5 representing each of the two axis.   In addition there is a line to a GPIO pin, attached to a pull down resistor, to register a click.

Using the uSD on BeagleBone Black as Aux Storage

I followed some instructions, that I have since lost track of, to enable the use of the uSD card on the BBB for auxilary storage when booting from the internal eMMC.   The below are my version of what was needed:

Format the drive

Add a partition and make it of type FAT, name it and size it however you want

After it has been formatted and partitioned mount the FAT 32 partition you just made

Create the document "uEnv.txt" in the root of the partition and add the following lines to it:

mmcdev=1

bootpart=1:2

mmcroot=/dev/mmcblk1p2 ro

optargs=quiet

This should do it.

Chromium Full Screen

My application is intended to be completely embedded in a laboratory apparatus presenting a captive user interface on the LCD Cape which is running as the console to the device.  The BBB provides a choice of several browsers but I have chosen Chromium as the front-end for my application.

Here is the command line argument that starts Chromium with it pointed to my application running under Node.js.    The two command line switches ensure that Chromium is started in full screen mode without any of the browser elements such as an address bar, and, that we don't get any extraneous messages (the exports are needed for that purpose) when pages are loaded from my application:

export GOOGLE_API_KEY=AIzaSyCcjKzcifha1m8P4RVxytpVsx3wNDIEHsY
export GOOGLE_DEFAULT_CLIENT_ID=985919302268.apps.googleusercontent.com
export GOOGLE_DEFAULT_CLIENT_SECRET=vQKKl73QQk8_dgEF44vNTHmJ
google-chrome --kiosk --incognito  localhost:7000 &

The above is run from .profile with the user automatically logging in when the 'X' session starts on the console.   I also start my application under Node.js at the same time.

Software Development on the BeagleBone Black

My original thought was to develop on the BeagleBone Black using Python as I had done on the Raspberry Pi.   Once I started to explore the BBB I was both intrigued and worried by the idea of using Node.Js and JavaScript instead.

Intrigued because I really liked the idea of building an application with the front-end presented via a browser.   Also intrigued because of Node's reputation for performance.   A little worried because I just have not thought of JavaScript as anything more than a client-side scripting language.   Also a little worried because the foundation of Node.js lies in it's asynchronous, non-blocking, architecture.

Once I got started slinging some code I did come to the conclusion that I was right about the good things and was overly worried about the bad.   This said, the async nature of the Node.js model does give me headaches.   Below is a narrative that presents some of the key processing flow for the app that I am developing:

“The App” modules “main” and “form” integrate with the Node.js to provide a web server as described by the example on this page.  This is somewhat different than most development environments where handling of the web interface is more abstracted from the application code!

1.  “The App” is launched at startup with main running and a “/” is fired from the browser running on the LCD display as console.
2. “main”  is monitoring the http port and sees the “/”. It invokes form.send to put the main.html form out to the client.
3. When the user presses the “Start” button main sees it and invokes form.receive to handle the page.  The call to form.receive is made with a callback given that receiving a form is asynchronous.
4. form.receive does inspects the return from the client to see if the button pressed on the received page is asking for a new page (versus some other action).
5. In this case the button press indicates that we need to start a test so the appropriate html file is sent to the client using form.send and the callback is completed after populating global.context with the name of the page sent and with the button pressed on the client.
6. Main then receives that callback, sees that we want to start a test, loads the test module, and calls test.execute.
7. test.execute starts running and does a setInterval to begin collecting our observations.
8. setInterval fires as often as it can calling test.observe to do our data collection.

I will freely admit that I have not done the above in the best "Node" manner but I struggled to find some good examples from which to learn.  By good I mean, easy to understand and doing what I wanted to do!   This being to develop a pretty straight forward interactive web based application.

What I have built seems to work well but I am sure that I could have done it better!