Using waitvid for something other than video
JasonDorie
Posts: 1,930
I haven't had a good excuse to learn how to use the counters or video generator, so I made one up: One of the cogs in my TLC5940 driver does nothing but pulse a pin 4096 times, then pulse a different pin once, and do it all over again. It's used by the PWM hardware on the chip.
In PASM, the inner loop for it looks like this:
3 instructions, 4 cycles each @ 80MHz, 4096 times = 614.4 uS per loop. It works fine, but the TLC5940 can handle a 30MHz grayscale clock. The PASM code is about 4.5 times slower than that.
I read all the docs on waitvid, vcfg, and the counters, and figured out how to make the waitvid command work. I set the pixel clock frequency to 60MHz and then sent pixel blocks that are 16 pairs of '01', so each pair is a toggle, making 30MHz.
The new inner loop looks like this:
Assuming that it works the way I think it does, it'll execute that loop in 136 uS, and the cog spends a good chunk of its time suspended, waiting to feed the next block of pixels.
This could be a very cool way to send SPI data - All you'd need is a four color palette : 11_10_01_00, representing all possible pairs of clock and data. Each bit to send would be replicated, once paired with a clock high bit, and once paired with a clock low.
So the two bits 0 & 1 would become 00_10 & 01_11 in the pixel data.
One waitvid instruction could pipe out 8 bits of data and toggle the clock for you while you were off getting more data ready. It would only be useful for things like fixed or rarely changing values (like address, command, or device id) because converting an 8-bit value into 8 replicated bits interleaved with the clock toggles would take more time than sending them. ...but if you only had to create the values once...
This is mostly late-night rambling. I wanted to see how fast I could get the frame rate of the TLC5940 driver, and I think this is it - roughly 7000fps.
I haven't seen many examples of using the video generator to do things other than video, so I thought I'd share.
In PASM, the inner loop for it looks like this:
mov t1, count 'Load up the counter
:Toggle
or outa, gsmask 'Set the gspin high
andn outa, gsmask 'Set the gspin low
djnz t1, #:Toggle 'Toggle the pin again, if counter is not expired
3 instructions, 4 cycles each @ 80MHz, 4096 times = 614.4 uS per loop. It works fine, but the TLC5940 can handle a 30MHz grayscale clock. The PASM code is about 4.5 times slower than that.
I read all the docs on waitvid, vcfg, and the counters, and figured out how to make the waitvid command work. I set the pixel clock frequency to 60MHz and then sent pixel blocks that are 16 pairs of '01', so each pair is a toggle, making 30MHz.
The new inner loop looks like this:
mov t1, VidCount '4096 / 16 toggles per pixel block
:PixelLoop
waitvid Colors, Pixels 'push 16 pulses through with the video hardware
djnz t1, #:PixelLoop
Assuming that it works the way I think it does, it'll execute that loop in 136 uS, and the cog spends a good chunk of its time suspended, waiting to feed the next block of pixels.
This could be a very cool way to send SPI data - All you'd need is a four color palette : 11_10_01_00, representing all possible pairs of clock and data. Each bit to send would be replicated, once paired with a clock high bit, and once paired with a clock low.
So the two bits 0 & 1 would become 00_10 & 01_11 in the pixel data.
One waitvid instruction could pipe out 8 bits of data and toggle the clock for you while you were off getting more data ready. It would only be useful for things like fixed or rarely changing values (like address, command, or device id) because converting an 8-bit value into 8 replicated bits interleaved with the clock toggles would take more time than sending them. ...but if you only had to create the values once...
This is mostly late-night rambling. I wanted to see how fast I could get the frame rate of the TLC5940 driver, and I think this is it - roughly 7000fps.
I haven't seen many examples of using the video generator to do things other than video, so I thought I'd share.
Comments
!:D
Paul
I just spent a bit of time on Wikipedia, Google and the TLC5940 datasheet. I still don't know what a "grayscale clock" is. (This isn't a request to have it explained.)
The TLC5940 datasheet reminds me of my attempt (failed) at interfacing with some SDRAM on an old DIMM. Lots of pins to keep track of.
Looking forward to seeing what you do. It would be great to have an ultra fast SPI driver.
http://forums.parallax.com/showthread.php?98039
-Phil
http://forums.parallax.com/showthread.php?121321-Working-full-speed-(12-Mb-s)-bit-banging-USB-Host-controller
-Phil
The only reason I havn't released it is due to the fact that it's hard to make it work 100% of the time because of PLL phase issues.
/Ahle2
Can You release it anyway else send me copy on it to christofferj2@gmail.com.
As it can be very nice program to test Over-clocking on PCB's I build.
I will send you the code after some cleaning up. You can have the source code to my SIDcog demo as well. (I think you have asked about it before?)
/Ahle2
Thanks.
But not clean in that as it function correctly. It is this code with bugs I'm interested on.TO test PLL's reliablity.