waitpeq/waitpne help please

Lafet · 2007-10-24 21:22

Hi, can you help me please?


CON
        _clkmode        = xtal1 + pll16x
        _xinfreq        = 5_000_000

        in_pin = 6

VAR

  long Index
                  
PUB start

Index := 0
dira[noparse][[/noparse]20]~~
outa[noparse][[/noparse]20]~
coginit(6,@entry, @index)
repeat 

DAT
       ORG   0

entry

:det_pulse
        mov             _count, #6
        mov             _tmp_count, _count
        jmp             #:det_pulse_loop
:det_pulse_cnt
        cmp             _tmp_count, #6  wz
 if_z    mov             _count, #7              
 if_nz  mov             _count, #6
          mov             _tmp_count, _count
:det_pulse_loop

        waitpeq         _null, #in_pin
        waitpne         _null, #in_pin

        djnz            _count, #:det_pulse_loop

        rdbyte          _temp, par 
        add             _temp, #1   
        cmpsub       _temp, #6   
        wrbyte         _temp, par 
        jmp             #:det_pulse_cnt

_null   long  0

_temp   res   1
_count  res   1
_tmp_count    res       1

Why waitpeq don't work?
Function: waiting 0 -> 1 -> 0 on P6.

Very thanks, Lafet

deSilva · 2007-10-24 21:30

WAITPEQ and WAITPNE take a complete 32 bitpattern as parameter not the portnumber. You have also to state the MASK correctly, also 32 bits long.

When using I/O #6 you can still use immediate addressing #%100_0000 or - better! - # |<in_pin

Lafet · 2007-10-24 21:42

waitpeq         _null, #|<in_pin
waitpne         _null, #|<in_pin

waitpeq         _null, #%100_0000
waitpne         _null, #%100_0000

waitpeq         %100_0000, #%100_0000
waitpne         %100_0000, #%100_0000

...don't work

Post Edited (Lafet) : 10/24/2007 10:10:50 PM GMT

deSilva · 2007-10-24 21:53

I said:

deSilva said...
You have also to state the MASK correctly, also 32 bits long.

hippy · 2007-10-24 22:45

Lafet said...

waitpeq         %100_0000, #%100_0000
waitpne         %100_0000, #%100_0000

...don't work

You need a register in the destination field ...

mov             reg, #%100_0000
waitpeq         reg,reg
waitpne         reg,reg

deSilva · 2007-10-24 23:07

@Lafet: Just to explain it:
Alas, it is possible to write things like:

waitpne         %100_0000, ....

although it will make little sense to the human reader, except he is very unexperienced with the SPIN assembly language

For the assembler this is the clear instruction to use the mask stored at address number 64 of the COG - why not?

A VERY GOOD assembler would issue a
"WARNING: Unrecommended and most likely erronious use of bit-literal as register number!"

What do we learn from this? Don't use I/O pins below number 9

Post Edited (deSilva) : 10/24/2007 11:22:11 PM GMT

Timothy D. Swieter · 2007-10-24 23:21

All of the above is good info. I would add that the setup of the I/O (dira, outa, ina) be moved in to the assembly program. I won't recount each time I messed this up, it is more times than I care to share. The I/O for each cog needs to be setup. In the example above the cog running the spin portion of the program has its I/O setup, but then the assembly program is launched into another COG with its own I/O registers. By default the registers are all inputs, so sometimes not setting up the I/O won't show as a problem if you are using only inputs.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter
tdswieter.com

One little spark of imagination is all it takes for an idea to explode

deSilva · 2007-10-24 23:28

Thank you, Timothy.
This is the real reason why it won't even work with the latest try - and hippy and me would have been very, very surprised

Timothy D. Swieter · 2007-10-25 01:34

Thanks deSilva. There have been many times when you posted a response and duh it was so obvious how did I/the poster/the forum miss the problem. Glad I could beat you to it this time. Your help on the forums is appreciated.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Timothy D. Swieter
tdswieter.com

One little spark of imagination is all it takes for an idea to explode

Lafet · 2007-10-25 09:07

I'm adjusted programme, but also it don't work

entry
        mov             det_pin, #1
        shl             det_pin, #6
        andn            dira, det_pin
    
:det_pulse

...

:det_pulse_loop

        waitpeq         det_pin, det_pin
        waitpne         det_pin, det_pin

        djnz            _count, #:det_pulse_loop

...

det_pin   long 0
 
_tmp_count    res  1

hippy · 2007-10-25 12:59

Wrong pin used ?
Hardware connected to wrong pin ?
Signal not toggling ?
Signal toggling too fast ?
Incorrect signal voltages ?
_count not initialised correctly ?
That code not being executed ?
Other code error ?
Error in your data definitions ( res before long or before code ) ?

ErNa · 2007-10-25 14:47

In this case, You should post the complete program (if not too big). If too big: remove everything not necessary to produce this error.

Lafet · 2007-10-25 19:11

Full programme is at first benefit. After it only his adjustment. I replaced program part with waitpeq/waitpne following:

one
        mov             _temp, ina
        and             _temp, det_pin  wz
if_z    jmp             #one                    
null
        mov             _temp, ina
        and             _temp, det_pin  wz
if_nz   jmp             #null

and this way it works OK.

deSilva · 2007-10-26 07:11

Good to hear!
(a) You are now waiting the other way round 0->1 rather than 1-> 0 in your first postings
(b) You do not need the _temp

one
        and              det_pin,   INA  wz,NR
if_z    jmp             #one                    
null
        and              det_pin,   INA  wz,NR
if_nz   jmp             #null

mpark · 2007-10-26 18:02

(a) I don't think that's quite correct. 0->1 just gets past the first loop; the signal has to go 1->0 to leave the second loop, no?
(b) But why didn't this work?

        waitpeq         det_pin, det_pin
        waitpne         det_pin, det_pin

deSilva · 2007-10-26 19:42

mpark said...
(b) But why didn't this work?

Just because it's different..

hippy · 2007-10-27 01:12

Works ...

one
        mov             _temp, ina
        and             _temp, det_pin  wz
if_z    jmp             #one                    
null
        mov             _temp, ina
        and             _temp, det_pin  wz
if_nz   jmp             #null

Apparently doesn't work ...

        waitpeq         det_pin, det_pin
        waitpne         det_pin, det_pin

I have to admit that I cannot see the difference.

In the first case the 'one' loop is only left when ( INA & det_pin ) <> 0 and the 'null' loop is only left when ( INA & det_pin ) == 0. So it waits firstly for pin high then pin low.

I do not see any difference to how the waitpeq/waitpne proceeds - waits for pin high then waits for pin low, so I'm at a loss to explain why the first works but the second does not.

Mike Green · 2007-10-27 02:14

Hmmm. I cannot see the difference either.
There must be something else going on that you can't see from these fragments.
Are you literally substituting one for the other?

deSilva · 2007-10-27 09:17

I agree: no difference!
Both will wait for 1 -> 0
Sorry for having been slop(p)y!

Edit:
But I was a little bit confused as the very first solution was this:

waitpeq         _null, #%100_0000
waitpne         _null, #%100_0000

I have to look it up from time to time, "who is who":
its:
WAITP value, mask.

So this (reported: not working) example looked for 0 -> 1
Then it became a little bit confused... In fact DIRA wil have nothing to do with it, as input is default and - contrary to my former posting - this had no influence on it.....

Remains the last riddle: Two obviously equivalent programs behave differently...

Post Edited (deSilva) : 10/27/2007 1:23:31 PM GMT

hippy · 2007-10-27 13:42

deSilva said...
I agree: no difference!
Both will wait for 1 -> 0
Sorry for having been slop(p)y!

I was on my way to posting exactly as you did but caught myself before pressing send; "there but for the grace of God go I"

There has to be something else which is not being revealed. My gut suspicion is that the "waitpeq/waitpne" is not in the same order used in the code test.

waitpeq/waitpne help please

Comments