WAITPEQ questions;

Harley

·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?

              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

Ariba

Harley

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

Harley

Thanks 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

Ariba

I've simply read the value on INA and set then the paddr value equal to the lower 17 Bits of INA to test a match. Then I changed a single Bit with a Switch to test a No-Match - the WAITPEQ stopped, then I changed the Switch back, and the code continued to the Breakpoint.
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

deSilva

I don't want to interfer with any PASD matter.... I personally did never encounter any problem with it..

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...

Ariba

deSilva

Yes, PAR and paddr are the pointers and BAcomp contains finaly the value.
But I don't agree with:

deSilva said...

...
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.

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

deSilva

Andy - this is not the first time you surprise me

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

Harley

@ Andy and deSilval,

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

deSilva

Harley,
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

  DIRA := $0001_FFFF
  REPEAT
      OUTA := ....

in another COG....