adafruit / adafruit_circuitpython_is31fl3731 Goto Github PK

There are missing type annotations for some functions in this library.

The typing module does not exist on CircuitPython devices so the import needs to be wrapped in try/except to catch the error for missing import. There is an example of how that is done here:

try:
    from typing import List, Tuple
except ImportError:
    pass

Once imported the typing annotations for the argument type(s), and return type(s) can be added to the function signature. Here is an example of a function that has had this done already:

def wrap_text_to_pixels(
    string: str, max_width: int, font=None, indent0: str = "", indent1: str = ""
) -> List[str]:

If you are new to Git or Github we have a guide about contributing to our projects here: https://learn.adafruit.com/contribute-to-circuitpython-with-git-and-github

There is also a guide that covers our CI utilities and how to run them locally to ensure they will pass in Github Actions here: https://learn.adafruit.com/creating-and-sharing-a-circuitpython-library/check-your-code In particular the pages: Sharing docs on ReadTheDocs and Check your code with pre-commit contain the tools to install and commands to run locally to run the checks.

If you are attempting to resolve this issue and need help, you can post a comment on this issue and tag both @FoamyGuy and @kattni or reach out to us on Discord: https://adafru.it/discord in the #circuitpython-dev channel.

The following locations are reported by mypy to be missing type annotations:

• adafruit_is31fl3731/__init__.py:95
• adafruit_is31fl3731/__init__.py:101
• adafruit_is31fl3731/__init__.py:114
• adafruit_is31fl3731/__init__.py:127
• adafruit_is31fl3731/__init__.py:134
• adafruit_is31fl3731/__init__.py:142
• adafruit_is31fl3731/__init__.py:163
• adafruit_is31fl3731/__init__.py:171
• adafruit_is31fl3731/__init__.py:193
• adafruit_is31fl3731/__init__.py:221
• adafruit_is31fl3731/__init__.py:237
• adafruit_is31fl3731/__init__.py:241
• adafruit_is31fl3731/__init__.py:260
• adafruit_is31fl3731/__init__.py:273
• adafruit_is31fl3731/__init__.py:303
• adafruit_is31fl3731/__init__.py:308
• adafruit_is31fl3731/__init__.py:343
• adafruit_is31fl3731/scroll_phat_hd.py:40
• adafruit_is31fl3731/rgbmatrix5x5.py:44
• adafruit_is31fl3731/rgbmatrix5x5.py:64
• adafruit_is31fl3731/matrix_11x7.py:39
• adafruit_is31fl3731/matrix_11x7.py:43
• adafruit_is31fl3731/matrix.py:40
• adafruit_is31fl3731/led_shim.py:39
• adafruit_is31fl3731/led_shim.py:43
• adafruit_is31fl3731/led_shim.py:63
• adafruit_is31fl3731/keybow2040.py:42
• adafruit_is31fl3731/keybow2040.py:65
• adafruit_is31fl3731/charlie_wing.py:40
• adafruit_is31fl3731/charlie_bonnet.py:41

Recent attempt to reuse the Led Shim with the Pico failed on me with all kind of I2C related message.
It could be related to some issue with the RP2040 or by problem with the Pull-Up resistor.
I need rebuild the initial setup to test this with another MCU and another adaptor (Feather 2 Pi) to clear this issue.

Please close this with a comment if you successfully tested that on the hardware.

Also get examples highlighted as Python

The example code for the charlieplexed leds with 0-255 PWM brightness are not corrected for human perception of lightness.

Consider adding that when relevant. In my CharlieWing experience, it makes an antialiased font display such as in the pillow_marquee.py animation easier to read. It may also give that animated gif more definition.

I was about to drop the little code snippet from my project notebook to do that here... but told myself "this really belongs in a common library" as it is useful for LED control of any form. Which at 11pm led me down a Python packaging rabbit hole (note to self: do not do that at 1am). Thankfully, I finally made it out the other side after a night's sleep! Here you go: https://github.com/gpshead/pwm_lightness aka https://pypi.org/project/pwm-lightness/.

That might go further than you want to explain within a tutorial. But I do think people would find it useful. Up to you!

The board specific wrappers should live in separate files from the core class so that other boards' code isn't loaded into memory. They could even live in separate product level libraries (aka repos) instead of this one which should be IC level.

I am using a feather M0 simple, with a Matrix board.

When I try to run the following:

import adafruit_is31fl3731
import board
import busio
with busio.I2C(board.SCL, board.SDA) as i2c:
    display = adafruit_is31fl3731.Matrix(i2c)
    display.fill(127)

I get

AttributeError: 'Matrix' object has no attribute 'fill'

If I try to run the same code again in the same REPL session I get:

MemoryError: parser could not allocate enough memory

What am I doing wrong?

Thanks,
Boris

This library may be a good candidate for refactoring based on adafruit_bus_device and adafruit_register based on a quick initial look.

I want to write the code for Pimoroni 5x5 LED Matrix. The table and algorithm is very similar is for led_shim.
Except that led_shim has 28 entries and 5x5 has 25 entries.

Q1: What is prefered way of writing the mapping

• Lookup:

  Adafruit_CircuitPython_IS31FL3731/adafruit_is31fl3731/keybow2040.py

  Line 65 in 11533d4

  def pixel_addr(x, y):

• Algorithm:

  Adafruit_CircuitPython_IS31FL3731/adafruit_is31fl3731/led_shim.py

  Line 62 in 11533d4

  @staticmethod

(see below for code extract)

Q2: How do I convince pylint that this duplicate code is OK? Or should I put the table/algo in a separate file and import? (it is very similar but maybe with 3 entries less, but having 3 extra entries is not hurting much.

Lookup used in keybow2040:

    @staticmethod
    def pixel_addr(x, y):

        lookup = [
            (120, 88, 104),  # 0, 0
            (136, 40, 72),  # 1, 0
            (112, 80, 96),  # 2, 0
            (128, 32, 64),  # 3, 0
            (121, 89, 105),  # 0, 1
            (137, 41, 73),  # 1, 1
            (113, 81, 97),  # 2, 1
            (129, 33, 65),  # 3, 1
            (122, 90, 106),  # 0, 2
            (138, 25, 74),  # 1, 2
            (114, 82, 98),  # 2, 2
            (130, 17, 66),  # 3, 2
            (123, 91, 107),  # 0, 3
            (139, 26, 75),  # 1, 3
            (115, 83, 99),  # 2, 3
            (131, 18, 67),  # 3, 3
        ]

        return lookup[x][y]

Algorithm used in led_shim (not exactly the same table):

    @staticmethod
    def pixel_addr(x, y):
        """Translate an x,y coordinate to a pixel index."""
        if y == 0:
            if x < 7:
                return 118 - x
            if x < 15:
                return 141 - x
            if x < 21:
                return 106 + x
            if x == 21:
                return 15
            return x - 14

        if y == 1:
            if x < 2:
                return 69 - x
            if x < 7:
                return 86 - x
            if x < 12:
                return 28 - x
            if x < 14:
                return 45 - x
            if x == 14:
                return 47
            if x == 15:
                return 41
            if x < 21:
                return x + 9
            if x == 21:
                return 95
            if x < 26:
                return x + 67
            return x + 50

        if x == 0:
            return 85
        if x < 7:
            return 102 - x
        if x < 11:
            return 44 - x
        if x < 14:
            return 61 - x
        if x == 14:
            return 63
        if x < 17:
            return 42 + x
        if x < 21:
            return x + 25
        if x == 21:
            return 111
        if x < 27:
            return x + 83
        return 93

It seems there's a missing return that should occur when both parameters are None. If that does not occur, line 209 will (obviously) fail.

That way it can be swapped in for a NeoPixel strip.

Appears to still be using I2C bus directly.
https://github.com/adafruit/Adafruit_CircuitPython_BusDevice