Node.Js Async Processing Example

• The BeagleBone Black supports a number of development environments native to other linux platforms.  My original thought was to use Python but a closer look at Node.Js and Javascript convinced me to go in that direction.
• Node.js is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.
• Using Javascript on both the server and client will make development more consistent and will allow access to a realm of addons for graphing and other functions. 
• The “event-driven, non-blocking I/O model” mentioned of Node.Js does pose a bit of a challenge in terms of the structure of programs written for the node environment.
• The below diagram presents an example of how this works.
• Code written in this manner allows the node engine to focus on processing tasks that need attention rather than on those waiting for slower operations completing.
• It can lead to a plate of call back spaghetti  ... and has not been the easiest environment in which I have ever worked!

 

1. Function that sends the specified file of html to the client.
2. Asynchronous read of the file initiated here with two arguments – the file name to read and the function to call when the read has been completed.
3. Inline definition of the function mentioned above – the call back function named as such because it is called back when the read finishes.
4. (and 5.) In this example the message “sendForm ended” will appear on the console BEFORE the message “Form xxx Sent"

Sample code for my demo application can be found on GitHub.

Wiring the BBB for "The App"

Wiring the BBB for my application was pretty straight forward though the software side of the data collection proved to be a little less so.   

 

Integrating the Real Time Clock (RTC)

• The BeagleBone Black, like other single board computers, does not have an onboard clock with battery backup to preserve current date and time.  
• Theory of the case being that if the application needs one the date and time can be gotten from:
• The network via NTP, or
• An optional battery backed Real Time Clock.
• Since ‘The App’ is not a network attached device the latter alternative has been implemented.
• Luckily the BBB does come with the necessary hooks to easily integrate an RTC (assuming it is one of a list that is supported).
• The RTC is connected using I2C and powered from the BBB as shown in the previous diagram.
• Once it is connected the time on the BBB is set using NTP while it is connected to the network – ‘ntpdate -b -s -u pool.ntp.org’
• Once the BBB is running the correct time it can be downloaded to the RTC – ‘hwclock -f /dev/rtc1 –w’
• From that point the BBB can get the time from the RTC rather than the network – ‘hwclock -f /dev/rtc1 –s’
• It is not essential that the BBB support a real time clock for operation of ‘The App’, however, doing so will allow files to be date and time stamped.

Integrating the Analog Digital Convertor (ADC)

• The BBB has an onboard ADC, however, the entire ADC is allocated to the LCD cape!
• Given this I have integrated an off board ADC, one that was designed for the Raspberry Pi, but that works with anything that communicates via I2C.
• Wiring is shown by the preceding diagram and consists of five lines, two power, two for I2C, and a single line from our input source.
• One of the disadvantages with the onboard ADC was it’s operating range for input (-1.8 to +1.8v).  The Pi ADC operates from 0-5v which better suits our requirement.
• The bulk of the work of talking to an I2C device is done by a library installed via NPM – ‘npm install i2c’.  This library is available as part of Bonescript which ships with the BBB or as an install from npm per the above (which is what I am using since I don't have a need for the rest of Bonescript.
• The code to access the ADC is shown below with some comments.

Initialize the interface library	var i2c = require('i2c');
Setup the address and command for the ADC.  The command translates to 12 bit resolution, gain of 1, in continuous mode	var address = 0x6A; var command = 0x90;
Use the library loaded above to instantiate a new wire (I2C) interface	var wire = new i2c(address,     {device: '/dev/i2c-1', debug: false});
Setup an interval to capture observations.   5ms is as fast as we can go	intervalId = setInterval(function() {     observeCallback(); }, 5);
Here is the callback for the above interval.  This function actually calls on the I2C interface to get four bytes of data from the ADC	function observeCallback() {     wire.readBytes(command, 4, function(err, res) {         observe(res);     }); }
Within the observe function the two bytes of data that actually contain our reading are bit shifted into a measurement	function observe(buffer) {     var voltageIn = (buffer[0] << 8) + buffer[1];     voltageIn = (voltageIn / 2048) * 5.0;

There is a huge caveat on the above code.  Namely that when embedded within my application it will, at some point, cause a Segmentation Fault.  In a later post I will describe my solution to this rather fatal problem!

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.