If software reads one, then possibly the other changes, inside that reading aperture, then you have bad data.
Standard trick is four quick reads instead of two: Read the "frequency" Z accumulator first then the "duty" Z accumulator (First pair of readings), and reread both in same order (Second pair of readings). Compare the two frequency readings. If they're the same then first pair is valid, if they're different then second pair is valid.
That may 'mostly' work on a normal MCU, with fast SFR access, and slow PinIn values, but the P2 has a read time that is long, relative to the possible input frequency, which could be up to 80MHz.
Right now, the updates only occur at the conclusion of the measurement. Then, a new measurement is automatically started.
Hmm.., I think that rather limits the use, to where users know X in advance, which is not always the case.
Certainly not the case in Instrumentation and Testers.
What happens in the X=0 case ?
I was hopeful that X=0 would pass the 'control baton' to Software, allowing multiple pin, same SysCLK captures, but on SW paced request.(usually those requests are quite slow - 1~1000 milliseconds )
Addit: Can you give an example of use ?
I'm unclear on how one X, in one PinIn, paces two Pin's capture - did you add some cross-links to do that ?
Or does the user load 2 X's ? that means X needs separate Clock mux, as pins may be measuring dT or dC ?
Right now, the updates only occur at the conclusion of the measurement. Then, a new measurement is automatically started.
Hmm.., I think that rather limits the use, to where users know X in advance, which is not always the case.
Certainly not the case in Instrumentation and Testers.
What happens in the X=0 case ?
I was hopeful that X=0 would pass the 'control baton' to Software, allowing multiple pin, same SysCLK captures, but on SW paced request.(usually those requests are quite slow - 1~1000 milliseconds )
Addit: Can you give an example of use ?
I'm unclear on how one X, in one PinIn, paces two Pin's capture - did you add some cross-links to do that ?
Or does the user load 2 X's ? that means X needs separate Clock mux, as pins may be measuring dT or dC ?
The smart pins are not aware of each other. You just configure them with the same X and they will report, in unison, via IN, when they are done, with updated Z's ready to read.
The smart pins are not aware of each other. You just configure them with the same X and they will report, in unison, via IN, when they are done, with updated Z's ready to read.
So that means the A-Field sets the Z clock, and the B-field sets the X clock source ?
What happens when the user loads X=0 ? Can that give the Software control method ?
The smart pins are not aware of each other. You just configure them with the same X and they will report, in unison, via IN, when they are done, with updated Z's ready to read.
So that means the A-Field sets the Z clock, and the B-field sets the X clock source ?
What happens when the user loads X=0 ? Can that give the Software control method ?
Well, the way I've thought about it, you would point both smart pins' A-inputs to the same pin. You would release them from reset at the same time. They would both run until X cycles had come in. One smart pin accumulated total SysClk cycles and the other accumulated total highs. They both started at the same time, and waited for the inital rise to start counting off subsequent rises. They both stopped on the Xth rise. One has time, the other has highs, both readable via PINGETZ.
Well, the way I've thought about it, you would point both smart pins' A-inputs to the same pin. You would release them from reset at the same time. They would both run until X cycles had come in. One smart pin accumulated total SysClk cycles and the other accumulated total highs. They both started at the same time, and waited for the inital rise to start counting off subsequent rises. They both stopped on the Xth rise. One has time, the other has highs, both readable via PINGETZ.
If the Signal is Hi then they start, is that first partial high counted ?
I'm not sure how that Pincell knows to wait for the first _/= before starting ?
I think the advice then has to be to discard the first reading, after a X-value change ?
Also, is both stopped the right wording ? I thought this was a capture on X.TC ? - that does not stop anything, but repeats the capture on every X.TC ?
More general software support for only X-forced captures, is going to need some extra range-finding code, a cost in both code size and time.
Well, the way I've thought about it, you would point both smart pins' A-inputs to the same pin. You would release them from reset at the same time. They would both run until X cycles had come in. One smart pin accumulated total SysClk cycles and the other accumulated total highs. They both started at the same time, and waited for the inital rise to start counting off subsequent rises. They both stopped on the Xth rise. One has time, the other has highs, both readable via PINGETZ.
If the Signal is Hi then they start, is that first partial high counted ?
I'm not sure how that Pincell knows to wait for the first _/= before starting ?
I think the advice then has to be to discard the first reading, after a X-value change ?
Also, is both stopped the right wording ? I thought this was a capture on X.TC ? - that does not stop anything, but repeats the capture on every X.TC ?
More general software support for only X-forced captures, is going to need some extra range-finding code, a cost in both code size and time.
When they are both released from reset (DIR rises), they both wait for the initial rise on their A-input (same pin). Then, they both set their Z registers to $00000001. One pin counts highs, while the other always increments. When the Xth rise on the A-input thereafter comes in, they both output their Z registers and raise IN. Then, a new count is underway, starting both pins' Z registers from $00000001.
We just don't have enough flops in the smart pins to make this auto-ranging, as intermediate counts would have to be buffered before being accumulated into the main counts upon A-rise if the timeout hadn't occurred, yet.
We just don't have enough flops in the smart pins to make this auto-ranging, as intermediate counts would have to be buffered before being accumulated into the main counts upon A-rise if the timeout hadn't occurred, yet.
That is why I believe the PinCell needs the (missing?) Software Mode, (when X=0?)
Instead of needing any auto-ranging flops, you manage the general case with a Software minimum measurement time*, and then the PinIn frequency auto-scales itself.
Commercial reciprocal counters, do not have a range-set step, because they use Software minimum measurement time mode.
High frequencies give more PinIn Cycles and lower frequencies give less, and the SW measurement time determines the digits of precision.
* The actual exact measurement time, is set by the nearest-round-up-whole-cycle of PinIn.
We just don't have enough flops in the smart pins to make this auto-ranging, as intermediate counts would have to be buffered before being accumulated into the main counts upon A-rise if the timeout hadn't occurred, yet.
That is why I believe the PinCell needs the (missing?) Software Mode, (when X=0?)
Instead of needing any auto-ranging flops, you manage the general case with a Software minimum measurement time*, and then the PinIn frequency auto-scales itself.
Commercial reciprocal counters, do not have a range-set step, because they use Software minimum measurement time mode.
High frequencies give more PinIn Cycles and lower frequencies give less, and the SW measurement time determines the digits of precision.
* The actual exact measurement time, is set by the nearest-round-up-whole-cycle of PinIn.
I finally see the light!
I understand now about a minimum acquisition time, and running past that, until the next (last) cycle edge of the input is registered.
There are FOUR things that must be tracked:
1) countdown for the minimum acquisition time
2) number of system clocks needed to get from the first input edge, past the minimum acquisition time, to the last input edge
3) number of highs counted during (2) - this is for duty
4) number of input cycles counted during (2) - this is for frequency
It will take THREE smart pins to do a complete frequency+duty acquisition. Each will have to track (1) from above, along with one of the other three.
We just don't have enough flops in the smart pins to make this auto-ranging, as intermediate counts would have to be buffered before being accumulated into the main counts upon A-rise if the timeout hadn't occurred, yet.
That is why I believe the PinCell needs the (missing?) Software Mode, (when X=0?)
Instead of needing any auto-ranging flops, you manage the general case with a Software minimum measurement time*, and then the PinIn frequency auto-scales itself.
Commercial reciprocal counters, do not have a range-set step, because they use Software minimum measurement time mode.
High frequencies give more PinIn Cycles and lower frequencies give less, and the SW measurement time determines the digits of precision.
* The actual exact measurement time, is set by the nearest-round-up-whole-cycle of PinIn.
I finally see the light!
I understand now about a minimum acquisition time, and running past that, until the next (last) cycle edge of the input is registered.
There are FOUR things that must be tracked:
1) countdown for the minimum acquisition time
2) number of system clocks needed to get from the first input edge, past the minimum acquisition time, to the last input edge
3) number of highs counted during (2) - this is for duty
4) number of input cycles accumulated during (2) - this is for frequency
It will take THREE smart pins to do a complete frequency+duty acquisition. Each will have to track (1) from above, along with one of the other three.
Yup, pretty much nailed it
The beauty of Multi-pin co-operation, is someone can use THREE smart pins, if they want to do a complete frequency+duty acquisition. ( That little side-ways Pin Mux feature, has made this very powerful indeed )
If they just want Precision Frequency, or Duty, they need use only 2 (,4,6,8,10 for Multiple channels).
Of course, once you tell someone they can have both, they start thinking about Sensor designs that can isolate over one wire, and convey two lots of Precision Analog information - One encoded in Duty, the other encoded in Frequency.
The way I see it, item 1) does not have to be done in the Pin, that can be SW as it is a minimum acquisition time (eg 10ms, 100ms), ie it does not need to cost flops, you just need SW access to request capture-next-edge from many pins.
The small detail of reset of Z to $00000001, I am only luke-warm on.
I prefer no-reset, and using a simple difference dC, dT, as that avoids delay skew housekeeping details.
(ie makes the hardware easier, and SW cost is minimal ).
If the pin cell takes (say) any one of 1,2,3,4 SysCLKs to pipeline some of these actions, with a difference approach (no reset) that vanishes, as it is always the same delay. With reset, the IC designer (aka you) needs to count those SysCLKs.
Knowing you have no SysCLK count creep, also means you can run a background average over 100, 1000, etc readings, for precision limited only by the numeric base.
We just don't have enough flops in the smart pins to make this auto-ranging, as intermediate counts would have to be buffered before being accumulated into the main counts upon A-rise if the timeout hadn't occurred, yet.
That is why I believe the PinCell needs the (missing?) Software Mode, (when X=0?)
Instead of needing any auto-ranging flops, you manage the general case with a Software minimum measurement time*, and then the PinIn frequency auto-scales itself.
Commercial reciprocal counters, do not have a range-set step, because they use Software minimum measurement time mode.
High frequencies give more PinIn Cycles and lower frequencies give less, and the SW measurement time determines the digits of precision.
* The actual exact measurement time, is set by the nearest-round-up-whole-cycle of PinIn.
I finally see the light!
I understand now about a minimum acquisition time, and running past that, until the next (last) cycle edge of the input is registered.
There are FOUR things that must be tracked:
1) countdown for the minimum acquisition time
2) number of system clocks needed to get from the first input edge, past the minimum acquisition time, to the last input edge
3) number of highs counted during (2) - this is for duty
4) number of input cycles accumulated during (2) - this is for frequency
It will take THREE smart pins to do a complete frequency+duty acquisition. Each will have to track (1) from above, along with one of the other three.
Yup, pretty much nailed it
The beauty of Multi-pin co-operation, is someone can use THREE smart pins, if they want to do a complete frequency+duty acquisition. ( That little side-ways Pin Mux feature, has made this very powerful indeed )
If they just want Precision Frequency, or Duty, they need use only 2 (,4,6,8,10 for Multiple channels).
Of course, once you tell someone they can have both, they start thinking about Sensor designs that can isolate over one wire, and convey two lots of Precision Analog information - One encoded in Duty, the other encoded in Frequency.
The way I see it, item 1) does not have to be done in the Pin, that can be SW as it is a minimum acquisition time (eg 10ms, 100ms), ie it does not need to cost flops, you just need SW access to request capture-next-edge from many pins.
The small detail of reset of Z to $00000001, I am only luke-warm on.
I prefer no-reset, and using a simple difference dC, dT, as that avoids delay skew housekeeping details.
(ie makes the hardware easier, and SW cost is minimal ).
If the pin cell takes (say) any one of 1,2,3,4 SysCLKs to pipeline some of these actions, with a difference approach (no reset) that vanishes, as it is always the same delay. With reset, the IC designer (aka you) needs to count those SysCLKs.
Knowing you have no SysCLK count creep, also means you can run a background average over 100, 1000, etc readings, for precision limited only by the numeric base.
I think getting the acquisition timer out of the smart pin is good, because that might as well be done by software: start it, pass some time, stop it, and wait for the results via IN after the final A-input edge. Having the smart pins do the minimum timer is silly, because the exact time elapsed does not matter and will not be consistent, anyway - so why put a 32-bit comparator in each pin? The wrap-it-up signal can come from the B-input, which could be set to be the OUT bit, which bit can be set for all pins at once with an 'OR DIRA,##%111<<pinbase'.
This means that each smart pin in reciprocal-counter mode can track either system clocks, A-input edges, or highs. So, there will be three sub-modes to pick which measurement you are taking.
I think getting the acquisition timer out of the smart pin is good, because that might as well be done by software: start it, pass some time, stop it, and wait for the results via IN after the final A-input edge. Having the smart pins do the minimum timer is silly, because the exact time elapsed does not matter and will not be consistent, anyway - so why put a 32-bit comparator in each pin? The wrap-it-up signal can come from the B-input, which could be set to be the OUT bit, which bit can be set for all pins at once with an 'OR DIRA,##%111<<pinbase'.
This means that each smart pin in reciprocal-counter mode can track either system clocks, A-input edges, or highs. So, there will be three sub-modes to pick which measurement you are taking.
Agreed.
I think the additional option of your X-counted captures is useful (if that has low logic count) as that is broadly equivalent to Microchips Capture prescalers, and some users will understand that.
The more general software-paced you describe above, is better for libraries and general use.
That was why I suggested using X=0 as a means to flip X-Counted or SW-Paced, but SW-Paced alone, is fine.
X-Counted may be useful in some special cases, where Rate-Multiplier type PWM or sub-cycle jitter is used, and you know there are frames of 256, 1024 cycles, (or whatever).
One example: A P2, or other small MCU, sends PWM at 80M/2^12 = 19.53125 KHz, and also dither modulates that, in 256 frames.
X=256 would give a ~20 bit result(12+8), at 76.29 Hz reading rates.
A small part like EFM8LB1, could send multiple 14b ADC results over a simple PWM link.
I think getting the acquisition timer out of the smart pin is good, because that might as well be done by software: start it, pass some time, stop it, and wait for the results via IN after the final A-input edge. Having the smart pins do the minimum timer is silly, because the exact time elapsed does not matter and will not be consistent, anyway - so why put a 32-bit comparator in each pin? The wrap-it-up signal can come from the B-input, which could be set to be the OUT bit, which bit can be set for all pins at once with an 'OR DIRA,##%111<<pinbase'.
This means that each smart pin in reciprocal-counter mode can track either system clocks, A-input edges, or highs. So, there will be three sub-modes to pick which measurement you are taking.
Agreed.
I think the additional option of your X-counted captures is useful (if that has low logic count) as that is broadly equivalent to Microchips Capture prescalers, and some users will understand that.
The more general software-paced you describe above, is better for libraries and general use.
That was why I suggested using X=0 as a means to flip X-Counted or SW-Paced, but SW-Paced alone, is fine.
X-Counted may be useful in some special cases, where Rate-Multiplier type PWM or sub-cycle jitter is used, and you know there are frames of 256, 1024 cycles, (or whatever).
One example: A P2, or other small MCU, sends PWM at 80M/2^12 = 19.53125 KHz, and also dither modulates that, in 256 frames.
X=256 would give a ~20 bit result(12+8), at 76.29 Hz reading rates.
A small part like EFM8LB1, could send multiple 14b ADC results over a simple PWM link.
I agree. There could be some X-prescaler modes, and then if X=0 we use the B-input to start and stop the acquisition.
Of course, once you tell someone they can have both, they start thinking about Sensor designs that can isolate over one wire, and convey two lots of Precision Analog information - One encoded in Duty, the other encoded in Frequency.
And, you just re-invented QAM.
Just externally filter the signal and apply the Goertzel. Direct readout of frequency deviation (Phase) and duty (Amplitude). Use them separately, or develop a classic N bit by N bit constellation for data transfer.
I finally got all the special measurement modes in the smart pin worked out. They are modes %10011..%10111:
MMMMM Description OUT Inputs Pattern
--------------------------------------------------------------------------------------------------------
00000 OUT (default) OUT A,B <none>
00001 * DAC noise OUT A,B output-update-repeat
00010 * DAC 16-bit dither, noise OUT A,B output-update-repeat
00011 * DAC 16-bit dither, PWM OUT A,B output-update-repeat
00100 * X pulse(s) drive - wait-output-repeat
00101 * X edges drive - wait-output-repeat
00110 * NCO freq drive - output
00111 * NCO duty drive - output
01000 * PWM triangle 16:16 drive - output-update-repeat
01001 * PWM sawtooth 16:16 drive - output-update-repeat
01010 * PWM SMPS, A=V, B=I drive A,B output-update-repeat
01011 * A-B quadrature encoder OUT A,B measure-report-loop
01100 * A-high inc OUT A,B measure-report-loop
01101 * A-rise inc OUT A,B measure-report-loop
01110 * A-high inc, B-high dec OUT A,B measure-report-loop
01111 * A-rise inc, B-rise dec OUT A,B measure-report-loop
10000 * time A-state periods OUT A,B time-report-loop (!sign = state)
10001 * time A-high periods OUT A,B time-report-loop
10010 * time X A-highs OUT A,B time-report-loop
10011 * for X periods, count time OUT A,B time-report-loop
10100 * for X periods, count states OUT A,B time-report-loop
10101 * for periods in X+ clocks, count time OUT A,B time-report-loop
10110 * for periods in X+ clocks, count states OUT A,B time-report-loop
10111 * for periods in X+ clocks, count periods OUT A,B time-report-loop
11000 * USB host, low-speed drive A,B receive-repeat
11001 * USB host, full-speed drive A,B receive-repeat
11010 * USB device, low-speed drive A,B receive-repeat
11011 * USB device, full-speed drive A,B receive-repeat
11100 * B-clk tx drive B transmit-repeat
11101 * B-clk rx OUT A,B receive-repeat
11110 * async tx drive - transmit-repeat
11111 * async rx OUT A,B receive-repeat
* DIR from cogs: 0=reset, 1=start; IN to cogs: 1=done; 'PINACK pin' clears done
edge selection via PINSETY for modes 10011..10111
-------------------------------------------------
00 = A-rise to B-rise
01 = A-rise to B-edge
10 = A-edge to B-rise
11 = A-edge to B-edge
You can select what constitutes a period via PINSETY for these modes. A period is not necessarily a cycle, but an A-to-B event, where B can be A, also. The 'state' that can be counted in modes %10100 and %10110 is the leading edge of the A-input which starts a period. Periods can now overlap if the trailing B-input edge (may be same as A-input) is coincident with the leading A-edge.
I'll get these documented and into the next release.
Jmg, these special counter modes work great! I realized that there WAS sufficient logic to set a minimal sample timer that repeats automatically, like in other modes. You just tell it how long to look and it will count up whole periods until the timer runs down to 1. Then, it just waits for the last trailing edge to wrap up the measurement. And it can even handle coincident trailing and leading edges, making cycle counting contiguous. Really nice! Thanks for bringing this up (and up, and up...). It's very nice to have in the smart pin. It only added several ALMs per pin.
Since I had a spare slot, I also added a new mode (%10010) which times how long it takes to register X high samples on the A input. That ought to be good for something.
Jmg, these special counter modes work great! I realized that there WAS sufficient logic to set a minimal sample timer that repeats automatically, like in other modes. You just tell it how long to look and it will count up whole periods until the timer runs down to 1. Then, it just waits for the last trailing edge to wrap up the measurement. And it can even handle coincident trailing and leading edges, making cycle counting contiguous. Really nice! Thanks for bringing this up (and up, and up...). It's very nice to have in the smart pin. It only added several ALMs per pin.
Sounding great ! I was prepared for the COG to do at least some of the slower work...
( Sorry to play the squeaky wheel, but I could see that the Smart Pin cell was almost able to do this before...)
Does this still clear Z on capture ?
Can you post code examples used to test each of these modes, so others can stretch them around ?
One easy test I can think of, is to connect a couple (or 3) GPS modules, and measure the 1pps on each.
Set the Min-time to 0.5s, 13s, 50s
Then, also measure time-interval A-B between modules, to check the 1pps edge alignment jitters.
You should get 12.5ppb, ~1ppb, 0.25ppb LSBs
Since I had a spare slot, I also added a new mode (%10010) which times how long it takes to register X high samples on the A input. That ought to be good for something.
Isn't that one of the modes needed for Duty Measurement ?
See also the thread on fast PWM http://forums.parallax.com/discussion/comment/1373564/#Comment_1373564
Here, dither over some frame count, gives higher average precision.
To get best results of measuring such a frame-dithered PWM signal, if the user knows beforehand how many cycles the frame is, they can set the capture counts to be a multiple of that.
Capture then gets all the information, every time, with no partials, for best precision.
On the topic of Duty-Cycle Measurement, this new part from Infineon is nifty :
In a SOT23-6? this accepts a standard, simple 0-10V, (or R) and outputs a 5mA current PWM for direct opto drive.
Looks nice for Isolated, remote analog, to modest precisions.
Jmg, these special counter modes work great! I realized that there WAS sufficient logic to set a minimal sample timer that repeats automatically, like in other modes. You just tell it how long to look and it will count up whole periods until the timer runs down to 1. Then, it just waits for the last trailing edge to wrap up the measurement. And it can even handle coincident trailing and leading edges, making cycle counting contiguous. Really nice! Thanks for bringing this up (and up, and up...). It's very nice to have in the smart pin. It only added several ALMs per pin.
Sounding great ! I was prepared for the COG to do at least some of the slower work...
This will make for some attention-grabbing demonstrations !!
( Sorry to play the squeaky wheel, but I could see that the Smart Pin cell was almost able to do this before...)
Does this still clear Z on capture ?
Can you post code examples used to test each of these modes, so others can stretch them around ?
One easy test I can think of, is to connect a couple (or 3) GPS modules, and measure the 1pps on each.
Set the Min-time to (say) 0.5s, 12.5s, 49.9s
Then, also measure time-interval A-B between modules, to check the 1pps edge alignment jitters.
You should get 12.5ppb, ~1ppb, 0.25ppb LSBs
Since I had a spare slot, I also added a new mode (%10010) which times how long it takes to register X high samples on the A input. That ought to be good for something.
Isn't that one of the modes needed for Duty Measurement ?
See also the thread on fast PWM http://forums.parallax.com/discussion/comment/1373564/#Comment_1373564
Here, dither over some frame count, gives higher average precision.
To get best results of measuring such a frame-dithered PWM signal, if the user knows beforehand how many cycles the frame is, they can set the capture counts to be a multiple of that.
Capture then gets all the information, every time, with no partials, for best precision.
On the topic of Duty-Cycle Measurement, this new part from Infineon is nifty :
In a SOT23-6? this accepts a standard, simple 0-10V, (or R) and outputs a 5mA current PWM for direct opto drive.
Looks nice for Isolated, remote analog, to modest precisions.
It does, but the increment is still added in, setting it to one. This is needed, though, since when we detect end-of-cycle, the current value of the Z register needs to be sent for the update, not Z from the next cycle, which would have been incremented (and also cleared, leaving $00000001). This all works out and gives perfect results, as output of $00000000 is never possible. For the measurement to end, some measurement had to be taken, making it always >= 1.
Interesting idea about testing the GPS modules' jitter.
It does, but the increment is still added in, setting it to one. This is needed, though, since when we detect end-of-cycle, the current value of the Z register needs to be sent for the update, not Z from the next cycle, which would have been incremented (and also cleared, leaving $00000001). This all works out and gives perfect results, as output of $00000000 is never possible. For the measurement to end, some measurement had to be taken, making it always >= 1.
Cool, I was just worried about the potential for missing unusual cases.
If it tests ok in all cases, then that is great.
Users need to be able to capture at some faster rate (say >~ 100ms) and also run a background, slower 10s or 50s accumulate.
If there are never any lost edges, then that background accumulate is a correct answer.
Interesting idea about testing the GPS modules' jitter.
GPS should give a good way to test this, and should catch any off-by-one slip-ups.
If you have this all working in a pin now, with minimal SW overhead, then clipping on GPS for added precision (or calibrate) becomes quite easy to do. GPS-volumed (VC)TCXO's are also remarkably cheap recently.
Comments
Hopefully you are right, & Chip has covered all use modes, nothing extra needed, however I'll reserve judgement until Chip gives more details.
Certainly not the case in Instrumentation and Testers.
What happens in the X=0 case ?
I was hopeful that X=0 would pass the 'control baton' to Software, allowing multiple pin, same SysCLK captures, but on SW paced request.(usually those requests are quite slow - 1~1000 milliseconds )
Addit: Can you give an example of use ?
I'm unclear on how one X, in one PinIn, paces two Pin's capture - did you add some cross-links to do that ?
Or does the user load 2 X's ? that means X needs separate Clock mux, as pins may be measuring dT or dC ?
The smart pins are not aware of each other. You just configure them with the same X and they will report, in unison, via IN, when they are done, with updated Z's ready to read.
What happens when the user loads X=0 ? Can that give the Software control method ?
Well, the way I've thought about it, you would point both smart pins' A-inputs to the same pin. You would release them from reset at the same time. They would both run until X cycles had come in. One smart pin accumulated total SysClk cycles and the other accumulated total highs. They both started at the same time, and waited for the inital rise to start counting off subsequent rises. They both stopped on the Xth rise. One has time, the other has highs, both readable via PINGETZ.
If the Signal is Hi then they start, is that first partial high counted ?
I'm not sure how that Pincell knows to wait for the first _/= before starting ?
I think the advice then has to be to discard the first reading, after a X-value change ?
Also, is both stopped the right wording ? I thought this was a capture on X.TC ? - that does not stop anything, but repeats the capture on every X.TC ?
More general software support for only X-forced captures, is going to need some extra range-finding code, a cost in both code size and time.
When they are both released from reset (DIR rises), they both wait for the initial rise on their A-input (same pin). Then, they both set their Z registers to $00000001. One pin counts highs, while the other always increments. When the Xth rise on the A-input thereafter comes in, they both output their Z registers and raise IN. Then, a new count is underway, starting both pins' Z registers from $00000001.
We just don't have enough flops in the smart pins to make this auto-ranging, as intermediate counts would have to be buffered before being accumulated into the main counts upon A-rise if the timeout hadn't occurred, yet.
That is why I believe the PinCell needs the (missing?) Software Mode, (when X=0?)
Instead of needing any auto-ranging flops, you manage the general case with a Software minimum measurement time*, and then the PinIn frequency auto-scales itself.
Commercial reciprocal counters, do not have a range-set step, because they use Software minimum measurement time mode.
High frequencies give more PinIn Cycles and lower frequencies give less, and the SW measurement time determines the digits of precision.
* The actual exact measurement time, is set by the nearest-round-up-whole-cycle of PinIn.
I finally see the light!
I understand now about a minimum acquisition time, and running past that, until the next (last) cycle edge of the input is registered.
There are FOUR things that must be tracked:
1) countdown for the minimum acquisition time
2) number of system clocks needed to get from the first input edge, past the minimum acquisition time, to the last input edge
3) number of highs counted during (2) - this is for duty
4) number of input cycles counted during (2) - this is for frequency
It will take THREE smart pins to do a complete frequency+duty acquisition. Each will have to track (1) from above, along with one of the other three.
I'm on it.
Yup, pretty much nailed it
The beauty of Multi-pin co-operation, is someone can use THREE smart pins, if they want to do a complete frequency+duty acquisition. ( That little side-ways Pin Mux feature, has made this very powerful indeed )
If they just want Precision Frequency, or Duty, they need use only 2 (,4,6,8,10 for Multiple channels).
Of course, once you tell someone they can have both, they start thinking about Sensor designs that can isolate over one wire, and convey two lots of Precision Analog information - One encoded in Duty, the other encoded in Frequency.
Look forward to seeing what comes out
The way I see it, item 1) does not have to be done in the Pin, that can be SW as it is a minimum acquisition time (eg 10ms, 100ms), ie it does not need to cost flops, you just need SW access to request capture-next-edge from many pins.
The small detail of reset of Z to $00000001, I am only luke-warm on.
I prefer no-reset, and using a simple difference dC, dT, as that avoids delay skew housekeeping details.
(ie makes the hardware easier, and SW cost is minimal ).
If the pin cell takes (say) any one of 1,2,3,4 SysCLKs to pipeline some of these actions, with a difference approach (no reset) that vanishes, as it is always the same delay. With reset, the IC designer (aka you) needs to count those SysCLKs.
Knowing you have no SysCLK count creep, also means you can run a background average over 100, 1000, etc readings, for precision limited only by the numeric base.
I think getting the acquisition timer out of the smart pin is good, because that might as well be done by software: start it, pass some time, stop it, and wait for the results via IN after the final A-input edge. Having the smart pins do the minimum timer is silly, because the exact time elapsed does not matter and will not be consistent, anyway - so why put a 32-bit comparator in each pin? The wrap-it-up signal can come from the B-input, which could be set to be the OUT bit, which bit can be set for all pins at once with an 'OR DIRA,##%111<<pinbase'.
This means that each smart pin in reciprocal-counter mode can track either system clocks, A-input edges, or highs. So, there will be three sub-modes to pick which measurement you are taking.
Agreed.
I think the additional option of your X-counted captures is useful (if that has low logic count) as that is broadly equivalent to Microchips Capture prescalers, and some users will understand that.
The more general software-paced you describe above, is better for libraries and general use.
That was why I suggested using X=0 as a means to flip X-Counted or SW-Paced, but SW-Paced alone, is fine.
X-Counted may be useful in some special cases, where Rate-Multiplier type PWM or sub-cycle jitter is used, and you know there are frames of 256, 1024 cycles, (or whatever).
One example: A P2, or other small MCU, sends PWM at 80M/2^12 = 19.53125 KHz, and also dither modulates that, in 256 frames.
X=256 would give a ~20 bit result(12+8), at 76.29 Hz reading rates.
A small part like EFM8LB1, could send multiple 14b ADC results over a simple PWM link.
I agree. There could be some X-prescaler modes, and then if X=0 we use the B-input to start and stop the acquisition.
And, you just re-invented QAM.
Just externally filter the signal and apply the Goertzel. Direct readout of frequency deviation (Phase) and duty (Amplitude). Use them separately, or develop a classic N bit by N bit constellation for data transfer.
You can select what constitutes a period via PINSETY for these modes. A period is not necessarily a cycle, but an A-to-B event, where B can be A, also. The 'state' that can be counted in modes %10100 and %10110 is the leading edge of the A-input which starts a period. Periods can now overlap if the trailing B-input edge (may be same as A-input) is coincident with the leading A-edge.
I'll get these documented and into the next release.
Since I had a spare slot, I also added a new mode (%10010) which times how long it takes to register X high samples on the A input. That ought to be good for something.
Sounding great !
( Sorry to play the squeaky wheel, but I could see that the Smart Pin cell was almost able to do this before...)
Does this still clear Z on capture ?
Can you post code examples used to test each of these modes, so others can stretch them around ?
One easy test I can think of, is to connect a couple (or 3) GPS modules, and measure the 1pps on each.
Set the Min-time to 0.5s, 13s, 50s
Then, also measure time-interval A-B between modules, to check the 1pps edge alignment jitters.
You should get 12.5ppb, ~1ppb, 0.25ppb LSBs
Isn't that one of the modes needed for Duty Measurement ?
See also the thread on fast PWM
http://forums.parallax.com/discussion/comment/1373564/#Comment_1373564
Here, dither over some frame count, gives higher average precision.
To get best results of measuring such a frame-dithered PWM signal, if the user knows beforehand how many cycles the frame is, they can set the capture counts to be a multiple of that.
Capture then gets all the information, every time, with no partials, for best precision.
On the topic of Duty-Cycle Measurement, this new part from Infineon is nifty :
http://www.infineon.com/cms/en/product/power/lighting-ics-and-audio-driver-ics/dc-dc-led-driver-ic-and-linear-control-solutions/CDM10V/productType.html?productType=5546d46253f65057015414dc7d576130
In a SOT23-6? this accepts a standard, simple 0-10V, (or R) and outputs a 5mA current PWM for direct opto drive.
Looks nice for Isolated, remote analog, to modest precisions.
Sounding great !
This will make for some attention-grabbing demonstrations !!
( Sorry to play the squeaky wheel, but I could see that the Smart Pin cell was almost able to do this before...)
Does this still clear Z on capture ?
Can you post code examples used to test each of these modes, so others can stretch them around ?
One easy test I can think of, is to connect a couple (or 3) GPS modules, and measure the 1pps on each.
Set the Min-time to (say) 0.5s, 12.5s, 49.9s
Then, also measure time-interval A-B between modules, to check the 1pps edge alignment jitters.
You should get 12.5ppb, ~1ppb, 0.25ppb LSBs
Isn't that one of the modes needed for Duty Measurement ?
See also the thread on fast PWM
http://forums.parallax.com/discussion/comment/1373564/#Comment_1373564
Here, dither over some frame count, gives higher average precision.
To get best results of measuring such a frame-dithered PWM signal, if the user knows beforehand how many cycles the frame is, they can set the capture counts to be a multiple of that.
Capture then gets all the information, every time, with no partials, for best precision.
On the topic of Duty-Cycle Measurement, this new part from Infineon is nifty :
http://www.infineon.com/cms/en/product/power/lighting-ics-and-audio-driver-ics/dc-dc-led-driver-ic-and-linear-control-solutions/CDM10V/productType.html?productType=5546d46253f65057015414dc7d576130
In a SOT23-6? this accepts a standard, simple 0-10V, (or R) and outputs a 5mA current PWM for direct opto drive.
Looks nice for Isolated, remote analog, to modest precisions.
It does, but the increment is still added in, setting it to one. This is needed, though, since when we detect end-of-cycle, the current value of the Z register needs to be sent for the update, not Z from the next cycle, which would have been incremented (and also cleared, leaving $00000001). This all works out and gives perfect results, as output of $00000000 is never possible. For the measurement to end, some measurement had to be taken, making it always >= 1.
Interesting idea about testing the GPS modules' jitter.
If it tests ok in all cases, then that is great.
Users need to be able to capture at some faster rate (say >~ 100ms) and also run a background, slower 10s or 50s accumulate.
If there are never any lost edges, then that background accumulate is a correct answer.
GPS should give a good way to test this, and should catch any off-by-one slip-ups.
If you have this all working in a pin now, with minimal SW overhead, then clipping on GPS for added precision (or calibrate) becomes quite easy to do. GPS-volumed (VC)TCXO's are also remarkably cheap recently.