dtex

var Board = require("./board");
var Expander = require("./expander.js");
var EVS = require("./evshield");
var __ = require("./fn");
var events = require("events");
var util = require("util");
var Collection = require("./mixins/collection");
var Sensor = require("./sensor");
var ShiftRegister = require("./shiftregister");

dtex

const {Board, GPS} = require("../lib/johnny-five.js");
const board = new Board();

board.on("ready", function() {

  /*
   * This is the simplest initialization
   * We assume SW_SERIAL0 for the port
   */
  const gps = new GPS({

dtex

On Buckets & Chunks

Buckets in the Past

Before responsive websites, buckets were used to divide a page into sections. A typical design might have a Header bucket, an Inline bucket, a Sidebar bucket, and a Footer bucket. Each bucket could have any number of chunks and those chunks could be resequenced within the bucket or moved to another bucket.

The chunks in a bucket were output with a call to the built-in bucket-handler template and could be one of three types. A text/html chunk, an client or server script (any one of several media types), or a server-side include.

There is a separate template for each of the three chunk types in the xsl-library/presentation folder.

If you needed custom HTML around each chunk you could leverage the bucket-handler's $before, $after, and $wrapper params. These were ugly and pretty limited and they assumed that every chunk in the bucket would have the same HTML before and after. Without these params chunks just had their body barfed into the bucket 🤮.

dtex

TC-53 Terms

[ ] Application (Apps for things)	[ ] IOCP (The I/O Class Pattern)	[ ] Pre-Bound
[ ] Built-in	[ ] ISO/IEC JTC1/SC6	[ ] Protocol
[ ] Data Accuracy	[ ] I/O Class Pattern	[ ] Provider
[ ] Data Provenance	[ ] JSR 287	[ ] Remote Code Execution
[ ] Data Timeliness	[ ] Low-level API (Words to avoid)	[ ] Sleepability
[ ] Data Trustworthiness	[ ] Maximally minimal	[ ] Specialized Object Interface
[ ] Division of concerns	[ ] Meta-operations	[ ] Third-Party Libraries

dtex

Built-in vs. External providers

There are advantages to the proposed external provider pattern that the built-in pattern does not enjoy. The external provider allows for:

• Configuration on instantiation - Everything in node land needs configuration on instantiation, and I imagine there are devices where "builtin" would be the assumed pattern, but also need to be configured (i.e. wi-fi or oscillator settings)
• Capability checks by pin - A pin map in the provider instance, which could be an object or a tiny, 1 byte-per-pin array, can describe what each pin is capable of so users don't ask a pin to do something it can't (i.e. Perhaps not all pins will have a timer for PWM)
• Pin management - With a provider instance, it is simple to track and guard against things like using a single pin twice

An implementor may simply choose to use the external provider pattern if they have any of those needs, but conversely we could simplify things by not having the built-in pattern at all. Simple is good.

dtex

If your frame data is: [blah, blah, blah] send [blah, blah, blah, end]

If your frame data is: [blah, esc, blah] send [blah, esc, esc-esc, blah, end]

dtex

const five = require("johnny-five");
const board = new five.Board();
const REGISTER = require("./node_modules/johnny-five/lib/definitions/mpr121.js");
const Fn = require("./node_modules/johnny-five/lib/fn.js");

const scale = Fn.scale;
const toFixed = Fn.toFixed;

board.on("ready", function() {
  

dtex

WTF is firmata?

When I was first exposed to firmata I was confused by all the different parts and the scope of the ecosystem. Here is a breakdown for others who are curious but don't want to go researching:

firmata - A sketch for Arduino compatible devices. firmata is a simple client that executes basic GPIO commands on behalf of a host server. By default, the commands are received over serial. There are many versions of firmata and even a "configurator" over at http://firmatabuilder.com/ for building custom versions of the sketch. These custom versions may be optimized for certain devices whose inclusion would make firmata too big for low memory situations (ping, stepper) or they may provide other transport mechanisms for receiving commands from the host server (wifi, BLE).

dtex

  board.on("ready", () => {

    board.io.accelStepperConfig({
      deviceNum: 0,
      type: board.STEPPER.TYPE.FOUR_WIRE,
      motorPin1: 5,
      motorPin2: 6,
      motorPin3: 7,
      motorPin4: 8,
      stepSize: board.STEPPER.STEP_SIZE.WHOLE

dtex

let temporal = require("./../lib/temporal.js");

let hrTime = function() {
  let hrtime = process.hrtime();
  return Math.floor((hrtime[0] * 1e9 + hrtime[1]));
};

function standardDeviation(values){
  var avg = average(values);