*slower* performance when using I2CBACKPACK

[aroman]

Hi,

First of all thanks for this great library! I tried both the direct-to-board approach and the I2CBACKPACK approach. For single-pixel updates, or static displays, both work great. But for changing an entire strip of pixels (82, in my case), such as the "dynamic rainbow" example, both approaches slow to a crawl, and the framerate is barely 1FPS. I thought this was what I2CBACKPACK was supposed to enable, but for some reason it isn't working that way for me.

It seems like the big issue is the actual transmission/processing of the firmata commands on the main board. The RX light is constantly-on, and i can't even close the program with ctrl+C. It just prints 1518894452559 Board Closing. over and over until I kill the process. This behavior only happens with very fast refresh rates changing many pixels at a time.

Is the kind of operation/performance I'm trying to achieve simply not possible given the messaging overhead of FIRMATA?

[aroman]

Update for others wondering the same things: #4 has a ton of great information by @ajfisher. I'm keeping this bug open though as I do not understand why I2CBACKPACK is slower.

[ajfisher]

Can you post your code and I can have a look at it. You should be getting faster performance than this.

…

On Sun, Feb 18, 2018, 07:16 Avi Romanoff ***@***.***> wrote: Update for others wondering the same things: #4 <#4> has a ton of great information by @ajfisher <https://github.com/ajfisher>. I'm keeping this bug open though as I do not understand why I2CBACKPACK is *slower*. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#119 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAHRoxWMS1QdJ97AzAgidikWXXNQ3boqks5tVzOogaJpZM4SJbay> .

[aroman]

Thanks for the quick reply. The code I was running was your dynamic rainbow example, but with the following changes:

    strip = new pixel.Strip({
        data: 5,
        length: 82, // number of pixels in the strip.
        board: this,
        controller: "I2CBACKPACK",
        gamma: 2.8,
    });

(In fact, I've been using your strip.shift function to achieve a similarly pleasing effect with way less data, and that works fine. So I'm no longer blocked on this, but I still cant get the original example to run with >30 length)

[aroman]

Another issue (I can file a separate issue if you'd like) is the inability to SIGINT out of the process while it's driving a lot of LEDs (length ~30+) in that example. I have to SIGKILL/SIGTERM which is unfortunate because it causes a messy exit and sometimes has a hard time starting again (need to re-plug the USB cable).

[aroman]

Lastly, I should say that I've had to install the firmware on the board via

interchange install git+https://github.com/ajfisher/node-pixel -a nano --firmata,

NOT via

interchange install git+https://github.com/ajfisher/node-pixel -a nano, since this fails with the issue in #93.

Perhaps this is part of the issue? To be sure, the first/main arduino is able to control the lights directly if I say controller: FIRMATA, or via the second board over I2C if I say controller: I2CBACKPACK.