Added 4x4 Matrix Class

[sommersoft]

Added a 4x4 matrix class. intended use is currently for Adafruit Trellis board (PID: 1616), but can obviously be used beyond. I've only included a single matrix at this time. Can work on extras later (4x4x2, 4x4x4).

Trellis link: https://www.adafruit.com/product/1616

[sommersoft]

Pausing PR. Needs additional edits to ht16k33.py since the setter uses a bitmask of 8. Doesn't work for a 4x4 matrix. Matrix4x4 was written using a Trellis matrix that I believe has a burnt out HT16K33 (crossed +/-), but getting the same results on a brand new board. I may also tackle Issue #2, since I'll be in the file anyway.

[sommersoft]

So, after breaking code, reading results, scratching my head, and repeating...this PR will stay closed. A Matrix4x4 will not work for the Trellis, based on how it is designed/uses registers; unless a hardcoded Trellis matrix is put in. Which I guess is an option...

[tannewt]

Please reopen when you've come up with a solution!

[sommersoft]

SOLICITATION FOR COMMENTS ON INCORPORATING TRELLIS LIBRARY

Background
While the Trellis board uses the HT16K33 chip to handle LEDs and Buttons, the Trellis' design uses a specific HT16K33 pin utilization that doesn't work with the current adafruit_ht16k33/matrix.py classes. Ladyada's Arduino Trellis library shows the difference software-wise, with its use of a lookup table for LED/Button "addresses".

I have ported the Arduino library's functioning, while using the CircuitPython HT16K33 library's structure. I've currently got the LEDs working for a single board. Before I get much further (and put up useless PRs like this one :D), I'd like to ask you all your thoughts on either keeping the Trellis library completely standalone, or combining/utilizing the existing HT16K33 library. Note that simple utilization of HT16K33 library will involve changes/additions to it. As the code stands now, I should be able to plug-n-play. Here is a gist for what I have (working copy).

Below are the Pros & Cons I've considered for combining/interfacing with the HT16K33 library. While one section may outnumber the other, weight of the individual items is also a factor.

Pros

• Uses existing functions/doesn't duplicate code
• Can be bundled inside the one library; one-stop-shop for HT16K33 (see Cons on same point)
• Management remains in one repo

Cons

• Would be bundled with the whole HT16K33 library; might cause capacity problems for the non-Express boards. Especially with code required for running multiple boards.
• May overly complicate setting up a Trellis matrix (like an UNTZtrument)
  • 8x Trellis (max) = 16x8 matrix with 8x i2c addresses; current library only allows for 1x i2c address (e.g. adafruit_ht16k33.matrix.py has 16x8 class, but only uses one i2c address).
  • The multiple layers may cause a speed decrease with interaction (I know, speed is subordinate).
• Button handling is not currently part of the HT16K33 library, and I can't think of any use outside of the Trellis (Adafruit product-wise; it would allow roll-your-own support otherwise)
• Being "buried" in the HT16K33 library may make it difficult for people to find

Leave comments here, on my gist, or in discord. I appreciate your time. And, thanks to Ladyada, Radomir, and Tony for their previous work on both of these libraries.

[deshipu]

I think it totally makes sense to make it a separate library. Code reuse is overrated, especially for such simple chips as the HT16K33.

[jerryneedell]

I agree with @deshipu . Unless it is very likely that users will be using the Trellis and other HT16K33 devices at the same time, I see no compelling reason to combine them.

[caternuson]

I vote separate library also. If you need to re-write the HT16K33 class so that is more useful for your Trellis class, then you can do so in your library.

[kattni]

I agree that a separate library makes more sense. It'll give you more freedom to do what makes the most sense for the Trellis library and keep the code more efficient for general use of the HT16K33 lib.

[tannewt]

I'm ok with a separate library but wanted to point out that you could have it as a separate module (aka file) in this package and only cause the extra code to load as needed.

@sommersoft do you have an idea on which direction you want to go?

[sommersoft]

well, first of all... THANK YOU ALL for your thoughts and comments!

I was leaning separate before I posted the solicitation, and tried to keep my bias out of it.

@tannewt honestly, I think standalone, or standalone inside this repo are about the same. The only issue I can think of is having the specific Trellis library "buried". But, it wouldn't be too different than say the featherwing and rgb-display libraries. In the end, I'm more than happy leaving the decision to Adafruit (you, Dan, etc)...I'm just the codemonkey. 😄

I'm done with the code part, working on final doc strings (and leaning forward on the new RTD setup). The lib is setup as a standalone, and I have it broken into 2 modules (which is different than the Arduino/Python versions); base & matrix. The thought process is that you could use a single Trellis & base class by itself without the extra matrix code to save storage space. Or bring in the matrix class & multiple boards if you want to. Without doc strings, they're 5KB & 4KB respectively, so it's not a huge savings...but, on a non-express every byte counts, right?

[tannewt]

That sounds awesome @sommersoft. I'd be happy to make a repo for you to PR to once you are ready. Should we call it Adafruit_CircuitPython_Trellis perhaps?

…

On Tue, Jan 30, 2018 at 8:58 PM sommersoft ***@***.***> wrote: well, first of all... *THANK YOU ALL* for your thoughts and comments! I was leaning separate before I posted the solicitation, and *tried* to keep my bias out of it. @tannewt <https://github.com/tannewt> honestly, I think standalone, or standalone inside this repo are about the same. The only issue I can think of is having the specific Trellis library "buried". But, it wouldn't be too different than say the featherwing and rgb-display libraries. In the end, I'm more than happy leaving the decision to Adafruit (you, Dan, etc)...I'm just the codemonkey. 😄 I'm done with the code part, working on final doc strings (and leaning forward on the new RTD setup). The lib is setup as a standalone, and I have it broken into 2 modules (which is different than the Arduino/Python versions); base & matrix. The thought process is that you could use a single Trellis & base class by itself without the extra matrix code to save storage space. Or bring in the matrix class & multiple boards if you want to. Without doc strings, they're 5KB & 4KB respectively, so it's not a huge savings...but, on a non-express every byte counts, right? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADNqbh420c4sKB2fhTwmnm4XoUbefxCks5tP_LbgaJpZM4RqiIv> .

[sommersoft]

Adafruit_CircuitPython_Trellis sounds good to me.

[tannewt]

Repo created: https://github.com/adafruit/Adafruit_CircuitPython_Trellis Please PR to it when you are ready.

…

On Wed, Jan 31, 2018 at 8:33 AM sommersoft ***@***.***> wrote: Adafruit_CircuitPython_Trellis sounds good to me. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AADNqWiN1pbF0PSWrnhfHbgZ-bYDphZvks5tQJXzgaJpZM4RqiIv> .