Shop OBEX P1 Docs P2 Docs Learn Events
Smartpin "Quadrature Encoder" mode returns erratic values — Parallax Forums

Smartpin "Quadrature Encoder" mode returns erratic values

ozpropdevozpropdev Posts: 2,793
in Propeller 2
Chip
I been experiencing weird behaviour of the smartpins in quad. enc mode.
At first I thought it might be faulty encoders, so I replaced them.
The issue persisted so I have removed them and implemented fake ecoders in another cog.
The issue remained so I did a few tests and found that the issue seems to be related to the period between PINGETZ instructions.
in the included code the fake encoder cycles back and forth at low speed and displays the Z value spaced by its lower bits.

If the WAITX instruction @ main is enabled the following output is returned (Correct). 
                       00001862
                       0000185A
                      00001856
                    0000184E
                  00001846
                 00001842
               0000183A
             00001832
           0000182A
          00001826
        0000181E
      00001816
     00001812
       0000181A
         00001822
          00001826
            0000182E
              00001836
               0000183A
                 00001842
                   0000184A
                     00001852
                      00001856
                        0000185E
                          00001866
When the WAITX @ main is removed erratic behaviour is observed. 
 00000000
                0000023E
                 00000242
                   0000024A
                     00000252
 00000000
                        0000025E
 00000000
                            0000026E
                             00000272
                               0000027A
                                 00000282
 00000000
                              00000276
 00000000
                          00000266
                         00000262
                       0000025A
                     00000252
 00000000
                  00000246
 00000000
              00000236
             00000232
           0000022A

The results vary on each download.
The test code has been running on a P123-A9 board.




Comments

  • cgraceycgracey Posts: 14,287
    I'm glad you found this!

    I'm looking into it right now.
  • cgraceycgracey Posts: 14,287
    edited 2016-04-18 22:25
    It seems to work okay on my end. Try this A9 program and see if it works okay. Use PB3 and PB2 to simulate the encoder inputs:
    dat		org			'cog program

.init		pinsetm	pm,#7		'smart pin 7 is encoder (reads 8 and 9)
		pinsetx	#0,#7

		or	dira,##$3FF	'enable smart pin 7 and pins 9..0
.loop
		testb	inb,#27 wc	'copy pushbutton 3 to pin 9
		setbnc	outa,#9

		testb	inb,#26 wc	'copy pushbutton 2 to pin 8
		setbnc	outa,#8

		pingetz	x,#7		'read encoder and output to pins 7..0
		setbyte	outa,x,#0

		jmp	#.loop


pm		long	%0001_0010_000_0000000000000_01_10000_0
x		long	0
  • jmgjmg Posts: 15,194
    edited 2016-04-18 22:42
    cgracey wrote: »
    It seems to work okay on my end.

    You mean you checked the code in #1 and it ran 100% ?

    Looking at the code, the delay patch seems to be in an unexpected place, (ie the loop has already taken many cycles sending data, why should a few more matter ? ), and it seems the counter itself is ok, just the read sometimes gets 00 by mistake.
    The patch is right after a jump, could there be some interaction between pipeline and opcodes like pingetz ?
    Is there enough timing margin in the FPGA's ?

    OzPropdev: What range of delays is a fix, and does one or more NOP also fix ?

    Addit: I also notice that failure seems periodic - it is always NYNYYYY ?
    Could the loop time not be N*16 and so a variable phase on COG slot is occurring ?
    ( that would mean some NOPs could fix, and more NOPs could break again )
  • ozpropdevozpropdev Posts: 2,793
    I ran some more tests this morning and might have another clue.
    I fired up my DE2-115 board just as a point of reference.
    Because the DE2 only has 8 snartpins and no smartpin on pin 62(Tx) I replaced the Tx code with a bit bang variant.
    Code works fine with/without WAITX delay.
    At first I thought this might be a Cyclone 4/5 timing difference.
    Running the bit bang variant back on the A9 board and now everything works.
    It seems to be a smartpin message issue from the async tx mode that upsets the quad mode smartpin?
    spin
    spin
    quad_enc_test_serial_2.spin
    2K
  • jmgjmg Posts: 15,194
    ozpropdev wrote: »
    It seems to be a smartpin message issue from the async tx mode that upsets the quad mode smartpin?
    You mean interleaved pingetz's get confused ?
    The loop delay is likely also not exactly the same, so you could try inserting back dummy pingetz, and see if that
    always breaks, no matter where it is inserted ?

  • ozpropdevozpropdev Posts: 2,793
    Huh?
    I setup another smartpin in async mode but only ever reference it wuth a PINGETZ.
    		pingetz	dummy,#tx_pin2 wc
		pingetz	temp,#fake		'read encoder count
    Works fine but 
    		pingetz	temp,#fake		'read encoder count
		pingetz	dummy,#tx_pin2 wc
    does not (erratic quad. enc values), but a combination of the two 
    		pingetz	dummy,#tx_pin2 wc
		pingetz	temp,#fake		'read encoder count
		pingetz	dummy,#tx_pin2 wc
    works fine. ?????
    I'm still thinking it's some sort of smartpin messaging issue.
  • jmgjmg Posts: 15,194
    Is that failing case still the first opcode after a jump ? (aka jump destination)
  • ozpropdevozpropdev Posts: 2,793
    jmg wrote: »
    Is that failing case still the first opcode after a jump ? (aka jump destination)
    Yes, but I have placed a bunch of instruction before the PINGETZ and it made no difference.


  • jmgjmg Posts: 15,194
    Does this simpler test, also fail the same way on the DE2 ?
  • ozpropdevozpropdev Posts: 2,793
    jmg wrote: »
    Does this simpler test, also fail the same way on the DE2 ?
    Same result on DE2 as A9.

    One thing I did discover is that if I assign my dummy async Tx smartpin to a non existant smartpin the issue goes away.
    So the code combination #2 now works on DE2-115.
  • jmgjmg Posts: 15,194
    edited 2016-04-19 02:01
    ozpropdev wrote: »
    Same result on DE2 as A9.

    Starts to look less like some marginal FPGA issue....
    ozpropdev wrote: »
    One thing I did discover is that if I assign my dummy async Tx smartpin to a non existant smartpin the issue goes away.
    Maybe that just becomes a NOP ? - Chip will know how different a no-pin-there opcode is.

    If you do 2 consecutive 'read encoder count' pingetz's, do they both have a failure pattern, or only the first one ?
  • ozpropdevozpropdev Posts: 2,793
    edited 2016-04-19 03:33
    Chip
    I modified your test code slightly to display the encoder value on the A9's green leds.
    By adding a async smartpin into the mix breaks your code too.
    Particulary on rollover.
    con
	sys_clk = 80_000_000
	tx_pin = 62
	baudrate = 115_200
	nco_baud = round(float($1_0000) / (float(sys_clk) / float(baudrate)))

dat		org			'cog program

.init		
		pinsetm	#%1_11110_0,#tx_pin
		pinsetx	##$8000_0000 | nco_baud << 16 | %1_00000 | 7,#tx_pin
		setb	dira+tx_pin>>5,#tx_pin

		pinsetm	pm,#7		'smart pin 7 is encoder (reads 8 and 9)
		pinsetx	#0,#7
		setb	dira,#7
		setb	dira,#8
		setb	dira,#9

		or	dirb,##$ffFF	'enable green leds
.loop
		testb	inb,#27 wc	'copy pushbutton 3 to pin 9
		setbnc	outa,#9

		testb	inb,#26 wc	'copy pushbutton 2 to pin 8
		setbnc	outa,#8
		pingetz	x,#7		'read encoder and output to pins 7..0
	'	pingetz	adra,#tx_pin wc   '<<<< causes invalid encoder values
		setword	outb,x,#0

		jmp	#.loop

pm		long	%0001_0010_000_0000000000000_01_10000_0
x		long	0

    Edit: Same outcomes are observed using the three variants mentioned above.
    As long as there is a Async PINGETZ before the ENC PINGETZ it works?
  • cgraceycgracey Posts: 14,287
    I didn't realize there was an initial program posted, as jmg pointed out. Anyway, now that we know what circumstance elicits the problem, it will be much easier to identify. I'll be on it shortly.
  • cgraceycgracey Posts: 14,287
    edited 2016-04-19 06:26
    Okay!

    Ozpropdev, I got it to fail using your last program posted.

    I see the problem. On the first clock of the GETPINZ instruction, it's reading the smart pin that was the object of the prior PINSETM/PINSETX/PINSETY/GETPINZ instruction. If that smart pin happens to be outputting a message header, the cog starts reeling in a message, starting on the next clock, from what is then the correct smart pin. So, it's sometimes using a wrong message header with the right pin, causing registration and sizing errors. Sorry about this. I should have thought this through better.

    I'm fixing it now.

    I'm sure glad you guys find things like this.

    Jmg, you have the scariest imagination - a pipeline bug! There could be such things lurking, but, hopefully, we've weeded those out, already. Good guess, anyway.
  • jmgjmg Posts: 15,194
    cgracey wrote: »
    Jmg, you have the scariest imagination - a pipeline bug! There could be such things lurking, but, hopefully, we've weeded those out, already. Good guess, anyway.
    The symptoms did not quite fit a simple alternate-read / leading hangover issue, so I had to imagine deeper...
    Good if you have nailed it.


  • cgraceycgracey Posts: 14,287
    It's fixed.

    I'm starting up an A9 compile now.
  • ozpropdevozpropdev Posts: 2,793
    cgracey wrote: »
    It's fixed.

    I'm starting up an A9 compile now.
    Thanks Chip.
    It's nice when it's a quick fix. :)

  • cgraceycgracey Posts: 14,287
    ozpropdev wrote: »
    cgracey wrote: »
    It's fixed.

    I'm starting up an A9 compile now.
    Thanks Chip.
    It's nice when it's a quick fix. :)

    The fix was maybe 10 minutes, but the compile takes 2 hours.
  • cgraceycgracey Posts: 14,287
    Here is a new Prop123_A9_Prop2_v8a.rbf:

    https://drive.google.com/file/d/0B9NbgkdrupkHby0xV0tsU3ZJZXM/view?usp=sharing
  • jmgjmg Posts: 15,194
    cgracey wrote: »
    Here is a new Prop123_A9_Prop2_v8a.rbf:

    Any summary of what else changed ?
    Dual-port LUT ? Better capture-mode controls ?

  • cgraceycgracey Posts: 14,287
    jmg wrote: »
    cgracey wrote: »
    Here is a new Prop123_A9_Prop2_v8a.rbf:

    Any summary of what else changed ?
    Dual-port LUT ? Better capture-mode controls ?

    Dual-port LUT and phase setting in NCO mode. I'll document these things as soon as they are done and I'll make a new release.
  • ozpropdevozpropdev Posts: 2,793
    cgracey wrote: »
    Here is a new Prop123_A9_Prop2_v8a.rbf:

    https://drive.google.com/file/d/0B9NbgkdrupkHby0xV0tsU3ZJZXM/view?usp=sharing

    Thanks Chip.
    V8a running very nicely.
    Cheers
    Brian
Sign In or Register to comment.