Board and pin mapping support

[iamdustan]

There are a few interesting properties that Firmata supports and we have a few ways to support these.

I’m currently exploring the API tradeoffs (external and internal) with the following two options.

import React from '../';

const {
  ArduinoUno,
  Button,
  Led,
} = React;

class Application extends React.Component {
  render(): ReactElement {
    return (
      <ArduinoUno port="/dev/tty.usbmodem1411">
        <Button pin={2}
          onChange={this.toggle} onDown={this.log}
          onUp={this.log} onHold={this.log}
          />
        <Led pin={9} value={this.state.value} />
      </ArduinoUno>
    );
  }
}

React.render(<Application value={HIGH} />);

import React from '../';

const {
  Board,
  Button,
  Led,
} = React;

class Application extends React.Component {
  render(): ReactElement {
    return (
      <Board type="ArduinoUno" port="/dev/tty.usbmodem1411">
        <Button pin={2}
          onChange={this.toggle} onDown={this.log}
          onUp={this.log} onHold={this.log}
          />
        <Led pin={9} value={this.state.value} />
      </Board>
    );
  }
}

React.render(<Application value={HIGH} />);

Both intend to provide a friendly mapping from the boards visual port numbers to what is required to interface with node-firmata. E.g. on an Arduino Uno the analog pins [A0...A5] are pins 14-19 (maybe +1 to those) on the reported pin array.

By supporting this we can begin to provide developer warnings when attempting to set pins to values or modes that they do not support.

Thoughts?

[qwertypants]

I like ArduinoUno as a property; it reads clearer, while making <Board> generic enough to extend.

[iamdustan]

Fwiw, the current ArduinoUno implementation is just a Board with a pinMapping property.

[aliv1]

Is having the ArduinoUno prop limiting in any way? Could Board present
more options now and/or in the future?

On Tue, Jul 14, 2015 at 1:58 PM, Dustan Kasten notifications@github.com
wrote:

Fwiw, the current ArduinoUno implementation is just a Board with a
pinMapping property.

—
Reply to this email directly or view it on GitHub
#2 (comment)
.

[blainekasten]

Also agreeing with the use of Board. What if I want to use this with a Beagleboard?

[iamdustan]

I wrote the initial issue in too much haste (as I am doing with this response as well).

Board is not going away. ArduinoUno and other board types would just be preconfigured Boards. The current ArduinoUno implementation is the following:

https://gist.github.com/iamdustan/14ba3b907d92c5f0d027

This means it has all the capabilities of a Board but allows it to be preconfigured with certain properties. It also theoretically would make supporting a Beagleboard something that can happen in userland and not in core. In this approach there can be something like npm install react-hardware-beaglebone to get the Beaglebone component and dependencies.

I’ll write up an implementation of the <Board type="ArduinoUno" ... /> later to show the alternative approach.