waitpeq / waitpne

Jack Buffington

I found a thread on the forum about these instructions taking 6 cycles instead of five but I am having a different issue I think. I am sampling a VGA 640x480x60Hz signal that has a 25.175MHz pixel clock. I have overclocked my propeller to a 25.000MHz instruction cycle to be close to that frequency. I can't find a better crystal to match that frequency. For each scan line I am using waitpne followed by waitpeq to find the trailing end of the horizontal sync signal. It appears that these instructions don't kick out of waiting on a predictable basis. The data sheet says that the condition is checked every system clock but that is not what I am seeing I think. Are they supposed to kick out of waiting on the next system clock after they see the valid condition or do they kick out of waiting the next system clock divided by four to match the cog instruction cycle? It appears that it may be the next system clock divided by four because if I put up a test pattern with vertical bars, I see something like what I have drawn below. There is a one pixel difference in the sync every few lines. This happens regardless of where in the image horizontally I sample the pixels.

#  #  #  #
#  #  #  #
#  #  #  #
#  #  #  #
 #  #  #  #
 #  #  #  #
 #  #  #  # 
#  #  #  #
#  #  #  #
#  #  #  #
#  #  #  #
 #  #  #  # 
 #  #  #  # 
 #  #  #  # 
 #  #  #  # 

This leads me to believe that there is no escaping the system clock divided by four for the cogs even though some instructions take five or seven clocks. Am I missing something? Has anyone else sampled VGA signals here?

Mike Green

1) When you say "25.000MHz instruction cycle" do you mean a 100MHz system clock? Are you using the 16x PLL with a 6.250MHz crystal?
There's some jitter inherent in the use of a PLL.

2) The WAITPEQ/WAITPNE instructions sample the input once during each system clock cycle, so there's a 10ns jitter inherent in the process (with a 100MHz system clock). Perhaps that's what you're seeing.

Jack Buffington

Yes. I am running with a 100Mhz system clock. 12.5Mhz crystal with 8X PLL.

I figured out what the issue was. It had stumped me all of yesterday though... The waitpeq command is indeed starting the cog on the system clock that it sees the valid condition. What was happening was I was sampling right on the edge of the pixels so sometimes I would catch them and sometimes I wouldn't. What I did to correct things was to throw in another waitpeq right after the first one to take up an extra system clock cycle. This put the sampling more in the middle of the pixel's time slot.