WAITPEQ help please
Harley
Posts: 997
For some reason WAITPEQ almost works. Help please!
1. There are 17 bits (16 plus a 'strobe' bit) to compare against I/O signals. The valid compare time is 800 nsec, which should be more than adequate.
2. Using ViewPort, I can observe that the timing is correct and that the 16 signal values are proper. But it always hangs waiting for the WAITPEQ compare at full speed (80 MHz system clock.)
3. Using PASD, I can step through the code, but only occasionally will a match occur. And then only after numerous re-starts. (A keypad press re-start this cog to get out of the hang-up state which is possible in real use.)
I've re-read and re-read the PASM manual for this instruction and think I have WAITPEQ set up properliy. The signals have been analog scoped numerous time and appear OK. I've even swapped out the Prop for a new one, same no match. I've tried single bit compare, which works OK, but not with multiple bits! I've worked around this instruction debugging other sections of code.
What am I doing wrong? Does anyone spot a problem with this instructions's use. Thanks in advance for any assistance. WAITPEQ seems to be the perfect instruction, it is the fastest, if it works, than any other coding. I need as low as possible a latency time from event to matching a user's input value.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
Post Edited (Harley) : 5/27/2009 3:35:44 AM GMT
1. There are 17 bits (16 plus a 'strobe' bit) to compare against I/O signals. The valid compare time is 800 nsec, which should be more than adequate.
2. Using ViewPort, I can observe that the timing is correct and that the 16 signal values are proper. But it always hangs waiting for the WAITPEQ compare at full speed (80 MHz system clock.)
3. Using PASD, I can step through the code, but only occasionally will a match occur. And then only after numerous re-starts. (A keypad press re-start this cog to get out of the hang-up state which is possible in real use.)
I've re-read and re-read the PASM manual for this instruction and think I have WAITPEQ set up properliy. The signals have been analog scoped numerous time and appear OK. I've even swapped out the Prop for a new one, same no match. I've tried single bit compare, which works OK, but not with multiple bits! I've worked around this instruction debugging other sections of code.
What am I doing wrong? Does anyone spot a problem with this instructions's use. Thanks in advance for any assistance. WAITPEQ seems to be the perfect instruction, it is the fastest, if it works, than any other coding. I need as low as possible a latency time from event to matching a user's input value.
BAbusRd
andn OUTA,INTR1msk ' set A21/pin 26 to LO level
or DIRA,INTR1msk ' set /INTR pin to output
wrlong zed0,PAR ' ensure PAR clear on entry ???
or DIRA,TestMsk2 ' also set A20/pin 25 to Output
andn OUTA,TestMsk2 ' and LO level
:loop 'xor OUTA,TestMsk2 ' added for visual view in VP
rdlong BAcomp,PAR wz ' test if valid BP + BM1 value (noon-zero)
if_z jmp #:loop ' wasn't, continue to loop
or OUTA,TestMsk2 ' TEMP test use
nop
nop
nop
nop ' 8 x 50 nsec/ = 400 nsec HI
nop
nop
nop
waitpne BM1mask,BM1mask ' wait for BM1 at LO level
andn OUTA,TestMsk2
' waitpeq BM1mask,BM1mask ' wait for BM1 at hi level
or OUTA,TestMsk2 ' set HI A20/pin 25 (VP pos sync)
' nop ' 2* x 50 nsec/ = 100* nsec HI
waitpeq BAcomp,BAbusMask ' wait for breakpoint match
andn OUTA,TestMsk2 ' TEST
:doINTR
or OUTA,TestMsk2 ' TEMP
andn OUTA,TestMsk2 ' TEMP
wrlong zed0,PAR ' clear PAR after a BP event
jmp #:loop ' loop forever ' TEMP
or OUTA,INTR1msk ' output pos. pulse to Pod on A21/pin 26
wrlong zed0,PAR ' clear PAR after a BP event
' nop ' stretch for viewing; ViewPort cannot display events during
' nop ' first several hundred nanoseconds after trigger
' nop
' nop
' nop ' 8 x 50 nsec/ = 400 nsec HI
' nop
' nop
andn OUTA,INTR1msk ' return to LO level
jmp #:loop ' loop forever
' PASM instructions take 4 system clocks, except RDLONG, WRLONG (7..22) and WAITPEQ (5+)
' Initialized data for 'BAbusRd'
BM1mask long |<16 ' mask for only BM1 pin (A16) event $0001_0000
BAbusMask long $0001_FFFF ' BM1 + 16 Z80 addr bits mask
TestMsk2 long |<20 ' temp 'marker for this cog
INTR1msk long |<21 ' mask for /INTR on A21/pin 26
zed0 long 0 ' to clear a 32-bit register (PAR)
' Unitialized data for 'BAbusRd'
BAcomp RES 1 ' holds 'breakpoint' value from SBPt; compare w/BAbus value
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
Post Edited (Harley) : 5/27/2009 3:35:44 AM GMT
Comments
I can't see anything obvious wrong (block until (INA & S) == D) if that's what you want.
Post Edited (kuroneko) : 5/27/2009 1:17:22 AM GMT
I want to look for a match as soon as possible after BM1 goes high. Do I have this code wrong for that?
Yes, BAcomp value is only 17 bits (actually a 16 bit value plus when BM1 is HIGH).
Valid compare time is I assume the WAITPEQ instruction will take much less time than the 800 nseconds of BM1, like 5 + clock times after BM1 goes HI once a match occurs. Yes, the bit pattern stays valid dthat long.
The fact that it sometimes does see a match was a surprise, as it had previously never happened. But don't understand why it sometimes compares but most of the time will not. Others have used this instruction, so wonder why it is so difficult to get going. Unless the PASM text is not correct or there's a condition I don't read in this instruction.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
Bit 16 = 1 makes sure that BM1 is high as a prerequisite, after that the address has to match (while BM1 is high).
You say 'code looks OK.' I've been at this for waay too long. And it looks OK to me too. Just can figure out how to further debug this critter. When it steps through PASD OK, and each instruction seems to be working fine, but then when I go back to running it at full speed, it just hangs after getting into the WAITPEQ instruction. That is why the test signals to view in ViewPort. Just hangs!
Thanks for taking a look at this 'mystery'.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
This is just POC so no points for looking nice. The counter cog sets BM1 to high for 2sec, then low for 2sec then high again and keeps it there. It also starts counting up 16bit (demo board P0..P7, P18..P25). At the bottom (source) there is a commented waitcnt which - when enabled - will slow the visible counter (LED P18..P23) down to managable speed. ATM it runs at full speed (~500ns cycle).
The monitor cog waits for BM1 low, after that for BM1 high and address match. When the waitpeq returns, it lights up LED P17.
I tried to reverse engineer what all you are doing in your 'waitpeq.spin'; I can see it would take too much time to regen. it for my understanding. I could not determine if you were doing anything different that allows yours to work than my code. Don't know why I've run into a road block with this one instruction.
Wish I could pass this before Chip's eyes and see what his take on how WAITPEQ should be handled. Yeah, a hint-hint. If anyone should know, Chip's the ONE.
Thanks again, kuroneko, for your comments and time.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
Post Edited (kuroneko) : 5/28/2009 12:32:10 AM GMT
The 'address' values passed presently would range from 0000h .. 0014h (plus bit 16 set) only because of the present target's test EPROM. Actually once running, this target only runs from 0004h . 0014h. In actual use, 0000h .. FFFFh should be available to compare.
Using PASD I can step through the PASM code and observe that PAR and BAcomp are OK. I do have an ORG prior to the code, but had other text and PASD code I didn't want to confuse things by showing it. Funny that PASD allows one to step through and see all the right stuff happening, yet when run full speed it doesn't seem to then be right!
I'd not thought about using any dedicated registers, like FRQA, as a general purpose register, even though not being otherwise used for this cog. Also the use of OUTB surprised me. Hadn't run low on spare registers so hadn't a need to use them.
The '17 lines' are inputs only to my knowledge. The fact that I can see the sequence, via ViewPort, of 0004h.. 0014h should verify that fact.
I have another cog in a second Prop that has seven WAITPEQs that I need to also have working or this project will be dead. Getting a first WAITPEQ to work will provide much joy. I've been working around this for many moons.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
Well, that's certainly an odd one. Next step, grab a free cog, and tell it to issue the correct bit pattern (e.g. $00010014) 5 sec after it started to its outa. I've yet to see a prop where the internal bus is broken. It must be something obvious we're missing.
Perhaps, given how much trouble it is giving you, you should try to test for fewer pins until you have it working better, then expand from there. I find myself to be more productive when I expand on something that works.
Is it possible that when you are doing the check _including_ BM1, that BM1 has already changed to another value?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
I don't see what's not right or missing, but this instruction has given me the most grief of all the Prop instructions I've made use of.
But I'm not about to quit either. Just was hoping someone saw something wrong with what I'm doing. Back to the 'battle'.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
Okay, just so I understand things, are you talking from one propeller chip to another with this?
Can you try a simple program that does nothing but waitpeq for a single bit to be correct?
Surely we can get that to work [noparse]:)[/noparse].
Then add complexity...
Are your inputs set as inputs correctly?
I may try to run that command at home tonight, not sure how much time I will get though.
Now this seems very strange to me, if I read the instruction correctly. I read it as "State is compared against INx ANDed with Mask", and "Mask is bitwise Anded with INx before the comparison with State", no?
BAbusRd andn OUTA,INTR1msk ' set A21/pin 26 to LO level or DIRA,INTR1msk ' set /INTR pin to output wrlong zed0,PAR ' ensure PAR clear on entry ??? or DIRA,TestMsk2 ' also set A20/pin 25 to Output andn OUTA,TestMsk2 ' and LO level :loop 'xor OUTA,TestMsk2 ' added for visual view in VP rdlong BAcomp,PAR wz ' test if valid BP + BM1 value (noon-zero) if_z jmp #:loop ' wasn't, continue to loop or OUTA,TestMsk2 ' TEMP test use nop nop nop nop ' 8 x 50 nsec/ = 400 nsec HI nop nop nop waitpne BAcomp,BM1mask ' wait for BM1 at LO level andn OUTA,TestMsk2 waitpeq BAcomp,BM1mask ' wait for BM1 at hi level or OUTA,TestMsk2 ' set HI A20/pin 25 (VP pos sync) ' nop ' 2* x 50 nsec/ = 100* nsec HI waitpeq BAcomp,BAbusMask ' wait for breakpoint match andn OUTA,TestMsk2 ' TEST :doINTR or OUTA,TestMsk2 ' TEMP andn OUTA,TestMsk2 ' TEMP wrlong zed0,PAR ' clear PAR after a BP event jmp #:loop ' loop forever ' TEMP ' Initialized data for 'BAbusRd' BM1mask long |<16 ' mask for only BM1 pin (A16) event $0001_0000 BAbusMask long $0001_0000 ' BM1 + 16 Z80 addr bits mask 'BAbusMask long $0001_FFFF ' BM1 + 16 Z80 addr bits mask TestMsk2 long |<20 ' temp 'marker for this cog INTR1msk long |<21 ' mask for /INTR on A21/pin 26 zed0 long 0 ' to clear a 32-bit register (PAR) ' Unitialized data for 'BAbusRd' BAcomp RES 1 ' holds 'breakpoint' value from SBPt to compare w/BAbus value FIT 496I included the cog code again as I'd made numerous edits trying other things to no avail. I still don't understand why the bit 16 only mask won't allow any other values greater than it to pass the WAITPEQs. Anyone have a clue?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
waitpeq val_OK, mask ' may match eventually waitpeq val_NG, mask ' never matches mask long $0001FFFF val_OK long $00010014 val_NG long $FF010014In short, you never get a match when D & !S is not zero.
Apologies for not making clear about BAcomp range. It is basically derived from a 16-bit 'address' and a bit 16 ORed HI. The upper 15 bits are all Zeros.
After reading you last post, I'm mulling over why I don't get a compare when the mask is 0001_FFFF and BAcomp is between 0001_0000 and 0001_FFFF.
I sure wish the manual had included a clear example for WAITPEQ. I've looked at several people's code using that instruction and don't see what the 'trick' might be. I tried to do it the same way. I feel like I'm becoming as dense as a brick on this detail.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
The Prop using the WAITPEQ comparator has no free I/O pins; does have a couple free cogs. This Prop has no means to easily display anything. I have to use ViewPort or PASD to observe things at present. I couldn't follow your example code to know how to 'connect' it to mine and 'see' anything. So the answer is 'No I didn't; sorry.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
Does the 'bitwise ANDed with INx' repeat over and over (loop) until a match occurs?? Else, how does it prepare for later INx values being ANDed with Mask?
Otherwise, if no match first time, then a hang-up occurs forever, it appears. But don't think this is what's really implemented in WAITPEQ
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
- don't connect any external source
- start your problematic waitpeq cog with say BAcomp $0001ABCD, BAbusMask $0001FFFF
- start the trigger cog with $0001ABCD
- after 8 sec (you can adjust the value) there should be a match
As for waitpxx, they re-evaluate the bit pattern for each iteration, wouldn't be much point otherwise [noparse];)[/noparse]On entering the PM page, I noted several PMs to me I don't ever recall getting an email notice or any notice of. So am letting you know of this, if such happens for you.
Thanks
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
Finally had the time to incorporate your code, comment in/out 13 lines of code to switch between ViewPort and PASD to verify our code was operating OK in my program (it was; Oh, conditional compile would be so useful!!), and revert back to ViewPort to observe all 32 lines in LAS mode and can see the input 'ABCD' that my code runs, but hangs up, at the WAITPEQ, unfortunately. My flag, A20, gets set but not reset (which it should if exiting a WAITPEQ.)
Now, back where I was, my task still is how to find what and why no match/exit occurs. ViewPort shows the '1ABCD' placed on the lines (the real target lines are received thru 2K resistors, which isolate the target from the 17 of 32 'outa' bits of your code). Thanks for your assistance; it verifies that a proper value is NOT being matched and exited by my use of the WAITPEQ instruction.
Sigh, "Back to the drawing board, fellow" I say to myself.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
[img]http://forums.parallax.com/images/smilies/tongue.gif[/img]eqWait mov INAtemp,INA ' get, and INAtemp,BAbusMask ' mask, xor INAtemp,BAcomp wz ' and compare if_nz jmp #[img]http://forums.parallax.com/images/smilies/tongue.gif[/img]eqWaitso I could check if I was doing something strange with WAITPEQ. The program ran the same, that is, stepping through with PASD I could see that when INA matched BAcomp value it would exit. But only when stepping. Running in PASD it never would exit. So think it isn't my using WAITPEQ, but something else.
Got me to thinking if maybe the serial resistors between some 5v TTL and the Prop is somehow not right. I'm using 2.2K now, thinking of reducing that down to something like 470 Ohms. There are 20-some input lines plus 8 bi-directional lines. Does lower than 470 Ohms seem more practical? Something like 400 to 800 nsec is the period of a valid 'compare' time. I didn't write down existing rise/fall times; my bad.
I'm thinking it might be rise-time getting involved; have scoped them and there is visually some R-C involved on these lines. I know many LS TTL parts don't output 5v levels, and with loading (3.6v Prop output clamped to Vcc -- 470 Ohm -- TTL) the high state voltage wouldn't be anywhere near 5v.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko