That's more detail than is suitable for a one-liner.
The most important part of my list is the classification clarification of what the type of measurement is: count, accumulate or interval.
I agree Counter / Timer (interval) info helps, but the word accumulate needs care.
Some modes I read as gated-timers, which may appear to accumulate during multi period readings, but some reset-on-capture, so using accumulate can confuse users.
Better would be Gated Counter/ Counter / Gated Timer / Timer, to use terminology that users of other MCU are used to.
Addit: maybe Period Timer and Gated Period timer are needed too, as P2 smart pins can do more than most MCU timer-blocks. A period timer includes edge-sync features.
Addit: maybe Period Timer and Gated Period timer are needed too, as P2 smart pins can do more than most MCU timer-blocks. A period timer includes edge-sync features.
I don't want to give any of them a timer label because they are primarily for external measuring of inputs. Where as a timer is more associated with simple metronomics for internal use.
%10000 = Time A-input low states and high states
%10001 = Time A-input high states
See questions above
Does this mode pair clear-on-capture ? Merely says "... and a new measurement begins"
Also vague is if this is 'gapless' ?
My guess is one period is consumed at each boundary, but it may be smart enough to capture & restart on the same edge, making capture X-Whole_Periods Time sums gapless, and equivalent to real time.
(with just a phase delay on the very first edge, after smart pin config/arming, after that, no lost time)
%10000 = Time A-input low states and high states
%10001 = Time A-input high states
See questions above
Does this mode pair clear-on-capture ? Merely says "... and a new measurement begins"
Also vague is if this is 'gapless' ?
My guess is one period is consumed at each boundary, but it may be smart enough to capture & restart on the same edge, making capture X-Whole_Periods Time sums gapless, and equivalent to real time.
(with just a phase delay on the very first edge, after smart pin config/arming, after that, no lost time)
It's gapless, of course. When the input transitions high, it signals for you to get the low time, and vice-versa. No measurement mode misses anything. Everything is gapless.
It's gapless, of course. When the input transitions high, it signals for you to get the low time, and vice-versa. No measurement mode misses anything. Everything is gapless.
That's good, does that include these modes ?
%10011 Time captured over X whole A-B periods. (Time to read is X periods)
%10100 is a gated version of that, A=H=Enable, so it gives a % of H time.
Gapless here needs the X edge that captures, to also be the edge that starts the next time-whole-X ?
The Smart Pin DOCs should include this important detailing.
Here's my most recent summary of the smartpin counter modes: <snip>
Suggest removing leading tab and one of the two before ' and space after ' to avoid/reduce sideways scrolling on smaller displays:
SPM_CNT_QUAD = %01011_0 'count: A-B quadrature encoder
SPM_CNT_UP_ENA = %01100_0 'count: A clock up, B enable
SPM_CNT_DIR = %01101_0 'count: A clock, B direction
SPM_CNT_UP = %01110_0 'count: A clock up
SPM_CNT_UP_DN = %01110_0 'count: A clock up, B clock down
SPM_ACC_UP = %01111_0 'accumulate: A up
SPM_ACC_UP_DN = %01111_0 'accumulate: A up, B down
SPM_TIM_STEP = %10000_0 'interval: of most recent step duration
SPM_TIM_PULSE = %10001_0 'interval: of most recent pulse duration
SPM_TIM_A = %10010_0 'interval: of X number of A accum/pulses/steps
SPM_TIMEOUT = %10010_0 'interval: since high/step
SPM_TIM_PULS = %10011_0 'interval: of X number of A-B pulses/steps
SPM_ACC_PULS = %10100_0 'accumulate: A up, of X number of A-B pulses/steps
SPM_TIM_OVER = %10101_0 'interval: until X time + A-B step
SPM_ACC_OVER = %10110_0 'accumulate: A up, until X time + A-B step
SPM_CNT_OVER = %10111_0 'count: pulses/steps, until X time + A-B step
Cripes, you must have a very small display there Tony. My browser is only 1280 wide with no scrolling needed ... and I've even got bulky fonts because it's all on a 4k monitor with those extra small pixels.
Cripes, you must have a very small display there Tony. My browser is only 1280 wide with no scrolling needed ... and I've even got bulky fonts because it's all on a 4k monitor with those extra small pixels.
1024x768 and your table fits perfectly with whitespace trimmed.
I recommend a 43" for your next monitor. I wish I'd waited a little longer until they were on the market. I guess I could have gone for a TV back then but I didn't really trust them, finding info like IPS construction is not generally available for TVs.
I recommend a 43" for your next monitor. I wish I'd waited a little longer until they were on the market. I guess I could have gone for a TV back then but I didn't really trust them, finding info like IPS construction is not generally available for TVs.
+1
Note that the "screen door" effect on TVs can be bad if used as a monitor, so definitely go for 4k.
EDIT2: Getting a handle on these modes means I'm reasonably sure that SPM_ACC_OVER can provide a synchronised pulse density measurement without any external clock. The tricky part will be in processing it, since the timebase becomes uncertain due to complete pulses determining each sample period.
I think introduction of new words here (step, pulse then step/pulse ?), that are not used in Chip's docs, will only confuse users.
Chip uses period in the DOCs, why not keep using that ?
Chip uses 'state' which is also confusing, when I think he really means gated, or 'enabled when hi' (working back from context)
Other MCUs talk about Timer/Counters/Capture and Gated (Timers or Counters), so those terms are already in common use, & best to use words that cross language barriers already.
The change to 'for at least X duration' is good here, as that shows the very important detail of whole periods.
SPM_TIM_OVER = %10101_0 ' interval: of A-B pulses/steps, for at least X duration
SPM_ACC_OVER = %10110_0 ' accumulate: A-B pulses/steps, for at least X duration
SPM_CNT_OVER = %10111_0 ' count: A-B pulses/steps, for at least X duration
but OVER means over what ? Better may be SPM_CNT_GEX for Greater than or equal to X aka for at least X duration.
FWIR Chip has designed most (all?) smartpin modes to clear-on-capture, and in a smart way. (if an edge was going to increment, on capture clock instant, clear is to 1 instead of 0, to not lose an edge)
That feature not showing yet in all pinmode sections docs, but is hinted at by ".. then the result will be placed in Z, while the accumulator will be set to the 0/1/-1 value that would have otherwise been added into it, beginning a new measurement"
That means 'accumulate' is going to rather confuse users, as nothing actually accumulates across readings. A better top level word than accumulate, is gated, which is what the HW actually does.
Gated modes will always have some duty related percentage of 100% of possible count, but otherwise acts the same as whole-period modes.
A merge of Chip's docs
%10101 = For periods in X+ clock cycles, count time
%10110 = For periods in X+ clock cycles, count states
%10111 = For periods in X+ clock cycles, count periods
and merge of the above, for clarity (removing words pulse/step/state) would give something like this
SPM_TIM_GEX = %10101_0 ' Time interval of N whole periods, for at least X duration (capture dT)
SPM_GAT_GEX = %10110_0 ' Gated time interval of N whole periods, for at least X (capture %dT)
SPM_CNT_GEX = %10111_0 ' Count of N whole periods, for at least X duration (capture dN)
Some examples:
Reciprocal Counting:
Two smart pins, in complementary modes of
SPM_TIM_GEX = %10101_0 ' Time interval of N whole periods, for at least X duration (capture dT)
SPM_CNT_GEX = %10111_0 ' Count of N whole periods, for at least X duration (capture dN) started in sync, with a nominal/min capture timebase of X, will give precise, no lost edges, continual readouts of Cycles and Time, for a reciprocal calculation of Freq = dN/dT, and a background rolling total of sum(dN)/sum(dT) will give very high precision frequency calculations.
Precision Duty:
Two smart pins, in complementary modes of
SPM_TIM_GEX = %10101_0 ' Time interval of N whole periods, for at least X duration (capture dT)
SPM_GAT_GEX = %10110_0 ' Gated time interval of N whole periods, for at least X (capture %dT) started in sync, with a nominal/min capture timebase of X, will give precise, no lost edges, continual readouts of %dT and dT, for a Duty calculation of Duty= %dT/dT, and a background rolling total of sum(%dT)/sum(dT) will give very high precision Duty.
Simpler Duty:
With a good stability Duty source, one smart pin can alternate
SPM_TIM_GEX = %10101_0 ' Time interval of N whole periods, for at least X duration (capture dT)
with
SPM_GAT_GEX = %10110_0 ' Gated time interval of N whole periods, for at least X (capture %dT)
Alternating readouts of %dT and dT, for an estimated Duty calculation of Duty= %dT/dT
Poor stability sources, will jitter/wander between these two captures, but they should track slow thermal drifting of RC oscillators in sensors.
It's gapless, of course. .... No measurement mode misses anything. Everything is gapless.
Expanding the gapless question a little, in my post above of simple duty, using alternate smart pin modes, what happens ?
I presume the change of mode resets everything, and it will need to pause (typically) one iDuty period to resync, but the captured changes will be valid ?
For higher rate sensors, that's not going to matter much, but for lower rate ones (capture a single pulse) it may lower user reading rate a little - becomes Fi/4 ?
Precision Duty avoids this, giving reading rate of Fi, but costs 2 smart pins.
Some mode combinations can be alternated but others just die. Many smartpin modes need a DIRL/DIRH surrounding sequence. As for gaplessness, I think all bets are off when changing modes. You might get lucky in special cases of close modes.
@evanh
Hello evan,
I have been fiddling with your lutson.spin2 attempting strip out the portion that
transmits to the serial terminal.
My goal is to learn how to print from P2asm.
I can get it to print but after a lot of noise, then the print works, then more noise as if the baud rates don't match.
Noted that there are a variety of ways to perform this feature.
Would you look at my code please. What am I missing.
Thanks for posting the other code. Learning a lot.
Martin
You've distilled it down pretty good there Pilot Martin. The catch is RCFAST isn't a fixed frequency. Die temperature affects it a lot, and die temperature is affected by the prop2 power consumption as well as room temperature.
So, unless you're planning on adding regular recalibrations into your code, then you'll be wanting to turn on the crystal clocking of the propeller.
I could have done it as a single cryptic HUBSET value but it's nice to be able to quickly adjust the PLL parameters without having to think about re-encoding it. Cluso did a clearly laid out full set of constants a year ago that I've been referencing ever since - https://forums.parallax.com/discussion/comment/1452025/#Comment_1452025
Attached is slightly limited more compact version for your use. Also has a few bug fixes - which turns out to be the no-serial-gaps is the real reason for your original problem.
So far works great. I will study the link you sent. I will probably have a bunch of questions.
Thanks for the leg up. Now I can go play as I learn more.
Next issue. Have been trying to, say, do plain addition. 2+2. not being able to print result. Looked in several areas. Looked at your code and have this question.
Like in your bcd section, how do you get the print routine to print the number? I don't see it.
The BCD store space is basically a string, but with 4-bit characters instead of 8-bit.
Cordic result from QDIV operation produces the quotient, in QX, and the fractional part as a remainder, in QY. Conveniently, when dividing by ten (Effectively a right shift in decimal) the least most digit becomes the remainder. No adjustment needed.
The routine iterates a divide by ten, extracting the decimal digits one by one, least significant first. Then, once the input integer equals zero, the BCD string is printed, most significant first.
PS: I assumed you are asking about how the "itod" function works.
Comments
Some modes I read as gated-timers, which may appear to accumulate during multi period readings, but some reset-on-capture, so using accumulate can confuse users.
Better would be Gated Counter/ Counter / Gated Timer / Timer, to use terminology that users of other MCU are used to.
Addit: maybe Period Timer and Gated Period timer are needed too, as P2 smart pins can do more than most MCU timer-blocks. A period timer includes edge-sync features.
I don't want to give any of them a timer label because they are primarily for external measuring of inputs. Where as a timer is more associated with simple metronomics for internal use.
Wendy only takes notice of something if there's a problem compiling it, and even then what it does is meaningless to her.
%10001 = Time A-input high states
EDIT: Ah, I think there's a buffering effect that's got me all in knots.
See questions above
Does this mode pair clear-on-capture ? Merely says "... and a new measurement begins"
Also vague is if this is 'gapless' ?
My guess is one period is consumed at each boundary, but it may be smart enough to capture & restart on the same edge, making capture X-Whole_Periods Time sums gapless, and equivalent to real time.
(with just a phase delay on the very first edge, after smart pin config/arming, after that, no lost time)
It's gapless, of course. When the input transitions high, it signals for you to get the low time, and vice-versa. No measurement mode misses anything. Everything is gapless.
That's good, does that include these modes ?
%10011 Time captured over X whole A-B periods. (Time to read is X periods)
%10100 is a gated version of that, A=H=Enable, so it gives a % of H time.
Gapless here needs the X edge that captures, to also be the edge that starts the next time-whole-X ?
The Smart Pin DOCs should include this important detailing.
1024x768 and your table fits perfectly with whitespace trimmed.
+1
Note that the "screen door" effect on TVs can be bad if used as a monitor, so definitely go for 4k.
It won't fit now. I've started using the extra space.
EDIT: I think I've got things tidy and correct now - https://forums.parallax.com/discussion/comment/1479535/#Comment_1479535
EDIT2: Getting a handle on these modes means I'm reasonably sure that SPM_ACC_OVER can provide a synchronised pulse density measurement without any external clock. The tricky part will be in processing it, since the timebase becomes uncertain due to complete pulses determining each sample period.
Chip uses period in the DOCs, why not keep using that ?
Chip uses 'state' which is also confusing, when I think he really means gated, or 'enabled when hi' (working back from context)
Other MCUs talk about Timer/Counters/Capture and Gated (Timers or Counters), so those terms are already in common use, & best to use words that cross language barriers already.
The change to 'for at least X duration' is good here, as that shows the very important detail of whole periods.
SPM_TIM_OVER = %10101_0 ' interval: of A-B pulses/steps, for at least X duration
SPM_ACC_OVER = %10110_0 ' accumulate: A-B pulses/steps, for at least X duration
SPM_CNT_OVER = %10111_0 ' count: A-B pulses/steps, for at least X duration
but OVER means over what ? Better may be SPM_CNT_GEX for Greater than or equal to X aka for at least X duration.
FWIR Chip has designed most (all?) smartpin modes to clear-on-capture, and in a smart way. (if an edge was going to increment, on capture clock instant, clear is to 1 instead of 0, to not lose an edge)
That feature not showing yet in all pinmode sections docs, but is hinted at by ".. then the result will be placed in Z, while the accumulator will be set to the 0/1/-1 value that would have otherwise been added into it, beginning a new measurement"
That means 'accumulate' is going to rather confuse users, as nothing actually accumulates across readings. A better top level word than accumulate, is gated, which is what the HW actually does.
Gated modes will always have some duty related percentage of 100% of possible count, but otherwise acts the same as whole-period modes.
A merge of Chip's docs
%10101 = For periods in X+ clock cycles, count time
%10110 = For periods in X+ clock cycles, count states
%10111 = For periods in X+ clock cycles, count periods
and merge of the above, for clarity (removing words pulse/step/state) would give something like this
SPM_TIM_GEX = %10101_0 ' Time interval of N whole periods, for at least X duration (capture dT)
SPM_GAT_GEX = %10110_0 ' Gated time interval of N whole periods, for at least X (capture %dT)
SPM_CNT_GEX = %10111_0 ' Count of N whole periods, for at least X duration (capture dN)
Some examples:
Reciprocal Counting:
Two smart pins, in complementary modes of
SPM_TIM_GEX = %10101_0 ' Time interval of N whole periods, for at least X duration (capture dT)
SPM_CNT_GEX = %10111_0 ' Count of N whole periods, for at least X duration (capture dN)
started in sync, with a nominal/min capture timebase of X, will give precise, no lost edges, continual readouts of Cycles and Time, for a reciprocal calculation of Freq = dN/dT, and a background rolling total of sum(dN)/sum(dT) will give very high precision frequency calculations.
Precision Duty:
Two smart pins, in complementary modes of
SPM_TIM_GEX = %10101_0 ' Time interval of N whole periods, for at least X duration (capture dT)
SPM_GAT_GEX = %10110_0 ' Gated time interval of N whole periods, for at least X (capture %dT)
started in sync, with a nominal/min capture timebase of X, will give precise, no lost edges, continual readouts of %dT and dT, for a Duty calculation of Duty= %dT/dT, and a background rolling total of sum(%dT)/sum(dT) will give very high precision Duty.
Simpler Duty:
With a good stability Duty source, one smart pin can alternate
SPM_TIM_GEX = %10101_0 ' Time interval of N whole periods, for at least X duration (capture dT)
with
SPM_GAT_GEX = %10110_0 ' Gated time interval of N whole periods, for at least X (capture %dT)
Alternating readouts of %dT and dT, for an estimated Duty calculation of Duty= %dT/dT
Poor stability sources, will jitter/wander between these two captures, but they should track slow thermal drifting of RC oscillators in sensors.
I presume the change of mode resets everything, and it will need to pause (typically) one iDuty period to resync, but the captured changes will be valid ?
For higher rate sensors, that's not going to matter much, but for lower rate ones (capture a single pulse) it may lower user reading rate a little - becomes Fi/4 ?
Precision Duty avoids this, giving reading rate of Fi, but costs 2 smart pins.
Hello evan,
I have been fiddling with your lutson.spin2 attempting strip out the portion that
transmits to the serial terminal.
My goal is to learn how to print from P2asm.
I can get it to print but after a lot of noise, then the print works, then more noise as if the baud rates don't match.
Noted that there are a variety of ways to perform this feature.
Would you look at my code please. What am I missing.
Thanks for posting the other code. Learning a lot.
Martin
So, unless you're planning on adding regular recalibrations into your code, then you'll be wanting to turn on the crystal clocking of the propeller.
Thanks for looking at it.
Attached is slightly limited more compact version for your use. Also has a few bug fixes - which turns out to be the no-serial-gaps is the real reason for your original problem.
Thanks
So far works great. I will study the link you sent. I will probably have a bunch of questions.
Thanks for the leg up. Now I can go play as I learn more.
Can do characters. Next I will work on math.
Thanks again
Now getting a better understanding. Looked again at your loc_bug.spin2 and am better understanding.
Porting over you code slowly. Cool! Again thanks.
Next issue. Have been trying to, say, do plain addition. 2+2. not being able to print result. Looked in several areas. Looked at your code and have this question.
Like in your bcd section, how do you get the print routine to print the number? I don't see it.
Thanks
Cordic result from QDIV operation produces the quotient, in QX, and the fractional part as a remainder, in QY. Conveniently, when dividing by ten (Effectively a right shift in decimal) the least most digit becomes the remainder. No adjustment needed.
The routine iterates a divide by ten, extracting the decimal digits one by one, least significant first. Then, once the input integer equals zero, the BCD string is printed, most significant first.
PS: I assumed you are asking about how the "itod" function works.