Add adafruit_bus_device dependency

[tekktrik]

I debated trying to incorporate adafruit_register as well in a few different ways, but none of the exist classes do exactly what the library needs it seems, so I left that aspect as is.

Also adds some minor documentations additions.

Resolves #49

[FoamyGuy]

Looks good to me. Tested successfully with Feather RP2040 and 15x7 Charliewing. using some of the scripts in examples directory of this repo. Thank you @tekktrik

[FoamyGuy]

Ah, didn't see that it has merge conflicts until after I submitted review. I see how extensive those are, perhaps I can add a commit to resolve them.

[tekktrik]

No worries, I merged the other so I should have checked this! I just merged main into the PR branch, wanna test it again to be safe?

[FoamyGuy]

I took a look at the conflicts but I don't quite understand enough of the communication occurring to resolve them properly. I took a try at it but the resulting library raises an error when I attempt to test it.

AttributeError: 'CharlieWing' object has no attribute 'i2c'

I think I did not correctly resolve the differences in this section:

@tekktrik or @PaintYourDragon can one of you take a look and see if you're able to tell how this section needs to be to resolve conflicts?

[FoamyGuy]

This function got changed by another recent PR and the changes will get need to get conflicts resolved with this one before it can get merged.

[tekktrik]

@FoamyGuy I should have just resolved the conflicts in the latest commit! For this, it's sufficient to just store self.i2c_device and use that in the other pertinent functions.

[tekktrik]

Aaaaaand there are some other problems with it haha, let me take a look

[FoamyGuy]

Current version raises this error:

code.py output:
Traceback (most recent call last):
  File "code.py", line 24, in <module>
  File "/lib/adafruit_is31fl3731/__init__.py", line 100, in __init__
  File "/lib/adafruit_is31fl3731/__init__.py", line 142, in _init
AttributeError: 'CharlieWing' object has no attribute '_i2c_write_block'

Thanks for looking into it. Feel free to ping me once it's ready for re-test.

[tekktrik]

So turns out I overwrote an update @PaintYourDragon made to use a function that DIDN'T utilize a register that I didn't realized was used in their update, so I added that back in. Shooooouuuld be good now, thanks for your patience!

[FoamyGuy]

@tekktrik I think there is still some kind of trouble unfortunately. With the latest version the simpletest script results in a very brief "static looking scramble" on the LEDs and then all shut off.

With current released library:

With latest version from PR:

led_matrix.mp4

When the LEDs change in the video is when I pasted the current version of library from this PR and it noticed the file change to trigger the reboot / re-run.

I'm guessing this is something related to timing or else something very foundational to the communication. I am getting different results when it runs if I try multiple times. The first few times the entire matrix showed a "static looking scramble" for a split second and then turned off. A few times it did what is depicted int he video (only a few corner LEDs turn on instead of the whole outter row). Also a few times I saw it turn on most of the outter row except for these two LEDs and then switch so that these two turned on and the rest turned off.

[tekktrik]

Got it, I'll look deeper at the merge and see if I borked anything. Thanks for following up!

[tekktrik]

@FoamyGuy yup I borked it. Good suggestion about communication - it was accidentally writing an extra \x00 when using _i2c_write_block().

[FoamyGuy]

Tested latest version successfully with example scripts from the repo and Feather RP2040 + 15x7 Charliewing

Thanks @tekktrik