Replace PIO code with an inbuilt timer, based on https://learn.adafru… #20
Conversation
|
Many thanks for this. I'll test is as soon as I get the time. I'm not sure if this would cause any backwards-compatibility problems if merged to main, but if it works okay, I believe it probably shouldn't. |
|
I believe I've addressed your comments, let me know! Keep in mind the testcase I posted requires pull 19 to work. Also, I should mention the first four pixels are white for me when I apply this change, so it's not 100% yet. |
|
Thanks for addressing the comments. I'm not sure about the white pixel problem, but it might be due to the header and trailer because the code on that link I believe does some shifting and padding to fit the DMA requirements and I'm not sure if that's same here. |
Uses an offset to ensure get/set() happens in the right place. Also caches the memoryview once to make show() as efficient as possible. It turned out passing the header/trailer values as-is from python is the right approach. Everything works well for me now, maybe I'll look into DMA next :)
|
You were right, that packing was bogus. I've updated the PR with the new code, it works really nicely now... Thanks for your patience! |
|
Great to hear. Did the glitches also go away with this? |
|
Not entirely, though removing all interrupts and replacing with asyncio (especially Timers) seems to help a lot. It's waaay better though! |
|
Good. I'll probably have some time to review this and test next weekend. Thanks for all the effort 😄 |
|
Hi, I've finally had the time to check this, really sorry for the delay. It works quite well, but I had to change some code as rotation no longer works with this code. The other problem is that this only works for RGBW, so merging this would mean that RGB strips are no longer supported. I'm not entirely sure how to fix this, as that would require rewriting PIO program to do the pull once 24 bits are read. I'll see what I can do. |
|
Ah right I was worried about that. I’ll see if I can pass another argument in and have it only push the first 3 bytes if set. I don’t have a normal run strip to test with though, I’ll order or see if I can borrow one!
…-Max
On Mon, Apr 1, 2024 at 3:18 AM, Blaž Rolih ***@***.***(mailto:On Mon, Apr 1, 2024 at 3:18 AM, Blaž Rolih <<a href=)> wrote:
Hi, I've finally had the time to check this, really sorry for the delay. It works quite well, but I had to change some code as rotation no longer works with this code.
The other problem is that this only works for RGBW, so merging this would mean that RGB strips are no longer supported. I'm not entirely sure how to fix this, as that would require rewriting PIO program to do the pull once 24 bits are read. I'll see what I can do.
—
Reply to this email directly, [view it on GitHub](#20 (comment)), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AAABMCKAUN5ZTBC2MMPTYULY3BOSDAVCNFSM6AAAAABCZZDGGSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMRYHA4DCNZUHE).
You are receiving this because you authored the thread.Message ID: ***@***.***>
|
|
Thank you. I had an idea that could maybe work: when doing pull(ifempty) if we could somehow append some additional code to this ifempty and shift for 8 bits, then it should work. But at the moment I'm not sure if "ifempty" works outside pull instruction or/if it's possible to detect empty OSR. |
|
I think I figured it out. There is in fact and |
|
When you get some time, test this code I pushed on your end (RGBW only, no need to order RGB). I tested on both RGB and RGBW and it works for me on all examples now. |
|
Looking at the new asm for ws2821, I think that the new logic introduces some additional low output, that might be problematic in some cases, although I had no issues with my strip - I'll try to fix it, but I won't be able to test for some time now. |
…it.com/intro-to-rp2040-pio-with-circuitpython/advanced-using-pio-to-drive-neopixels-in-the-background
Not really helping with the glitchiness I wonder if it's my hardware at this point?