What does Mode %10011 actually measure? Incorrect results?

I have set this mode for %00, or A-input rise to B-input rise. When I set the X register for 1 count, the time from the first rising edge of A to the first rising edge of B, the measured time between these points on a logic analyzer, and the reported time via the Z register, match well.

When I change to X = 2 for measurement over two cycles, the measurements do not agree. Measured on a logic analyzer, the period from the first rising edge of the A input to the second rising edge of the B input comes to 1.391 sec. The hex value at the second rising edge of the B input calculates to yield 0.640 seconds.

What does this mode actually measure? What have I mixed up? --Jon

Comments

  • You'll need to cycle A-input twice as well. Set both inputs to the same pin for ease of testing.

  • JonTitus wrote: »
    ...What does this mode actually measure? What have I mixed up? --Jon
    Please post the code that demonstrates this.

  • Here you go, LarryVC, and others. Comments welcomed. --Jon
    ' Mode 10011  %100
    ' Synchronous serial transmission (SPI) of system-clock periods, Rev. 1, 06-22-2020 at 1100H MDT
    ' Data:  Positive edge on the SPI clock (Jon Titus)
    
    CON
            clkout   = 40	  ' Pin P40       'Transmitter's clock out, to P31
    	txout    = 41     ' Pin P41       'Transmitter data out, to P30
            A_in     = 53     ' Pin P53
    	
    dat	
    	org 0      
    	dirl    #clkout				'Clock output setup
            wrpin	clock_mode,       #clkout       'Set pin as transition-output mode
    	wxpin	##$1000,          #clkout       'Set base period for transition output
    	dirh	#clkout                         'Enable clock-output
    
            dirl    #txout				'Transmitter setup
            wrpin	sync_tx_mode,     #txout        'Set sync tx mode for pin 41
    	wxpin	#%1_11111,        #txout	'Set up stop/start mode, X[5] = 1, 32 bits (31 + 1)
    	dirh	#txout			        'Enable transmitter output
    	
            dirl   #A_in	                        'Use A_in, pin 53
    	wrpin  A_in_mode,       #A_in           'Set up mode for pin P53     
            wxpin  ##$2,	#A_in		        'Wait for $ (number) events
            wypin  ##%00,           #A_in           'Count A-input high states
            dirh   #A_in                            'Enable Smart Pin
    	
    .test_loop	nop
    		testp #A_in  wc
       if_nc        jmp #.test_loop               'If C=0 wait for logic-1
                    rdpin pin_data, #A_in          'C = 1, so save count
                    wypin pin_data, #txout         'send count out via SPI
    	        wypin #64,  #clkout           'Start clock, transmit data
                    jmp #.test_loop                                
    
           
    '=====================================
    
    A_in_mode       long  %0000_0001_000_0001000000000_00_10011_0
    
    pin_data	long	0       
    
    sync_tx_mode    long  %0000_1111_000_0000000000000_01_11100_0	'Positive-edge clock mode
    
    clock_mode	long  %0000_0000_000_000000_0_000000_01_00101_0	'Clock-mode
    
    '====================================
    
  • Here's a drawing of my logic-analyzer signals (not to scale) with the hex value from the transmitted data on the right and times backwards from that point of reference. The hex value produces a period of 0.756 sec., but that doesn't match any of the times I measured. Maybe I misunderstand the points at which the measurements start and finish or how to interpret them. Or what happens to the count. I did connect the B and A signals to the A input and the data obtained is correct. I spent an afternoon testing this timing and just can't figure it out. Any help appreciated. Thanks. --Jon
    1633 x 847 - 95K
  • jmgjmg Posts: 14,372
    edited 2020-06-22 - 21:59:36
    Can you measure the times more precisely ?

    That looks to be very close (< 1%) to what I expect from this
    0.372+(1.47-1.08) = 0.762

    ie that is timing (A _/= to B _/=) and it collects that twice, over two reading bursts.
    Measured on a logic analyzer, the period from the first rising edge of the A input to the second rising edge of the B input comes to 1.391 sec.

    You seem to be thinking it times from A _/= to second B edge ?, which is not how it works.
    It is X sums of dT(A _/= to B _/=) so gives the averaged time interval (A _/= to B _/=) when divided by X

    You can think of CountEnable signal as being a Set-Reset Flipflop here, and it Sets on A _/= and Resets on B _/=
    X determines how many times that repeats, before it captures the total, and reports


    A common use for this could be time of flight measurements, where phase delay of an echo determines distance.
    Provided there is some noise on the signal, averaging can improve the LSBs
  • Thanks, jmg! Very helpful. So it's (1.47 - 1.08) + (0.390 - 0.00) = 0.762 sec. vs 0.756 measured on my Logic Analyzer. I doubt I can get better measurements. I thought it was a measurement from one end result to the next end result as shown on my diagram as Data Out via SPI. I'll draw a new diagram for the Prop-2 Smart-Pin docs revision. All the best. --Jon
  • evanhevanh Posts: 9,642
    edited 2020-06-24 - 06:16:42
    Jon,
    It will be cleaner looking timings with a round frequency for the sysclock rate. For that you'll need to engage the crystal oscillator instead of living on the default RCFAST oscillator.

    The minimum is a two step process of start up the crystal, then pause for it to stabilise, then switch over from RCFAST to the crystal or PLL.

    eg: Tack this to the front of your examples:
    		hubset	##$0100_0000			'start up the crystal oscillator (still operating at RCFAST)
    		waitx	##25_000_000/100		'~10ms (at RCFAST) for oscillator to stabilise
    		hubset	##$0100_0002			'engage!  Switch to 20 MHz oscillator
    

    Note: This depends on the PLL not being engaged already. There is a small hardware flaw that makes the PLL tricky to readjust when already in use. The default is RCFAST, so the simplest three liner is okay for examples like this.


    EDIT: corrected the encoded number.
  • JonTitus wrote: »
    Thanks, jmg! Very helpful. So it's (1.47 - 1.08) + (0.390 - 0.00) = 0.762 sec. vs 0.756 measured on my Logic Analyzer.
    That's interesting. I may have misunderstood those two functions the same as you. It looks like Chip's naming of "time" and "states" is flipped compared to what I thought. I figured "time" naming as an interval measurement but it looks like it may be the accumulate mode instead, which makes "states" the interval mode. I haven't actually tested all the counter modes ...

  • jmgjmg Posts: 14,372
    evanh wrote: »
    JonTitus wrote: »
    Thanks, jmg! Very helpful. So it's (1.47 - 1.08) + (0.390 - 0.00) = 0.762 sec. vs 0.756 measured on my Logic Analyzer.
    That's interesting. I may have misunderstood those two functions the same as you. It looks like Chip's naming of "time" and "states" is flipped compared to what I thought. I figured "time" naming as an interval measurement but it looks like it may be the accumulate mode instead, which makes "states" the interval mode. I haven't actually tested all the counter modes ...

    Time is an interval measurement, but here it measures time-interval over multiple X captures, so that means it accumulates X times, and delivers the answer on the final X measurement cycle.
    In HW terms it is an Edge Set-Reset Flip flop -> Count Enable and the result is given after X Count Enables.

    My Frequency counter here has Time-Interval (single measurement) and Time-Interval-Average (totals over N captures, then /N) so you can also think of this (X > 1) as a Time-Interval-Average, just before the final /X

    I avoid the word 'states' totally, and prefer to use Count Enable instead, as that is more accurately descriptive of what the hardware actually does.

  • jmg wrote: »
    Time is an interval measurement, but here it measures time-interval over multiple X captures, so that means it accumulates X times, ...
    Which is why I call that an accumulation. There's not one interval but many and each individual interval has its own value.

    I've almost certainly got a few mode numbers that need swapped between the interval and accumulate groups.

  • evanhevanh Posts: 9,642
    edited 2020-06-27 - 08:21:32
    Hmm, things aren't as I expected at all. Here's the smartpin setup and bit-bashed sequence for A (tpin) and B (tpin+1) smartpin inputs:
    		org
    sequence
    		drvl	#tpin+1
    		fltl	#tpin				'set DIR low, and ensure OUT is low when smartpin is enabled
    		wrpin	tpin_mode, #tpin
    		wxpin	#50, #tpin			'50 pulses
    		wypin	#%00, #tpin			'rise to rise
    		dirh	#tpin				'enable smartpin
    
    .loop
    		outnot	#tpin
    		waitx	#500-4
    		outnot	#tpin+1
    		waitx	#500-8
    		jmp	#.loop
    
    
    'tpin_mode	long	SPM_ACC_PULS | SP_OUT
    tpin_mode	long	SPM_ACC_PULS | SP_OUT | BF_PLUS1
    
    '	SPM_TIM_PULS	= %10011_0		' interval: of X number of A-B pulses/steps
    '	SPM_ACC_PULS	= %10100_0		' accumulate: pulses/steps, of X number of A-B pulses/steps
    

    On the scope it's a simple quadrature (A input is blue, B input is orange):
    pin_lat0057.PNG


    The reported SPM_TIM_PULS measurement (with input B=A) followed by the delta in GETCT, repeating indefinitely.
      100000  100000
      100000  100000
      100000  100000
      100000  100000
    ...
    

    The reported SPM_ACC_PULS measurement (with input B=A) followed by the delta in GETCT, repeating indefinitely.
       50000  100000
       50000  100000
       50000  100000
       50000  100000
    ...
    

    All good so far. First case is the total interval of 50 pulses matching exactly how long it actually took. Second case is 50% duty (for tpin) of that same interval as per my bit-bashed sequence.


    Now same again but with tpin+1 as the smartpin B input:
    SPM_TIM_PULS measurement (with input B=A+1)
       25000  100000
       25000  100000
       25000  100000
       25000  100000
    ...
    
    Already not as I expected since this should still be the total interval of all 50 pulses. Obviously it's only giving me the accumulated highs of the pulses.


    SPM_ACC_PULS measurement (with input B=A+1)
       25050  100000
       25050  100000
       25050  100000
       25050  100000
    ...
    
    This one, however is the strangest of all. How does 25050 fit anything about the 50 pulses? There's a +1 sysclock on each accumulated pulse or something.

    640 x 480 - 8K
  • jmgjmg Posts: 14,372
    evanh wrote: »
    Hmm, things aren't as I expected at all. Here's the smartpin setup and bit-bashed sequence for A (tpin) and B (tpin+1) smartpin inputs:

    Now same again but with tpin+1 as the smartpin B input:
    SPM_TIM_PULS measurement (with input B=A+1)
       25000  100000
       25000  100000
       25000  100000
       25000  100000
    ...
    
    Already not as I expected since this should still be the total interval of all 50 pulses. Obviously it's only giving me the accumulated highs of the pulses.

    That looks ok to me, as it is 50 sums of ( time interval A_/= to B/=) being quadrature, it should be 25% of elapsed time.
    If you swap the quadrature phase, I'd expect 75% of elapsed time
    evanh wrote: »
    SPM_ACC_PULS measurement (with input B=A+1)
       25050  100000
       25050  100000
       25050  100000
       25050  100000
    ...
    
    This one, however is the strangest of all. How does 25050 fit anything about the 50 pulses? There's a +1 sysclock on each accumulated pulse or something.

    It does seem to have a off-by-1 effect on gated mode. If you flip the quad phase, is it then 75050 ?
    Maybe that's an artifact of pin delays, with a partial clock getting thru and being counted. Gated counters are prone to that, whilst capture counters avoid it, as the clock is not gated.

  • jmg wrote: »
    That looks ok to me, as it is 50 sums of ( time interval A_/= to B/=) being quadrature, it should be 25% of elapsed time.
    The difference between the two modes is what exactly? They're both variations on accumulation I guess.

  • evanhevanh Posts: 9,642
    edited 2020-06-27 - 10:52:59
    jmg wrote: »
    evanh wrote: »
    ...
    SPM_ACC_PULS measurement (with input B=A+1)
       25050  100000
       25050  100000
       25050  100000
       25050  100000
    ...
    
    This one, however is the strangest of all. How does 25050 fit anything about the 50 pulses? There's a +1 sysclock on each accumulated pulse or something.

    It does seem to have a off-by-1 effect on gated mode. If you flip the quad phase, is it then 75050 ?
    Maybe that's an artifact of pin delays, with a partial clock getting thru and being counted. Gated counters are prone to that, whilst capture counters avoid it, as the clock is not gated.

    New sequence:
    		org
    sequence
    		drvl	#tpin+1
    		fltl	#tpin				'set DIR low, and ensure OUT is low when smartpin is enabled
    		wrpin	tpin_mode, #tpin
    		wxpin	#50, #tpin			'50 pulses
    '		wxpin	##50_000, #tpin
    		wypin	#%00, #tpin			'rise to rise
    		dirh	#tpin				'enable smartpin
    
    .loop
    		outnot	#tpin+1
    		waitx	#500-4
    		outnot	#tpin
    		waitx	#500-8
    		jmp	#.loop
    

    New scope snap:
    pin_lat0058.PNG


    The first two cases give exact same results of 50000 and 100000 respectively. The second two cases give the following:

    SPM_TIM_PULS measurement (With input B=A+1) we get the inverted duty, as you'd expect now:
       75000  100000
       75000  100000
       75000  100000
       75000  100000
    ...
    


    SPM_ACC_PULS measurement (With input B=A+1) is different again and also doesn't have the +50 any longer:
       50000  100000
       50000  100000
       50000  100000
       50000  100000
    ...
    
    640 x 480 - 8K
  • evanhevanh Posts: 9,642
    edited 2020-06-27 - 10:53:15
    Here's the main reporting loop, btw:
    _main
    		coginit	#1, #@sequence
    		mov	bcdlen, #8
    		setse1	#E_PIN_RISE | tpin
    .loop
    		waitse1
    		rdpin	pa, #tpin
    		getct	misc1
    		call	#itod
    		mov	pa, misc1
    		sub	pa, misc2
    		add	misc2, pa
    		call	#itod
    		call	#putnl
    		jmp	#.loop
    

    And an actual terminal dump (I remove the first measurement line because the first CT delta is not setup):
    Total smartpins = 64   1111111111111111111111111111111111111111111111111111111111111111
    Rev B silicon.  Sysclock 2.0000 MHz
       5000022442356
       50000  100000
       50000  100000
       50000  100000
       50000  100000
       50000  100000
       50000  100000
       50000  100000
       50000  100000
       50000  100000
       50000  100000
       50000  100000
    ...
    
  • jmgjmg Posts: 14,372
    edited 2020-06-27 - 20:18:04
    evanh wrote: »
    SPM_TIM_PULS measurement (With input B=A+1) we get the inverted duty, as you'd expect now:
       75000  100000
       75000  100000
       75000  100000
       75000  100000
    ...
    
    That makes sense, and follows an Time_Interval_Gate = edge Set/Reset flipflop front end

    evanh wrote: »
    SPM_ACC_PULS measurement (With input B=A+1) is different again and also doesn't have the +50 any longer:
       50000  100000
       50000  100000
       50000  100000
       50000  100000
    ...
    

    Hmm... That saturates at 50%, but can reduce, so it seems that mode is (Time_Interval_Gate) & PinA
    ie it ANDs the PinA signal with the gate signal.
    Not sure what the practical use of that is ?

    Sounds like if you want to extract Period and Duty from A-B interval tests, you should use two edge modes, as those will always add to 100% of the time-interval.
  • Too much guessing ... Chip! Where are you? Help!

Sign In or Register to comment.