WAITPEQ Madness -- RESOLVED
localroger
Posts: 3,452
SOLUTION -- typical Prop gotcha, I have a jmp l1 that should be jmp #l1.· The bizzarro thing is that it worked at all like that.
----
OK, this has me scratching my head.· I am trying to use my demoboard to profile the signal that a portable DVD player uses to drive its LCD.· (If I get the end project working it will show up here, and I think some folks will find it very useful.)· The signal "reverses" every scan line so, to make a long story short, it never spends more than about 63 milliseconds at logic 1 and for frame sync reeasons about 126 msec at logic 0.· The signal is only 0.9V p-p so I made a voltage divider with a 1K and 2K resistor and connected the DVD player ground to the center point, and I've verified with a scope meter that w/r/t demoboard ground the signal is swinging from about 1 to 2 volts, straddling the center threshold of the input.· I am operating both the DVD player and the other DVD player I'm using to monitor results on battery so there are no ground loop issues.
My basic questions are things like "exactly how long is a line pulse" and "how many lines are there in a frame."· The scope meter doesn't quite give me what I need, but the prop should let me get the answers to the microsecond -- except that it's not working.
Voila la code:
This works, but of course is only accurate to about 8-10 clock cycles.· I'm basically just looking for "the last pulse longer than thrval."· The repeat 100000 statement just slows down the results so I can read a representative sample.· Note that in spin I'm also outputting the raw pin so I can verify that it's toggling.·
With waitpeq I should be able to get it down to 1-2 clock cycles, right?· This also works:
So far so good.· This also works:
But ALL of the following lock the Prop up as soon as the signal is applied, whether they are followed by the second coded loop or the waitpeq that works if l1 is coded:
Note that by lock up, I mean it locks up the OTHER COG that is generating video.· If I download the program with the signal disconnected, the program starts and displays zeroes -- until I clip the test lead to the input pin, and the screen goes black.
I have tried alternate input pins, running everything on battery, and disconnecting all other peripherals.· I've tried coding to return max instead of greater than thrval.· I cannot for the life of me figure out why this doesn't work, and especially how changing from the coded loop to a waitpeq which should do exactly the same thing as the coded loop·manages to lock up the other cog that shouldn't have anything to do with the cog running the pasm profiler.
Any idears?
Post Edited (localroger) : 6/20/2009 6:58:40 PM GMT
----
OK, this has me scratching my head.· I am trying to use my demoboard to profile the signal that a portable DVD player uses to drive its LCD.· (If I get the end project working it will show up here, and I think some folks will find it very useful.)· The signal "reverses" every scan line so, to make a long story short, it never spends more than about 63 milliseconds at logic 1 and for frame sync reeasons about 126 msec at logic 0.· The signal is only 0.9V p-p so I made a voltage divider with a 1K and 2K resistor and connected the DVD player ground to the center point, and I've verified with a scope meter that w/r/t demoboard ground the signal is swinging from about 1 to 2 volts, straddling the center threshold of the input.· I am operating both the DVD player and the other DVD player I'm using to monitor results on battery so there are no ground loop issues.
My basic questions are things like "exactly how long is a line pulse" and "how many lines are there in a frame."· The scope meter doesn't quite give me what I need, but the prop should let me get the answers to the microsecond -- except that it's not working.
Voila la code:
CON
_clkmode = xtal1 + pll16x
_xinfreq = 5_000_000
video = 12
OBJ
text : "tv_text" ' Parallax 13-line Video
VAR
long maxc
PUB mainProgram | r, i
text.start(video)
cognew(@entry,@maxc)
repeat
text.hex(maxc,8)
text.out(32)
text.hex(ina[noparse][[/noparse]7],1)
text.out(13)
repeat 100000
DAT
entry
l1 mov thisval, ina
and thisval, pmask wz
if_nz jmp #l1
mov pval, cnt
l2 mov thisval, ina
and thisval, pmask wz
if_z jmp #l2
mov thisval, cnt
sub pval, thisval
neg pval, pval
cmp pval, thrval wc
if_c jmp l1
wrlong pval, par
jmp #entry
thisval long 0
pmask long $80
pval long 0
pclr long 0
thrval long $2700
This works, but of course is only accurate to about 8-10 clock cycles.· I'm basically just looking for "the last pulse longer than thrval."· The repeat 100000 statement just slows down the results so I can read a representative sample.· Note that in spin I'm also outputting the raw pin so I can verify that it's toggling.·
With waitpeq I should be able to get it down to 1-2 clock cycles, right?· This also works:
l1 mov thisval, ina
and thisval, pmask wz
if_nz jmp #l1
mov pval, cnt
waitpeq pmask, pmask
mov thisval, cnt
sub pval, thisval
neg pval, pval
So far so good.· This also works:
l1 mov thisval, ina
and thisval, pmask wz
if_nz jmp #l1
mov pval, cnt
waitpne pclr, pmask
mov thisval, cnt
But ALL of the following lock the Prop up as soon as the signal is applied, whether they are followed by the second coded loop or the waitpeq that works if l1 is coded:
l1
waitpeq pclr, pmask
mov pval, cnt
l1
waitpne pclr, pmask
mov pval, cnt
l1
waitpeq pmask, pmask
mov pval, cnt
l1
waitpne pmask, pmask
mov pval, cnt
Note that by lock up, I mean it locks up the OTHER COG that is generating video.· If I download the program with the signal disconnected, the program starts and displays zeroes -- until I clip the test lead to the input pin, and the screen goes black.
I have tried alternate input pins, running everything on battery, and disconnecting all other peripherals.· I've tried coding to return max instead of greater than thrval.· I cannot for the life of me figure out why this doesn't work, and especially how changing from the coded loop to a waitpeq which should do exactly the same thing as the coded loop·manages to lock up the other cog that shouldn't have anything to do with the cog running the pasm profiler.
Any idears?
Post Edited (localroger) : 6/20/2009 6:58:40 PM GMT
Comments
-Phil
CON _clkmode = xtal1 + pll16x _xinfreq = 5_000_000 video = 12 OBJ text : "tv_text" ' Parallax 13-line Video VAR long maxc PUB mainProgram | r, i text.start(video) cognew(@entry,@maxc) repeat text.hex(maxc,8) text.out(32) text.hex(ina[noparse][[/noparse]7],1) text.out(13) repeat 100000 DAT entry l1 waitpeq pclr, pmask mov pval, cnt l2 mov thisval, ina and thisval, pmask wz if_z jmp #l2 mov thisval, cnt sub pval, thisval neg pval, pval cmp pval, thrval wc if_c jmp l1 wrlong pval, par jmp #entry thisval long 0 pmask long $80 pval long 0 pclr long 0 thrval long $2700This version should work exactly the same as the first "working" version above, but it displays zeroes until the input pin goes logic 1, at which point the screen goes black.
EDIT -- and resolved.· there's a jmp l1 in there that should be jmp #l1.· Odd that the other version works with this error.
Post Edited (localroger) : 6/20/2009 6:57:40 PM GMT
JMP l1 reads the content of COG RAM adress $0 and finds mov thisval, ina
INA is somwhere around $1f?, so in the end we have JMP $1f?.
As you don't use the counters and stuff the 'code' there will be NOPs and the program counter turns around comeing back to l1.
JMP l1 in the waitxx case takes pmask as adress, which is $080. What to find there is very likely something comeing from the tv_text ... maybe some SPIN code which accidently contains the cogstop-command or a write to HUB-RAM to a place that confuses the TV-driver.