What does Mode %10011 actually measure? Incorrect results?
JonTitus
Posts: 193
in Propeller 2
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
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
' 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 '====================================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.
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
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:
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.
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.
I've almost certainly got a few mode numbers that need swapped between the interval and accumulate groups.
On the scope it's a simple quadrature (A input is blue, B input is orange):
The reported SPM_TIM_PULS measurement (with input B=A) followed by the delta in GETCT, repeating indefinitely.
The reported SPM_ACC_PULS measurement (with input B=A) followed by the delta in GETCT, repeating indefinitely.
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) 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) 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.
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
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:
New scope snap:
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:
SPM_ACC_PULS measurement (With input B=A+1) is different again and also doesn't have the +50 any longer:
And an actual terminal dump (I remove the first measurement line because the first CT delta is not setup):
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.