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!

Technology Alternatives - Summary, Conclusion, Recommendation

This post is part of a thread titled "What Technology to Choose for a Physical Interface Project"

Summary, Conclusion, Recommendation

The following two charts provide a summary of my conclusions after an initial period of "hands-on" evaluation.

 

My conclusions, in narrative form, were summed up as follows:

• Cost does not seem to be a huge issue given that all of the solutions are close in terms of required investment.
• Customer requirements that demand a high degree of computation for analysis could make the single-board computer alternatives attractive given the limited memory available on the Arduino boards.
• The Arduino Mega would be the recommended choice if an Arduino were to be used given it has much more memory than the Uno. 
• The Arduino provides the most simple hardware solution though it’s reliance on “C” as a development language, and without an IDE as good as the BeagleBone Black, adds complexity on the software side.
• The Raspberry Pi, with an Arduino, provides a very flexible solution but at the cost of complexity with two hardware environments and two languages.
• The Raspberry Pi, with an ADC, was a bit more challenging to integrate than was expected though in most other respects it has been easy to work with to date..
• The BeagleBone Black could provide the best overall solution from a hardware and software complexity perspective though it’s user community does not seem as strong as that of the Raspberry Pi.
• At this point in the investigation I would recommend the Arduino Mega with an external ADC or the BeagleBone Black.   
• While the BeagleBone Black merits further investigation, particularly around the user interface, it has been very impressive to date:
• Combines features of Raspberry Pi and Arduino in one package,
• Includes 12bit resolution on board with a high sample rate,
• Looks and feels more “industrial strength” than the Raspberry Pi (and is faster),
• Provides a very user friendly development environment with some characteristics similar to Visual Basic,
• Allows for easy porting of code from Arduino given language similarities.

 Final decision was to pursue a BeagleBone Black solution.

Technology Alternative - BeagleBone Black

This post is part of a thread titled "What Technology to Choose for a Physical Interface Project"

BeagleBone Black

• BeagleBone Black Hardware (50):
• 1ghz ARM CPU
• 512mb of Memory
• Storage on Flash Card or USB
• Graphics Accelerator and Floating Point Processor
• Initially developed by Texas Instruments in 2008.  Current device seems to have been released at an RPi competitive price point.
• RPi Software:
• Fully functional Linux implementation with Javascript as primary programming language (though Python is also supported).
• Javascript IDE supports interactive debugging and as such has some similarity to Visual Basic.
• Vast selection of software available to meet development requirements.
• Initial impression is that user community is not as strong as that of the RPi.
• Provides 12bit resolution for Analog to Digital conversion via onboard hardware.  Inputs must be below 1.8v.
• Supports several LCD displays as add-ons, called “capes”.

Notes:
(1) The breadboard provides a voltage divider that uses a variable resistor to deliver a variable voltage for simulating a test measurement.  It is also supporting a tri-colour LED as a status monitor while a test is running.
(2) LCD ‘cape’ shown is one of several options for a User Interface.

Technology Alternative - Raspberry Pi with External ADC

This post is part of a thread titled "What Technology to Choose for a Physical Interface Project"

Raspberry Pi with External ADC

• Raspberry Pi (Rpi) Hardware (50):
• 700mhz ARM CPU
• 512mb of Memory
• Storage on Flash Card or USB
• RPi Software:
• Fully functional Linux implementation with Python as primary programming language.
• Vast selection of software available to meet development requirements.
• Extremely strong user community for support
• External ADC chip integrated with the Raspberry Pi via I2C (a serial communications protocol)
• Provides up to 18bit resolution for Analog to Digital Conversion 
• Could provide user interface through one of several available LCD displays

The breadboard provides a voltage divider that uses a variable resistor to deliver a variable voltage for simulating a test measurement.  It is also supporting a tri-colour LED as a status monitor while a test is running. 

Technology Alternative - Hybrid = Arduino + Raspberry Pi

This post is part of a thread titled "What Technology to Choose for a Physical Interface Project"

Hybrid = Arduino + Raspberry Pi

• Raspberry Pi (Rpi) Hardware (50):
• 700mhz ARM CPU
• 512mb of Memory
• Storage on Flash Card or USB
• RPi Software:
• Fully functional Linux implementation with Python as primary programming language (though certainly not the only language supported).
• Vast selection of software available to meet development requirements.
• Extremely strong user community for support
• Does not have onboard Analog to Digital conversion and so needs another device for integration with physical devices.
• Arduino hardware would be per previous example (65)
• Very high sample rates (+/- 600/sec) possible with logging by Arduino to SD Card and then upload to Raspberry Pi.
• Could provide user interface through LCD integrated with the Arduino or by integrating an LCD with the RPi (the former being what is shown as I do not have an LCD on my RPi.

Notes:
(1) The breadboard provides a voltage divider that uses a variable resistor to deliver a variable voltage for simulating a test measurement.  It is also supporting a tri-colour LED as a status monitor while a test is running.
(2) LCD display has not been integrated with the Raspberry Pi as of this picture but is shown for illustrative purposes

Technology Alternative - Arduino Mega with LCD Touchscreen

This post is part of a thread titled "What Technology to Choose for a Physical Interface Project"

Arduino Mega with LCD Touchscreen

• Hardware:
• Arduino Mega 2560 (40),
• TFT LCD Shield (10),
• TFT LCD/Touchscreen Shield (15)
• Microprocessor:
• Flash Memory - 256KB of which 8 KB used by bootloader
• SRAM - 8 KB
• EEPROM - 4 KB
• Software:  Arduino sketches written in C++ and downloaded to the microprocessor from a workstation.
• Supports 10bit resolution for Analog to Digital Conversion (external adapter can be added for higher resolution).
• Capable of taking 250 fixed time slice samples per second (assuming no updates of the LCD during sampling).
• LEDs could be used for indicating status during a capture (blink each second).  Shown upper left in picture to the right.

The breadboard provides a voltage divider that uses a variable resistor to deliver a variable voltage for simulating a test measurement.  It is also supporting a tri-colour LED as a status monitor while a test is running.

Technology Alternative - Arduino Uno with Simple LCD Display

This post is part of a thread titled "What Technology to Choose for a Physical Interface Project"

Arduino Uno with Simple LCD Display

• Hardware:
• Arduino Uno (15),
• SD Card Shield (15),
• Screwpoint Adapters (10),
• LCD with Keypad Shield (10)
• Microprocessor:
• Flash Memory - 32 KB (ATmega328) of which 0.5 KB used by bootloader
• SRAM - 2 KB (ATmega328)
• EEPROM - 1 KB (ATmega328)
• Clock Speed - 16 MHz
• Software:  Arduino sketches written in C++ and downloaded to the microprocessor from a workstation.
• Supports 10bit resolution for Analog to Digital Conversion (external adapter can be added for higher resolution).
• SRAM limits board to taking 125 fixed time slice samples per second (assuming no updates of the LCD during sampling).
• LEDs could be used for indicating status during a capture (blink each second).

 

The breadboard provides a voltage divider that uses a variable resistor to deliver a variable voltage for simulating a test measurement.

What Technology to Choose for a Physical Interface Project?

High Level Project Requirement

Goal of the project will be to integrate a piece of test equipment with a user friendly and computationally capable front-end that can operate without being attached to a dedicated computer.   The host needs to capture observations from a single analog source (at a rate of between 100 and 200 obs/sec), provide real-time feedback, and save the captured data to be presented with some other analysis tools.

Obviously I had a fair amount of experience with the Arduino and with the Raspberry Pi but I also wanted to look at another single board computer.   A survey of the market led me to the BeagleBone Black.   Given this, the alternatives that were investigated on a hands-on basis were:

• Arduino - a single-board microcontroller designed to make the process of using electronics in multidisciplinary projects more accessible.
• Raspberry Pi - a credit-card-sized single-board computer developed in the UK by the Raspberry Pi Foundation
• Beaglebone Black - a low-power open-source hardware single-board computer produced by Texas Instruments in association with Digi-Key.

There are a variety of other technologies but these three represent what I feel to be the best of those other alternatives.

BeagleBone Black

The Raspberry Pi was definitely not the first single board computer nor the first in it's form factor of "credit card" size.   In fact the concept has been around for decades and the first credit card size computers for years.   What the Raspberry Pi has done is popularize the notion AND (presumably) drive down the costs of at least one other computer in this class, the BeagleBone Black.

The BeagleBone Black, shown below, is the latest offering from BeagleBoard and seems to be aimed straight at the Raspberry Pi price point.   Since I am interested in the physical interface side of computing I was very interested to see this computer seeming to merge an Arduino with an ARM processor based computer. 

I have only started to work with this device but on first blush I would say that it looks and feels like a more professional device than the Raspberry Pi.   It has a faster processor, though less capable graphics, and as I said, a full range of physical interface capabilities including on board, 12bit, Analog to Digital Conversion.

On the down side I would say that it is more complicated to get going...I am struggling a bit with their way or burning images, and, their user community is not as strong as I have come to be used to with the Raspberry Pi.   Lastly, they chose JavaScript as their primary development language.  JavaScript???  

More to come later including a comparison of the environments that I have been testing.