@Wuerfel_21 said:
Better to use the symbolic P_INVERT_OUTPUT than a magic number...
The hardware and software manuals could do with some cross pollination on this. There's a disconnect between them. The simplest improvement would be add the symbols to the hardware manuals.
@ke4pjw said:=
Something that is really bothering me is the way I am driving that last group of 8 pins.....
altsb tx, #outa ' What is the base PIN?
setbyte #$FF ' Turn them all on, because pixeldata always starts with a 1
tx is set to 4 (P32-P40), but the source is #outa instead of #outb. How is that even working?!?!? I just added the extra code in the main program to start the cog that sends data to the last group of outputs, full send. It worked so I never reviewed it. Now that I look at it, how does it even work?!
It works because outb is the next register address after outa, and altsb, altsw, altsn etc each automatically advance into the next register(s) when the resulting indexed nibble, or byte, or word spills over into subsequent addresses. Handy!
I implemented @cgracey 's suggestions. (I implemented it for WRn,RDn,A0,A1, and CS) Before the changes, I was able to see the CS properly on my scope, and boy did it have a nasty spike! That waveform was UGLEY! After doing what Chip suggested, that waveform cleared up nicely. However, with the cap across the line, I lost communication with the W6100. With it removed, the familiar glitching returned.
Knowing I had done everything I could do to ensure there was no ringing/bouncing caused by the handshaking lines, I turned back to the validate that if I shutdown the cog that was driving pins P32-P40, the glitching would stop. It did. I then implemented the suggestion by @ManAtWork and turned the drive down on those pins to 1.5K (WRPIN ##$00000800) and poof! Fixed! Solid! Perfection!
The drive was too dang high!
So the induced RD bounce was indeed coming from the output. The correlation with the input was much more complicated than it first seems, because of the way these ws2812 pixels are driven. It is not a direct 1 or 0 for 1 or 0, it is driven low for a specified period of time depending on if you are sending a 1 or a 0.
I have had a lot of sleepless nights worried I would never figure this out. I enjoy killing the magic of how things work. It only seems like magic because I don't understand.
There were additional tweaks I had to make, driving some pins with WRPIN ##$00000C00. Those pins get occasional glitches, but I suspect now it is due to the ethernet data lines causing the issue. It does not affect all outputs, just outputs 22,23, and 24. I may look into reducing the drive on the ethernet datapins to help resolve this glitch.
I checked my code into devops, so I have it offsite. Time to update the known bugs in devops and do a methodical code cleanup.
Comments
The hardware and software manuals could do with some cross pollination on this. There's a disconnect between them. The simplest improvement would be add the symbols to the hardware manuals.
It works because outb is the next register address after outa, and altsb, altsw, altsn etc each automatically advance into the next register(s) when the resulting indexed nibble, or byte, or word spills over into subsequent addresses. Handy!
It is fixed! All in software!
I implemented @cgracey 's suggestions. (I implemented it for WRn,RDn,A0,A1, and CS) Before the changes, I was able to see the CS properly on my scope, and boy did it have a nasty spike! That waveform was UGLEY! After doing what Chip suggested, that waveform cleared up nicely. However, with the cap across the line, I lost communication with the W6100. With it removed, the familiar glitching returned.
Knowing I had done everything I could do to ensure there was no ringing/bouncing caused by the handshaking lines, I turned back to the validate that if I shutdown the cog that was driving pins P32-P40, the glitching would stop. It did. I then implemented the suggestion by @ManAtWork and turned the drive down on those pins to 1.5K (WRPIN ##$00000800) and poof! Fixed! Solid! Perfection!
The drive was too dang high!
So the induced RD bounce was indeed coming from the output. The correlation with the input was much more complicated than it first seems, because of the way these ws2812 pixels are driven. It is not a direct 1 or 0 for 1 or 0, it is driven low for a specified period of time depending on if you are sending a 1 or a 0.
I have had a lot of sleepless nights worried I would never figure this out. I enjoy killing the magic of how things work. It only seems like magic because I don't understand.
Thank you all so very much!
Soften those edges.
There were additional tweaks I had to make, driving some pins with WRPIN ##$00000C00. Those pins get occasional glitches, but I suspect now it is due to the ethernet data lines causing the issue. It does not affect all outputs, just outputs 22,23, and 24. I may look into reducing the drive on the ethernet datapins to help resolve this glitch.
I checked my code into devops, so I have it offsite. Time to update the known bugs in devops and do a methodical code cleanup.