Shop OBEX P1 Docs P2 Docs Learn Events
Using waitvid for something other than video — Parallax Forums

Using waitvid for something other than video

JasonDorieJasonDorie Posts: 1,930
edited 2011-04-06 06:01 in Propeller 1
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:
  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

  • Andrey DemenevAndrey Demenev Posts: 377
    edited 2011-04-03 05:05
    With 2 counters, it should be possible to generate clock with counter B, and send data with video generator - up to 32 bits per WAITVID instruction.
  • JasonDorieJasonDorie Posts: 1,930
    edited 2011-04-03 05:31
    I can't think of a way to use the 2nd counter to generate the clock in a way that's controllable by the waitvid so it only occurs while the waitvid instruction is pushing out pixel data. Can that be done?
  • Andrey DemenevAndrey Demenev Posts: 377
    edited 2011-04-03 05:46
    Although tricky, I think that can be done if serial interface has some sort of enable signal. Then you issue waitvid with say 16 meaningful bits in 32-bit frame, and then at the moment when it starts to output first meaningful bit you set the enable line, then issue waitvids with more data.When running video PLL at frequencies that are CLKFREQ divided by powero of 2, I believe the video PLL phase should be constant relative to system clock.
  • Andrey DemenevAndrey Demenev Posts: 377
    edited 2011-04-03 05:53
    Another use may be a phase-modulated signal generation - video generator can make a signal with variable phase
  • doggiedocdoggiedoc Posts: 2,246
    edited 2011-04-03 06:07
    Very cool concept although over my head by some margin. Still, I am subscribing to this thread so I can learn more!

    !:D
    Paul
  • Duane DegnDuane Degn Posts: 10,588
    edited 2011-04-03 08:25
    Ditto what Paul just said.

    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.
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2011-04-03 08:44
    Here are a couple other non-video applications of waitvid:

    -Phil
  • AribaAriba Posts: 2,690
    edited 2011-04-03 09:39
  • jazzedjazzed Posts: 11,803
    edited 2011-04-03 11:17
    I remember Hippy and others using WAITVID several years ago to generate Manchester encoding of data for 10Mb/s Ethernet transmit. Too bad there is not an easy equivalent for assembling bit streams into bytes. Kuroneko made some kind of a receiver using COG counters. Chip seems to be putting a flexible SERDES on Propeller 2 .
  • Phil Pilgrim (PhiPi)Phil Pilgrim (PhiPi) Posts: 23,514
    edited 2011-04-03 11:25
    jazzed wrote:
    I remember Hippy and others using WAITVID several years ago to generate Manchester encoding of data for 10Mb/s Ethernet transmit.
    That's the second link in my post above.

    -Phil
  • jazzedjazzed Posts: 11,803
    edited 2011-04-03 11:27
    That's the second link in my post above.

    -Phil
    Sorry for ignoring you :)
  • Ahle2Ahle2 Posts: 1,179
    edited 2011-04-03 11:50
    I have made a C3 spi-ram driver using the video generator. It features 20 Mbit/s to/from the spi-ram.
    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
  • SapiehaSapieha Posts: 2,964
    edited 2011-04-03 12:18
    Hi 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.



    Ahle2 wrote: »
    I have made a C3 spi-ram driver using the video generator. It features 20 Mbit/s to/from the spi-ram.
    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
  • kuronekokuroneko Posts: 3,623
    edited 2011-04-03 16:37
    JasonDorie wrote: »
    I can't think of a way to use the 2nd counter to generate the clock in a way that's controllable by the waitvid so it only occurs while the waitvid instruction is pushing out pixel data. Can that be done?
    You can at least benefit from the PLL clock, just use PLL mode %00010 and assign an output pin (video works with all PLL modes).
  • kuronekokuroneko Posts: 3,623
    edited 2011-04-03 18:44
    When running video PLL at frequencies that are CLKFREQ divided by powero of 2, I believe the video PLL phase should be constant relative to system clock.
    It's locked to the rising edge of the NCO feeding the PLL. Careful with /32, /64 and /128 though. In this case it's not constant relative to when the NCO was started, e.g. /128 can sync to any rising edge from 8n+0 .. 8n+7.
  • Ahle2Ahle2 Posts: 1,179
    edited 2011-04-06 03:23
    Sapieha wrote: »
    Hi 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
  • SapiehaSapieha Posts: 2,964
    edited 2011-04-06 06:01
    Hi 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.



    Ahle2 wrote: »
    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
Sign In or Register to comment.