Skip To Main Content

JavaScript: Verifying Analog Write on Intel Galileo

Posted by Rick Waldron

Jun 03 2014

Previously: On-Board: Intel Galileo Programming with JavaScript and Node.js


When working with emerging platforms, it’s common to find yourself in a position where the platform itself requires some form of testing or validation. Often, it’s not clear how to execute these sort of validations. Thankfully, when the platform’s hardware and software is completely open, the probability for sucess is much higher than it would be in closed systems. This article covers one of many processes that can be used in triage reports for such systems.

Recently a bug was filed for the Galileo-IO project that reported issues with writing analog (unsigned, 8-bit) values to digital pins. There was a corresponding thread on Intel’s Community site that included a code example. The first step was to clean up the test case and reduce it. In the process of reduction, I identified and eliminated a piece of code that was being used as a delay mechanism, replacing it with async-friendly interval. This change alone corrected the reported unreliable voltage reading issue: the process-blocking delay function had been preventing the async fs operations from occuring when they were expected.

The process blocking delay prevented fs GPIO writes from executing as expected.

A follow up message confirmed that the analog write operations were now occurring when expected, but the colors appeared dimly lit. In order to verify the correctness of the GPIO signal, I created four different RGB Led controller validation tests, plus three miscellaneous RGB Led tests.

The four primary tests were against the following hardware units:

  • Diffused RGB Led, Common Anode, 10mm
  • Diffused RGB Led, Common Anode, 5mm
  • Clear RGB Led, Common Cathode, 10mm
  • Clear RGB Led, Common Cathode, 5mm

The forward voltage is the same for all four units:

  • R: 2.0V
  • G: 3.2V
  • B: 3.2V

Each test was completed both with and without resistance:

  • R: 180Ω
  • G: 100Ω
  • B: 100Ω

The three miscellaneous RGB Led tests:

  • Clear RGB Led, Common Cathode Breakout board
  • SMD RGB Led, Breakout
  • Three Common Cathode Led array

Here’s the validation program:

var argv = require("yargs").default({ anode: false }).argv;
var Galileo = require("galileo-io");
var board = new Galileo();
var pins = {
  red: 11,
  green: 10,
  blue: 9
};
var names = Object.keys(pins);

// if --anode=false is passed, it will appear
// to be "truthy"
argv.anode = argv.anode === "true";

board.on("ready", function() {
  console.log( "CONNECTED" );

  this.pinMode(pins.red, this.MODES.OUTPUT);
  this.pinMode(pins.green, this.MODES.OUTPUT);
  this.pinMode(pins.blue, this.MODES.OUTPUT);

  var colors = [
    [0xff, 0x00, 0x00], // red hex code:   ff0000
    [0x00, 0xff, 0x00], // green hex code: 00ff00
    [0x00, 0x00, 0xff], // blue hex code:  0000ff
  ];

  var color = 0;

  setInterval(function() {
    setColor(colors[color], names[color]);
    color++;
    if (color === colors.length) {
      color = 0;
    }
  }, 500);
});

function setColor(rgb, name) {
  rgb = rgb.map(function(eightbit) {
    return argv.anode ? eightbit ^ 0xff : eightbit;
  });

  board.analogWrite(pins.red, rgb[0]);
  board.analogWrite(pins.green, rgb[1]);
  board.analogWrite(pins.blue, rgb[2]);

  console.log("Set to: %s ", name, rgb);
}

All eight test runs produced the expected results:

  • Red 500ms
  • Green 500ms
  • Blue 500ms
  • (Repeat)

A version of the tests that slowed the operation to 5000ms was executed for each, which allowed me to manually verify the actual value set to the GPIO path by executing the following from a second terminal:

cat /sys/class/gpio/gpio25/value;
cat /sys/class/gpio/gpio16/value;
cat /sys/class/gpio/gpio19/value;

Note that 25, 16, and 19 correspond to 11, 10, and 9 as Red, Green, Blue respectively.

The following videos are a selection of the validation tests as they are executing.

Clear RGB Led, Cathode, 5mm

Three Anode Leds, 5mm

SMD RGB Led, Breakout

In this case, the source of the bug report was actually a user error. The time and energy spent investigating and verifying correct behavior could definitely be frustrating for some people; after all, it resulted in no improvements to the shared open source code. But it’s important to remember this is always a possibility when triaging open source projects, and to appreciate the less tangible benefits. In this case, I

  • helped a developer learn more about Node.js
  • verified the correctness of an edge case in the platform (as the validation test results and video evidence shows, writing 8-bit analog values to the Galileo’s GPIO system works as expected)
  • re-inforced my own understanding of best practices in Node.js (it’s important to always abide by Node’s implicit async behavior)
  • identified a common workflow and shared it in a blog post!

Comments

We moved off of Disqus for data privacy and consent concerns, and are currently searching for a new commenting tool.

Contact Us

We'd love to hear from you. Get in touch!