Shift left and add c
ke4pjw Posts: 966
I am working on Jon McPhalen's pixel driver so that I can drive 8 PINs with a single cog. I have it doing that, but only from a single buffer source. I need to have individual buffers for each pin.
What my plan of attack is, is to shift left with wc on each of the buffers that I wish to pull data from,shift left and add c into a byte. Once the byte is populated, write that byte to the pins in parallel to 8 pins after .4us of high, and holding it for another .45us. That will ensue any 1's will be .85us and any 0s will be .4us.
Is there a good shortcut to shifting left and adding c?
BTW, Jon's code is simply gorgeous.
Yep, in Pasm there is Rotate Carry Left. And there's also a Rotate Carry Right for shifting the opposite direction.
It's going to be interesting to see how that shakes out.
Since you're starting with my code, I hope you'll share how you solve this.
Okay, where's the original?
This is the assembly section of the driver Terry referenced.
Oh, shift out to C ... That penny didn't drop immediately.
EDIT: I'm thinking one of the smartpin modes is going to be helpful here. What's the timing diagram look like? I see it's 1.5 us per bit.
This is the start of an idea I toyed with yesterday.
Is there some other topic covering all this? It feels like I'm in need of a catch up.
It works, mostly. Can't figure out why P7 and P8 don't work. Here is the chunk of the relevant code. Timing is still not exact, but the pixels work.
Currently you really should have the same number of pixels on each port, otherwise, it should just be the longest number of pixel strings on a port. I turned what Jon was doing sideways to parallel it.
You can track my progress here:
Just saw your post Jon. I will study that! Your code most likely is better and I am sure I will learn something. Thank you sir!
The conversation is somewhat ethereal. It seems there must be other linking topics on the propeller forums.
I'm going to try an 8-output version limited to the WS2812b (simplifies code).
This is the only one I know of. This is related to my W6100 Ethernet project. I have E1.31 ethernet controlling the pixels. If the velocity of this project continues, I will be testing driving my 4'x8' 1200 pixel (24x50) matrix this week with it. Fingers and toes crossed!
I think I have the parallel drive working for WS2812Bs. It's not ready for publication yet, so I'll just share some pieces to see what you think.
I always start very simple. This creates eight 2-pixel buffers and I set the first channel in each buffer to a color and leave the next channel black (0) -- this makes it easy to examine on a logic analyzer.
Here's the new object start() method.
Finally, here's the cog code. It's substantially longer than the single output version -- not a surprise with 8 simultaneous outputs.
The next step is to update the methods that manipulate a buffer to accept a buffer id -- I will do that tomorrow.
Here's a screen cap from the logic analyzer running the test code. This is kind of exciting!
Well, you both seem to be carrying on about an existing driver, which obviously isn't Ethernet comms. Is there something, on the forums, covering that?
Oh, this is Jon's pixel driver- jm_rgbx_pixel.spin2
I think it ships with the PropellerTool.
@JonnyMac I found a bug in my code that maps the E1.31 universes to a pin. It was a dumb mistake and I have all 8 pins working with inputs from Jinx!
Can't wait to see your finished code! I am a super sloppy coder that hacks at things until it works. I know your driver will be superior!
It is wild to see how many refreshes are occurring with a 100 pixel string vs 8 configured and 4 unconfigured E1.31 universes. When line 0 goes low, there is E1.31 data in the buffer. Line 1 is the P7 output, that is mapped to E1.31 Universe 9. The matrix refresh is set to 25Hz and it looks like the P2 will have absolutely no problem doing this! I knew she was a Pixel Pusher!
Thank you. And I see there is links to PDFs in the driver source too. That's handy.
Hmm, I guess next problem is I can't test any code without these LEDs ... they look like they could be the fancy lighting strips in the local lighting shops - job for tomorrow ...
Well, I stayed up far too late tonight -- but I think this is okay to share with others. I disconnected the LA and attached LEDs. All ports seem to be working properly.
You should be able to update about 1200+ pixels per port at 25Hz. That said, I have found long pixel strings require long reset periods (otherwise you get weird sparkles -- I had this happen on an art piece).
Please let me know if you find any issues with the driver. Once it's really wrung out I'll make a multi-type version that is like my original driver, but with 8 simultaneous outputs.
I updated my 8-port WS2812b driver so that it can vary between 1 and 8 ports. Now that this is working, I will add the other pixel types back into the mix. For those using WS2812b pixels, this is ready.