SmartPins Duty Cycle measurement
jmg
Posts: 15,144
in Propeller 2
The big pieces are looking good - Pins can measure Period, or can measure Hi time, which means two pin cells are needed paired to measure both Period and Hi time, to then extract Duty cycle in software.
There seem to be some small problems in the details :
Ideally, you want
a) Period and Hi time to apply to the same Pin Cycle in
b) A choice of how many Pin Cycles to measure over
and.or
c) Define of some measurement time, (rounds up to whole Pin cycles).
For b) the present time-only X Counter, could be clocked from the Pin, instead of SysCLK ?
That's a simple CLK source config ?
for a) some cross-linking seems to be needed, so pin-pair Start and Capture in Sync
With 2 pin cells, there are 2 X Counters, seems a pity to waste one ?
As well as possible define of N-Cycles to average over, another approach is to define some minimum time (TGM) - eg >= 100ms. (c)
With this setup, the Pair of cells total HI and Periods, until time is >= TGM.
Then, the next Period edge fires the capture-pair, and the cycle repeats.
This Capture-Pair on next edge >= TGM is also the feature needed for Reciprocal Counting (mentioned already in other thread).
It is very similar to existing Time-regulated capture, just a D-FF is added on >= flag, so actual capture is next-pin-edge based.
If TGM is too small, the SW side polls/waits for the Pin edge.
There seem to be some small problems in the details :
Ideally, you want
a) Period and Hi time to apply to the same Pin Cycle in
b) A choice of how many Pin Cycles to measure over
and.or
c) Define of some measurement time, (rounds up to whole Pin cycles).
For b) the present time-only X Counter, could be clocked from the Pin, instead of SysCLK ?
That's a simple CLK source config ?
for a) some cross-linking seems to be needed, so pin-pair Start and Capture in Sync
With 2 pin cells, there are 2 X Counters, seems a pity to waste one ?
As well as possible define of N-Cycles to average over, another approach is to define some minimum time (TGM) - eg >= 100ms. (c)
With this setup, the Pair of cells total HI and Periods, until time is >= TGM.
Then, the next Period edge fires the capture-pair, and the cycle repeats.
This Capture-Pair on next edge >= TGM is also the feature needed for Reciprocal Counting (mentioned already in other thread).
It is very similar to existing Time-regulated capture, just a D-FF is added on >= flag, so actual capture is next-pin-edge based.
If TGM is too small, the SW side polls/waits for the Pin edge.
Comments
Are you assuming the case of a continuously varying duty cycle and period?
Yes, that is the general case that needs to be covered.
Some sensors have simple low-spec RC oscillators, and that means the period has poor tolerance, and can drift.
The duty cycle should be more precise, as that is set by a timer.
Other systems may encode information in the Period, but keep the duty cycle fixed % for every Period.
I think in terms of frequency response that would be correct... and if you are going to build it into the pin, then don't you have to warn everybody that the frequency limit is Nyquist/something substantial, because you are going to be limited by the actual bandwidth of the signal, no? At lower frequencies, you have cog instruction time available... which can be parallelized.
In summary, I don't know:)
I don't know either.
Short answer : It can't.
To measure both Period and Pulse on the same cycle, requires (quite simple) hardware sync, not software.
The COG of course, manages the Divide to calculate Duty cycle, given the numbers by the Smart pins (paired)/
When we are talking about generating a duty cycle... where are the duty@frequency limits?
For example... as it stands now, can I generate a 48MHz frequency with a 40% duty cycle?
Seems like that use case is covered by the ability to assign multiple units (POGS) to the task?
A Cog can do it for example with Mode %10001 = Time Ainput high and low states that gives the high and the low time with two consecutive reads. It can be repeated several times to get an average value over some time.
Andy
- but you are right, if you can tolerate alternate reading and accept any drift between readings, then you can multiplex the two readings.
This rapid mode change approach would be worth testing, as there is a chance the enable part way through a Hi, needs to be discarded.
Rapid alternate also does not address multiple Pin Cycle readings, to get better precision.
Duty, which is a ratio, is then derived from those two readings, by maths in the COG
(you cannot measure duty directly)
The detail I am trying to get across here, is when those two pin cells capture, they should do so on the same cycle.
I think Multiple Pin cells can trigger from the COG now (Chip mentions sync'd starts) , but I do not (yet) see where multiple Pin cells can trigger from a Pin Signal.
You can control Frequency and Duty, in a classic (non P1 duty) manner.
Your example is pushing things a little.
The new PWM modes have Period and Compare setpoints defined to 1 cycle granularity.
48MHz at 40% requires
0.4/48M = 8.333 ns
0.6/48M = 12.5ns
That's a difference of 4.167ns, which would be possible with a 240MHz Clock.
In this special mode the smartpin logic switches between high and low state measuring on every read, so you get the two times from the same cycle. No mode switching from the cog required.
0% and 100% PWM will be a problem though.
Andy
Teach a man to fish... and he will eventually get tired of eating fish.
Not yet though.
Thanks
DOCs also say
"If states change faster than the cog is able to retrieve measurements, the measurements will effectively be lost, as old ones will be overwritten with new ones."
so that places some strict caveats on Reading rate, limits more than just 0% and 100%, and also pretty much limits to just ONE channel per COG.
I see no mention of reading-clobber error flags, so failures will be hard to sense.
DOCs also suggest using two pin cells as a workaround (now the same as in post #1), but omits any mention of sync of those two cells, which is really what this thread is about.
Smart pins can be controlled many from one COG in most modes, which is one of their significant features.
Best to get the details right, so that a single COG can use many-pins with no gotchas, & the best dynamic range.
sorry
I think you just need to reverse the polarity in this case, so that the first state measures the shorter pulsewidth.
You can sync the two smart pins by setting the corresponding DIRx bits in the same instruction to start them.
Andy
The Smart pins have good SysCLK domain Sync and Counts operation, but they are (currently) less well covered in Pin-Signal Sync and Count.
So, maybe we need some pin-event option to bring them out of reset.
Yes, the Pin-Event changes I would suggest are
a) Allow Period Counter to be SyCLK or Pin Event clocked. (or Pin-Event Clock Enabled )
This allows all those Periodic modes, to be configured for some user-set number of Pin-Events.
b) Add Pin-event trigger, that can apply to more than one pin at a time for sync,
I think this can be relatively simple - along the lines of a single Series D-FF that has a choice of Clock-Enable
i) Always clocked (this for SysCLK trigger)
or
ii) Pin-Event Clocked. This now triggers on first Pin-Event after the COG 'arms' the Pin cell.
I got rid of the V-only PWM SMPS mode, since it was redundant, considering that the B-input can be set to the pin's OUT bit, which can just be kept low.
Cool, so that means the A-Field sets the Clock source (if external), and B-field can set the Capture Source ?
I like the sound of that
Two pins (or more) co-operating on a measurement is very useful.
N-Cycle is easy to define, when you know you have a narrow range of interest.
However, that is not always the case, and for wide Dynamic Range, (and that includes general libraries) you need a variant means to Capture from Two Pins at the same time, and hold that, until they are both read.
ie some simple housekeeping logic.
This choice of 2 operations could also be called 'Hold Until Read' or '(re)Capture Overwrite' modes.
In Hold Until Read, two(or more) pins are Same-edge Enabled for Capture, and the NEXT external event captures both.
Any more external events that may arrive, before read, are ignored.
Once read is done, some time later the SW re-enables Multiple pins, waits for NEXT external event capture, and repeats.
This feature gives 2 results, from 2 pins that you know are same SysCLK edge based.
Most small MCUs operate only 'Capture Overwrite' (tho some have small FIFOs) and that gives serious race/aperture problems with higher frequency signals, where you cannot be in two places at once in SW, so what you read, is not same SysCLK derived.
I can imagine a much richer implementation, in which you give some number of clocks, as a limit of measurement time, and the circuit measures individual periods and duties (highs) for each cycle, adding them into separate period and duty accumulators and incrementing the cycle count, until the measurement time limit is reached, at which point any unfinished period and duty is thrown away and the accumulated periods, duties, and cycle count are returned. We don't have enough stuff to do all that, though. So, we make you pick a number of cycles to measure.
To Summarise the Pin Pair modes,
This Pair for Duty Cycle measurement, which can be over N(HW preset) or dC (SW read) whole Pinin Cycles.
and this pairing for Reciprocal Counting, which can be over N(HW preset) or dC (SW read) whole Pinin Cycles.
PinCell R Z reg holds PinIn Cycles (dC) over the Capture time, and PinCell S Z holds the SysCLKs (dT)
Usually, R & S map to the same PinIn. The P2 limit would be 32 Channels of high precision Frequency Counter, and groups of up to 16 could be sync'd
Frequency is K*dC/dT, and precision is essentially independent of the Frequency In.
100MHz resolves to a (10 parts per billion)(second) product.
1s gives 10 ppb, 10s gives 1ppb, 100ms is 0.1ppm etc
If dC/dT are lossless (as they are here) you can run multiple time bases, to the numeric limit.
I see that not mentioned in either 'measure', is the implicit capture that occurs, on A-rise.
Most MCUs mention Capture, so it would be good to include that wording in the P2.
What's the difference between the new mode 10011 and the similar sounding mode 10001? It seems to me combining mode 10010 with 10001 should achieve what you are proposing.
EDIT: Ah, comparing to earlier docs I now see the added "X periods" applied to six of the modes. That detail didn't stand out for me.
Rereading I think I get it now. Although the old modes 10010 + 10001 would've been completely accurate, they also required a Cog to fetch every modulated sample one by one.
With the new version, one can leave the two Smartpins to keep accumulating whole samples. The two Z's can presumably be examined arbitrarily before the X expiration and contain valid whole running totals.
That would need another timer, and I think it is simpler if the Software is used to choose the nominal measurement time.
Remember, this always snaps to a whole PinIn cycle, so any 'number of clocks' is a minimum.
The actual SysCLKs taken is read from the Pin Pairs.
Are there updated & more complete docs on this yet ?
When X=0, does that mean user has Software Control, as in other modes ?
That would be good, and is very close to the Software paced Capture I am seeking, and that I hope Chip has included, in the fine print.
There are lurking problems with that, 'two Z's can presumably be examined arbitrarily ' and more details are needed than Chip has given so far.
With two captures, as we have here, you need to be certain both captures are related.
If software reads one, then possibly the other changes, inside that reading aperture, then you have bad data.
That's why I've suggested the Hold Until Read action, that allows many-pin (re) init, and then you can read the captured values from many pins.
I think this needs a single Flag, per PinCell plus a means to set that flag across many PinCells on one SysCLK, and then they clear as each Pin is read, and then SW resets the group, and you repeat. Another flag signals Capture_Done.
This way you know all readings are good data, and this is simpler than needing some cross-ties between pin-cells.
Chip has said this "Two modes (%10010, %10011) can be started simultaneously on two different smart pins, focusing on the same input pin", so I think the first part is now implemented, hopefully, the second minor detail is there too ?
The results will be held indefinitely at end of expiry. Nothing extra needed.