adafruit / adafruit_circuitpython_dotstar Goto Github PK

The dotstar library could benefit from a CircuitPython helper to offload computationally expensive setitem work to.
See adafruit/circuitpython#884

There is something odd going on in the code with a mix of the use of self.brightness and self._brightness - it won't work in its current form and it's confusing.

On minor issues, there's no use of the python * pseudo-argument in constructor to force use of named arguments for last two args. And the example in docs uses an integer 1 for brightness rather than floating point 1.0

Are there any plans to add support for converting HSV values to RGB, similar to what is implemented in the Adafruit Dotstar library. As stated in the Arduino library use guide, its a bit easier to get certain effects using HSV.

I'm not quite sure about the 16 bit part mentioned in the article. I've had success using python's colorsys module.

The fill() function doesn't switch fast enough. It seems to have a big delay somewhere, which I couldn't spot.
My expectation will have a color-switching very fast ~1ms or even slower, but apparently, it would take 100ms or more and can be detected the color change by eyes.

See the code below:

import adafruit_dotstar
import digitalio
import board
import math
import time
import random

num_pixels = 40
brightness = 0.005

pixels = adafruit_dotstar.DotStar(board.SCK, board.MOSI, num_pixels, brightness=brightness, auto_write=False)

BLACK = (0, 0, 0)
WHITE = (255, 255, 255)

while True:

pixels.fill(WHITE)
pixels.show()
time.sleep(0.001)

pixels.fill(BLACK)
pixels.show()
time.sleep(0.001)

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_dotstar.py:96
• adafruit_dotstar.py:153
• adafruit_dotstar.py:166
• adafruit_dotstar.py:172

Hello,
I try to define a random color and apply it to 5 dots directly here is my code

r = random.randint(0, 255) g = random.randint(0, 255) b = random.randint(0, 255) self.strip[0:5] = (r,g,b) * 5 self.strip.show()

But it is always blue.

What is the issue?

Most onboard DotStar implementations have no need for a chip_select pin and work fine without it.

However, the Pimoroni Pico RGB Keypad Base is a pack to be added to a board and requires a chip_select to be pulled low before sending the data to the LEDs. While this can be done outside the DotStar library it would be nice if this could be controlled by the library.

Example: https://github.com/lesamouraipourpre/Community_CircuitPython_TCA9555/blob/main/examples/tca9555_pimoroni_rgb_base.py

If this sounds like a reasonable addition I can prepare a PR for it.
It could either:

• Accept an optional chip_select pin as a constructor parameter
• Extend the DotStar class with a DotStarSPI class
• Create an adjacent DotStarSPI class which extends _pixelbuf.PixelBuf directly.
• Create a new library called Adafruit_CircuitPython_DotStarSPI

My preference would be for the first one as I believe it can be done without breaking the API.

The get_time() function needs updating to deal with variable pixel ordering introduced in #15 #18.

    def __getitem__(self, index):
        if isinstance(index, slice):
            out = []
            for in_i in range(*index.indices(self._n)):
                out.append(
                    tuple(self._buf[in_i * 4 + (3 - i) + START_HEADER_SIZE] for i in range(3)))
            return out
        if index < 0:
            index += len(self)
        if index >= self._n or index < 0:
            raise IndexError
        offset = index * 4
        return tuple(self._buf[offset + (3 - i) + START_HEADER_SIZE]
                     for i in range(3))

I've not tested the code this is just from inspection after seeing the issue come up in adafruit/Adafruit_CircuitPython_WS2801#9. I'd imagine it'll end up similar to the neopixel implementation in https://github.com/adafruit/Adafruit_CircuitPython_NeoPixel/blob/163bd47a8385b993309a4b9100bb5956b2066a1d/neopixel.py#L182-L195

@RedAnon and @mcscope may be interested in this.

APA102 allows each pixel to have a 5 bit global brightness value in addition to the 8 bit RGB values for each pixel. This library doesn't allow that to be set - see this comment

        # Each pixel starts with 0xFF, then red/green/blue. Although the data
        # sheet suggests using a global brightness in the first byte, we don't
        # do that because it causes further issues with persistence of vision
        # projects.

I've used the global brightness a lot on other projects, and it's really a nice feature. I think we should allow people to use it and just note in the documentation that if you use it for persistence of vision applications you may get flickering. By preventing people from using the brightness bit, we're stopped them from accessing a decent range of what these leds can do.

(The brightness works by PWMing the entire output of the LED, and it's at a much slower pulse than the leds themselves do, so it can be flickery for persistence of vision)
I'll maintain the default behavior of max brightness if brightness is unspecified so as to not modify existing projects

Hi,
I have the Featherwing Dotstar module. I'm not an expert in CircuitPython, but the example on the 'https://learn.adafruit.com/dotstar-featherwing-in-circuitpython/text' page doesn't work.
In fact, I have a feeling that the 'dotstar_featherwing.py' module class doesn't support text scrolling anymore.
Am I wrong? If so, why didn't you leave these features in place?
Best regards,
Mike

Hello, how can I change a range of led dots at the same time?

shouldn't line 207 be:
buf = bytearray(self.n * bpp + 8)

If I set brightness to <.99 then this fails because "n" is not defined.

Think you for your great effort ,
I have a problem i would be grateful if you could help me to solve it , I am building a POV Display project , My motor is turning 25 spin per second (1500 RPM) , there is 64 LEDs of HD107S (same to Dotstar but have much higher addressing frequency "30 Mhz" ) , the problem is the speed of scanning is not fast enough, therefore I see lines and not dots i barely show the flower , is there any way to speed up scanning time ? like change the frequency for example ....

Testing the Dotstar library give better result than Apa102-pi library , but it still far from objective , i didn't find how to change frequency , and it seems that the library get the value and send it at same time , therefor there is much time loss ,I would be grateful if you can help to find way to set higher frequency , in order to have the less refresh time possible .

Apa102-pi loop :

while 1:
if GPIO.input(15) == GPIO.HIGH:
strip.set_pixel_rgb(30, 0x00000F)
strip.show()
strip.set_pixel_rgb(30, 0x000000)
strip.show()

Dotstar loop :

while 1:
if GPIO.input(15) == GPIO.HIGH:
pixels[30] = (10, 0, 0)
pixels[30] = (0, 0, 0)

DeprecationWarning: The symbol module is deprecated and will be removed in future versions of Python from symbol import testlist_star_expr.

In version 2.2.5

Currently when calling _set_item with an integer value such as one out of FancyLED's color.pack(), or even the example given in the docstring of _set_item, 0xFFFFFF.

Example/repro code:

import adafruit_dotstar
import board

led = adafruit_dotstar.DotStar(board.APA102_SCK, board.APA102_MOSI, 1)
led[0] = 0xFFFFFF

Traceback (most recent call last):
  File "code.py", line 5, in <module>
  File "adafruit_dotstar.py", line 190, in __setitem__
  File "adafruit_dotstar.py", line 160, in _set_item
TypeError: object of type 'int' has no len()

The issue is that the line in question is assuming that value is a tuple when it can be an int, as mentioned in the docstring. I have a fix I can submit as a PR; basically the function will already convert value to a tuple as rgb, we just need to check the length of rgb instead of value.

The same issue is there in the NeoPixel library though I haven't tested it yet. I can create an issue and PR there as well if this one is accepted.

I'm a little new to Python this so I may be wrong here but I think adafruit_dotstar's getitem method is attempting to cap the range of the slice values using:

range(*index.indices(len(self._buf) // 4)):

But the length cannot be determined correctly with a simple division because of the header and trailer data in the buffer for dotstars. Perhaps this code was cut and paste from other code which has no header data in buffer?

self._n looks like a suitable (calculation-free) substitute here? I see setitem uses len(self) which looks correct but you may wish to avoid the method call given the hardware this typically runs on. Either way, a consistent approach across class would make code easier to read.

https://github.com/adafruit/Adafruit_CircuitPython_DotStar/blob/main/examples/dotstar_image_pov.py

is this example meant for linux?
i thought its a normal uC example..

it uses from PIL import Image
and i did not find any information how to use PIL from CircuitPython...

There is use of math.ceil() but there's no import math

So when making anything that uses neopixels or dotstars, you may encounter issues with color giving unexpected results, and you might want to gamma correct your LEDs.
Here's an adafruit learn about them.
https://learn.adafruit.com/led-tricks-gamma-correction/the-issue

My suggestion is that we make this really easy to do, so that you can just pass gamma=True to a Dotstar/Neopixel strip when you construct it, and it will gamma correct every value.
Here's what that might look like:
dot = dotstar.DotStar(board.APA102_SCK, board.APA102_MOSI, 1, brightness=0.3, gamma=True)

If we do this, it should probably be done both in circuitpython dotstar and circutpython neopixel to keep the api the same.

The learn guide has a table of hardcoded gamma correction values, but I've used an algorithmic solution in my mcscope/liteup library. Probably the algorithmic correction takes less of a ram hit?

GAMMA_CORRECT_FACTOR = 2.8

def gamma_correct(led_val):
    max_val = (1 << 8) - 1.0
    corrected = pow(led_val / max_val, GAMMA_CORRECT_FACTOR) * max_val
    return int(min(255, max(0, corrected))))

it's a python implementation of the algorithm on the third page of the learn guide.

@schelmo has noted that clock rises before data bit is written on the bitbanging implementation in _ds_writebytes() in adafruit/Adafruit_CircuitPython_WS2801#4

That code is the same and probably originated from here. Check origins of this code and find other occurrences. Forum post to see if anyone is using non hardware assisted pins, i.e. why has this only just been noticed.

(This could be a direct translation of some flawed C code which worked because timing was far tighter??)

APA Electronic has a new 13-bit version of the APA-102 LEDs which have a lower refresh rate (approximately 700MHz) but smoother colours.
As far as I can tell there is currently no way of controlling these chips. And it would be extremely awesome if we could control them.