[WIP] support for HT1632C LED control

[ericandrewlewis]

This is a work in progress PR for #1000. More or less a JS port of Adafruit's HT1632C library.

Feedback welcome 😄 More soon.

[rwaldron]

For all occurrences, just use dot access: this.pins["write"] => this.pins.write

[ericandrewlewis]

Thanks for the feedback @rwaldron, I've fixed up accordingly.

Most API functionality has parity with the other matrices.

Here's some example code that would work with an HT1632C, hooked up the same way as in this tutorial:

var five = require("johnny-five");

var board = new five.Board();

board.on("ready", function() {
  var matrix = new five.Led.Matrix({
    controller: "HT1632C",
    pins: {
      data: 2,
      write: 3,
      cs: 4
    },
    devices: 1,
    dims: {
      rows: 16,
      columns: 24
    }
  });

  matrix.led( 0, 0, true );
  matrix.led( 15, 23, true );
  matrix.writeDisplay();
  matrix.blink();
  matrix.brightness(0);
  // Maximum brightness.
  matrix.brightness(15);


  matrix.draw( "hi" );

  matrix.brightness(0);
  matrix.writeDisplay();
});

Some open questions:

Writing to the display seems expensive at the moment, so I've disabled led() from calling it directly at the moment. Might have to take a look at the C++ library again for optimizations if any are possible. For now, writeDisplay() must be called explicitly after led().

How would one expect draw() to work with this display? Passing in an array of row data makes sense. But what about passing in characters, since this display has space for 6 characters?

The HT16K33 supports bicolor displays. Are there bicolor HT1632C matrices?

The HT16K33 supports rotation. Should the HT1632C do this as well?

Any other feedback appreciated.

[rwaldron]

For now, writeDisplay() must be called explicitly after led().

This is a semantic deviation that definitely needs to be resolved, but I have a feeling that won't be possible considering...

Writing to the display seems expensive at the moment,

Based on the communication protocol requirements, I assumed it would be. It's not much different from the MAX7219 and MAX722 devices, which are written using shiftOut (which is also expensive, though not quite as much)

How would one expect draw() to work with this display? Passing in an array of row data makes sense. But what about passing in characters, since this display has space for 6 characters?

I honestly have no idea. This display breaks a lot of assumptions made by existing LED matrix component controller implementations—that Johnny-Five just followed because that seemed to be a smart thing to do. Part of me wishes Johnny-Five could offload some of this stuff into plugins like the totally excellent node-pixel, but that ship has probably sailed :\

Let's gather some other brains that have worked on plugin stuff and/or led component stuff...

@ajfisher @Frxnz @boneskull

The thing I'd like to think about and discuss: building a set of LED component (digit, matrix, bar graph) classes as a plugin similar to node-pixel. I think this would be a way to expand the capabilities in a smart way and most importantly starting clean. @dtex and @BrianGenisio are brilliant at identifying capability intersection.

[boneskull]

what was the other issue I was talking about this in? Had something to do with bar graphs...

[boneskull]

I think it's worth mentioning that due to the nature of these displays, an inheritance model might be inappropriate. If we define individual capabilities such as "bi-color" or "matrix" and compose resulting objects that way, we won't fall into the trap of trying to classify hardware too hard or violate assumptions.

I'm not sure a pairing of a public API and a controller object makes much sense though. You can't necessarily use any combination. Maybe the public API should be hardware-specific. I know this goes contrary to much of j5's API but it's worth discussing. The current abstraction for these displays leaks everywhere....

[boneskull]

(that ticket was #665)

[boneskull]

also, please let me know if the above comment(s) didn't make sense; I wrote them while half-awake

[ericandrewlewis]

#665 is a nice read :)

We could do a refactor there. After that adding support here should be nominal. (Famous last words...)

I'm going to leave this open for now and see if I can help out on that ticket.

[dtex]

Hi @ericandrewlewis ,

Since this has been open and on hold for a while I'm closing. Rather than leave it languishing as an open PR we have created a Requested Features page and I have added your request for the HT1632C there with links to this PR and the relevant issue.