WAITPEQ questions;
·After quite a while away from this problem, I'm now running on an Intel iMac, Parallels virtual machine, and Window XP.· Phew!· But it's working.
·OK, there must be something I don't comprehend with WAITPEQ.· Using ViewPort to check the signals expected on INA, and PASD to step through this little bit of code, I find all working properly except the WAITPEQ.·
·PASD shows the proper paddr and BAcomp walues, but on Stepping, once it gets into the WAITPEQ it hardly ever triggers.· Only by hitting the Key, F8 = Step, time after time· it runs, on next F8, then hangs, then runs and finally might trigger after many many F8s.· If I hit F5, it Runs and never triggers.· When I say it 'runs', that is the indication of the PASD 'LEDs' on the I/O lines.· For some reason PASD doesn't seem to help debugging with this instruction.
·Reading the Prop manual, it seems the WAITPEQ would be 'easy'.· But I must not be doing things proper.· Anyone spot the error of my ways?![yeah.gif](http://forums.parallax.com/images/smilies/yeah.gif)
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
Post Edited (Harley) : 3/7/2008 2:00:59 AM GMT
·OK, there must be something I don't comprehend with WAITPEQ.· Using ViewPort to check the signals expected on INA, and PASD to step through this little bit of code, I find all working properly except the WAITPEQ.·
·PASD shows the proper paddr and BAcomp walues, but on Stepping, once it gets into the WAITPEQ it hardly ever triggers.· Only by hitting the Key, F8 = Step, time after time· it runs, on next F8, then hangs, then runs and finally might trigger after many many F8s.· If I hit F5, it Runs and never triggers.· When I say it 'runs', that is the indication of the PASD 'LEDs' on the I/O lines.· For some reason PASD doesn't seem to help debugging with this instruction.
·Reading the Prop manual, it seems the WAITPEQ would be 'easy'.· But I must not be doing things proper.· Anyone spot the error of my ways?
![yeah.gif](http://forums.parallax.com/images/smilies/yeah.gif)
org 0 entry ' --------- Debugger Kernel add this at Entry (Addr 0) --------- long $34FC1202,$6CE81201,$83C120B,$8BC0E0A,$E87C0E03,$8BC0E0A ' <===== for PASD long $EC7C0E05,$A0BC1207,$5C7C0003,$5C7C0003,$7FFC,$7FF8 ' -------------------------------------------------------------- BAbusRd or DIRA,INTRmsk ' set /INTR pin to output or OUTA,INTRmsk ' set HI loop1 waitpne BM1mask,BM1mask ' wait for BM1 LO level pg 413 mov paddr,PAR wc ' get parameter address pg 380 rdlong BAcomp,paddr ' get value @SBPt pg 395 waitpeq BAcomp,BAbusMask ' wait for breakpoint compare pg 412 andn OUTA,INTRmsk ' output negative pulse pg 417 or OUTA,INTRmsk ' (for INTR/ signal ) pg 392 jmp #loop1 ' TESTING; loop forever ' cogid :id ' these two s/b used in final form ' cogstop :id ' ' ' Initialized data ':id LONG 0 INTRmsk LONG |<19 ' mask for /INTR on A19/pin 24; REALLY S/B on A21/pin 26 BM1mask LONG $0001_0000 ' mask for only BM1 pin (A16) BAbusMask LONG $0001_FFFF ' BM1 + 16 addr bits mask ' Unitialized data FOR 'BAbusRd' paddr RES 1 ' for passing address of parameter BAcomp RES 1 ' holds 'breakpoint' address value; compare w/ BAbus value FIT 496
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
Post Edited (Harley) : 3/7/2008 2:00:59 AM GMT
Comments
I have tested your code in PASD, and it works exactly how it should. If the INA value ANDed with $1FFFF not matches the value in the PAR register (or paddr in your code) then waitpeq waits. When the values matches, then the next instruction is executed. This works with Single step (F8) or with Run (F5) and a Breakpoint after watpeq.
So something with the value that you expect on INA or the value that you pass in PAR must be wrong.
Andy
I don't know how you simulated the inputs, nor whether the timing relationships are even close. The signals are coming from a Z80 running at 2.5 MHz in my case.
Hopefully, you've provided some clue as to where to look.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
Yes, my timing was not very close to 2.5 MHz more to DC [noparse];)[/noparse]
IMHO a Propeller @ 80MHz should not have problems with testing a signal that changes with 2.5 MHz.
But for debugging such high rates with PASD, It's better to use only Breakpoints (no single steps).
Andy
The WAITPEQ works fine, note we had a HUGE discussion about it three months ago, where it turned out that the manual is not that correct. Parallax says now that flags are UNDEFINED for WAITPEQ/NE.
There is more interesting info in that thread!
You both talked of PAR and "paddr" when you mean "BAcomp".
Note that
MOV paddr,PAR wc
is a little bit useless: RDLONG can do it just alone, and C is not used, and could NEVER have been of any use at all.
But that is not an error.
As Ariba, I should say that your parameters just do not match...
We can't see...
Yes, PAR and paddr are the pointers and BAcomp contains finaly the value.
But I don't agree with:
I think Harley use this to clear the Carry Flag, and the Carry flag selects between INA and INB for WAITPxx in future Propeller Chips. It's not wrong to include the correct Carry already, also if the Propeller 1 don't need it.
Andy
I am 100% sure Harley did not intend what you say, but I might err
I was just talking about the code as such - as you do as well... This has all nothing to do with the issue...
Post Edited (deSilva) : 3/7/2008 4:28:24 PM GMT
After reading over the Spin and assembly WAITPEQ instruction many times, I finally noted that C=x would eventually be used. So added it the last time but it didn't help; so it is there.
I haven't yet tried, but using RDLONG rather than that MOV to get the desired value will be the next try, deSilva.
This WAITPEQ seemed so simple, yet hasn't been with the learning curve of the Prop instructions. But I'm not giving up. And yes part of the long thread on WAITPEQ was because of me, last year. I went on to other areas to debug in the meantime.
Thanks all for guidance.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Harley Shanko
please understand! We have the well founded suspicion that the code you posted here is o.k.
So it will not help messing around with it.
There are two possibilities
- you provide the wrong trigger value
- the hardware does not give the right value.
To check this you need a DEFINED pattern generator for the input.
This is one of the things where the propeller is extremely good with: It's just
in another COG....