HubRAM 16 of 8192x32 SP RAM 16 x 1.57 mm2 = 25.1 mm2
LUTRAM 16 of 256x32 SP RAM 16 x 0.095 mm2 = 1.5 mm2
32 kB HubRAM blocks vs 1 kB (at that time) LUTRAM blocks. HubRAM has smaller apparent SRAM cells there. Approximately twice the density of the LUTRAM. I'm assuming that's due to the block size.
The bigger the array, the less significant the row and column circuitry becomes.
HubRAM 16 of 8192x32 SP RAM 16 x 1.57 mm2 = 25.1 mm2
LUTRAM 16 of 256x32 SP RAM 16 x 0.095 mm2 = 1.5 mm2
32 kB HubRAM blocks vs 1 kB (at that time) LUTRAM blocks. HubRAM has smaller apparent SRAM cells there. Approximately twice the density of the LUTRAM. I'm assuming that's due to the block size.
No. The LUT and COG RAM is dual port which takes approx 2x die space.
It might be possible to get a whole megabyte of hub RAM with fewer cogs, but I doubt it. To get more RAM, we just need a smaller process. That is what would really do the trick.
Thanks Chip.
When P2 settles, which should be any day now , we can see where the die space is used. Perhaps there is an arrangement where some more hub ram could be squeezed in, perhaps not. Maybe the dreaded 640KB which "would be more than enough for anything"
You should remember the rather "in-depth" discussions on inter-Cog comms before arriving at the Cog pairing tandem Cogs via the then newly added dual-porting of the LUTRAM.
There seem to be many counting modes that could use one or two pins.
The steering circuitry to realize these modes is just a few gates, each, and these modes are trivial to implement. If you want to come up with a set of requirements for a bunch of these modes, I could look into implementing them. These are outside of the hub and cogs and may not have any effect on ongoing software development.
It's going to be a few months, probably, before we start spending the money to fabricate, so there's time to make sure the smart pins have what they ought to.
If you could express each mode in simple terms like these, it would make things very easy:
I'm starting with terminology, and I think we need to add a name for the buried CounterTimer, as below.
You may be able to simplify the DOCs and logic, if a single config bit can select PinCK or SysCLK for CounterTimer ?
Terminology:
SC = SystemCLK (eg 160MHz)
CT - Buried 32b CounterTimer (CT.R = !DIR)
.CLK = Clock Source
.DIR = CT Count direction
.CE = Clock Enable
.RE = Reload enable, used to preset -1/0/+1
.RV = Reload value, commonly -1/0/+1
Ar,Br = Rise _/= on Pin
Af,Bf = Fall =\_ on Pin
Ae,Be = Either edge, Rise or Fall
Ah = High Time on Pin (!A for low time)
.D = Capture register Data Pins (=CT in Counter/Timer modes)
.LE = capture register Load Enable (raise IN to signal event)
DIRt = Write 1 to DIRA or DIRB, arms/starts the configured mode
CellE = CellEnable, Set by first DIRt after init. Can enable many cells on same SysCLK
xNT = Buried counter for Number or Time, compares with X
and your terms of
- Clear counter on B-low
- Increment counter on every A-rise when B-high
- Capture counter on B-fall, and raise IN to signal event
becomes :
Mode = Gated Counter : INC on A _/=, Enabled by B, Capture & Reload on B =\_
CT.CLK = Ar (use !A for Af)
CT.CE = Bh
CT.RE = Bf
Z.D = CT (implicit)
Z.LE = Bf (raise IN to signal event)
and the close relative, the Gated Timer (swaps SC for Ar)
Mode = Gated Timer : INC on SysCLK, Enabled by B, Capture & Reload on B =\_
CT.CLK = SC
CT.CE = Bh
CT.RE = Bf
Z.D = CT (implicit)
Z.LE = Bf (raise IN to signal event)
Two modes can merge into one here, with an Ar | SC config bit on CT.CLK.
If B is Hi when this is configured and enabled, it will start counting immediately.
Applying X to this mode needs some thought.
Having A count to == X is of less use, as A is being captured by B (and may give any fraction of B as a result)
If the A:B ratio is low, but variable, it could be useful to sum over many B, so dB=X may be more useful ?
X effectively acts as a B prescaler, and some MCUs do offer Capture-edge prescalers.
Mode %01011 = qA/qB-input quadrature encoder
Small state engine turns (optionally filtered) qA.qB signals, into CLK & Direction.
From there, this mode is the same as Mode %01101 = Up/Dn Counter
Mode %01101 (X=0) = Up/Dn Counter : INC/DEC on A _/=, DIRN by B (SW read anytime)
CT.CLK = Ar (use !A for Af)
CT.DIR = Bh
Z.D = CT (implicit)
Z.LE = 1 (continual update)
Mode %01101 (X>0) = Up/Dn Counter : INC/DEC on A _/=, DIRN by B (xNT=X based capture & reload)
CT.CLK = Ar (use !A for Af)
CT.DIR = Bh
CT.RE = (xNT=X)
CT.RV = -1/0/+1 (no missing counts)
Z.D = CT (implicit)
Z.LE = (xNT=X) (raise IN to signal event)
xNT.CLK = SC Timer
xNT.RE = Z.LE Reload X counter when captures to Z
Usage example: One pin cell can have totalize mode(X=0) for absolute distance, and an adjacent pin cell can attach to the same pins, for velocity.
eg 1-10-100ms for X will read change-in-count on that timebase == velocity.
and some more... If I have these right, the pseudo logic equations should match the verilog flows.
%10101 = WP Timer For whole periods in X+ clock cycles, count time
%10111 = WP Counter For whole periods in X+ clock cycles, count periods
%10110 = PW Gated Timer For whole periods in X+ clock cycles, count PWh time
X[31:0] establishes the minimum number of clock cycles to track periods for. Periods are A-input rise/edge to A.B-input rise/edge.
Y[1:0] establishes A-input and B-input rise/edge sensitivity:
Ps = Pulse Start to Pe = Pulse End
%00 = A-input rise to B-input rise (B=A or B=!A is allowed)
%01 = A-input rise to B-input edge (B=A or B=!A is allowed)
%10 = A-input edge to B-input rise (B=A or B=!A is allowed)
%11 = A-input edge to B-input edge (B=A or B=!A is allowed)
All modes need at least 2 Ps, one to start, and one (>X) to capture/restart.
Trig.S = Ps
Trig.R = !CellE
%10101 : WP Timer ~~~~~~~~~~~~~~~~~~~~~~
// WP Timer ( Whole periods, >= X, Count Time )
CT.CLK = SC
CT.CE = Trig Delays leading edge, for whole period, first reading.
CT.RE = Ps & (xNT >= X)
CT.RV = 0/+1 (no missing counts)
Z.D = CT
Z.LE = Ps & (xNT >= X) & raise IN to signal event
xNT.CLK = SC Timer
xNT.RE = Z.LE Reload X counter when captures to Z
%10111 : WP Counter ~~~~~~~~~~~~~~~~~~~~
// WP Counter ( Whole periods, >= X, Count Periods )
CT.CLK = Ps
CT.CE = Trig Delays leading edge, for whole period, first reading.
CT.RE = Ps & (xNT >= X)
CT.RV = 0/+1 (no missing counts)
Z.D = CT
Z.LE = Ps & (xNT >= X) & raise IN to signal event
xNT.CLK = SC Timer
xNT.RE = Z.LE Reload X counter when captures to Z
%10110 : PW Gated Timer ~~~~~~~~~~~~~~~~
// PW Gated Timer ( Whole periods, >= X, Count PWh )
PW.S = Ps
PW.R = Pe | ModeInit
CT.CLK = SC
CT.CE = PW Pulse width collects fraction of High time.
CT.RE = Ps & (xNT >= X)
CT.RV = 0/+1
Z.D = CT
Z.LE = Ps & (xNT >= X) + raise IN to signal event
xNT.CLK = SC Timer
xNT.RE = Z.LE Reload X counter when captures to Z
Continual recapture on every [Ps & (xNT >= X)] is possible, for no missing edges longer timebase totals, for very high precision (ppb) results.
Each smart pin has just a single capture register, so if you want to extract simultaneous info from one signal, attach multiple smart pins.
In all 3 modes, the trigger can be synchronous, so 2 or 3 Smart pins can track down to one SysCLK, the [Ps & (dT >= X)]
Precision Duty Cycle is measured with (PW Gated Timer) / (WP Timer) pair,
Example code for Precision Duty Cycle Init and Run, tbs
Reciprocal Frequency Counter is supported with(WP Counter)/(WP Timer) pair.
Example code for Reciprocal Frequency Counter Init and Run, tbs
If you need to include 0 and 100% cases, those have no edges so a separate static pin handler is required.
old text:
A measurement is taken across some number of A-input rise/edge to B-input rise/edge periods, until X clock cycles elapse and then any period in progress completes.
If the A-input rise/edge is ever coincident with the B-input rise/edge at the end of the period, the start of the next period is registered.
Upon completion, the measurement is placed in Z, IN is raised, and a new measurement begins.
RDPIN/RQPIN can then be used to retrieve the completed measurement.
Z will be limited to $80000000.
The first mode accumulates time within each period, for an oversampled period measurement.
The second mode accumulates A-input trigger states within each period, for an oversampled duty measurement.
The third mode counts the periods.
Knowing how many clock cycles some number of complete periods took, and what the duty was, affords a very time-efficient and precise means of determining frequency and duty cycle. At least two of these measurements must be made concurrently to get useful results.
Jmg, looks good. I will review all this in the morning.
I have a clarify question -
ISTR you could trigger multiple Smart Pin Cells to launch on the same SysCLK edge, (was it using the OUTx as a final GO ?) - but the current DOCs seem to not say that anywhere ?
Using OUTx, I think you can also drive a real pin OUTx, and start a smart Pin cell, on the same SysCLK ? They just need to be in the same group.
..and another question, looking at boundary cases, and extremes of use...
In these modes
%10101 = WP Timer For whole periods in X+ clock cycles, count time
%10111 = WP Counter For whole periods in X+ clock cycles, count periods
%10110 = PW Gated Timer For whole periods in X+ clock cycles, count PWh time
Suppose there is no Period Start (Ps) at all within the X+, but a single Ps arrives later, (rare, but possible)
- does the Z update occur then, or is a second Ps required before Z update ?
ie can we say these modes require at least 2 edges, one of which is > X ?
By releasing a bunch of smart pins from reset all at once, by raising their DIR bits together (OR DIRA,allsmartpins), you would start them off on the same clock edge. In the case of PWM, for example, they would forever be sync'd.
By releasing a bunch of smart pins from reset all at once, by raising their DIR bits together (OR DIRA,allsmartpins), you would start them off on the same clock edge. In the case of PWM, for example, they would forever be sync'd.
Ah, via DIR... cool..
If someone issues a second OR DIRA,xx while the Pin Cell is already active, what happens ?
Any CLR of DIR is ignored / not required ?
So for the above, it would be better to write this small change to reflect this ?
Terminology:
DIRt = Write 1 to DIRA or DIRB, arms/starts the configured mode
CellE = CellEnable, Set by first DIRt after init. Can enable many cells on same SysCLK
..
Trig.R = !CellE
..
PW.R = Pe | !CellE
By releasing a bunch of smart pins from reset all at once, by raising their DIR bits together (OR DIRA,allsmartpins), you would start them off on the same clock edge. In the case of PWM, for example, they would forever be sync'd.
Ah, via DIR... cool..
If someone issues a second OR DIRA,xx while the Pin Cell is already active, what happens ?
Any CLR of DIR is ignored / not required ?
So for the above, it would be better to write this small change to reflect this ?
Terminology:
DIRt = Write 1 to DIRA or DIRB, arms/starts the configured mode
CellE = CellEnable, Set by first DIRt after init. Can enable many cells on same SysCLK
..
Trig.R = !CellE
..
PW.R = Pe | !CellE
Probably. I'm still mustering the energy to get all your terms into my head. I think I'm going to do it all at once.
Probably. I'm still mustering the energy to get all your terms into my head. I think I'm going to do it all at once.
I've done the pseudo logic equations, because my feeling is the smart pins are too complex to explain in a few sentences, especially to non-native English speakers.
I've also used terms more familiar to users of other MCU, like Timer, Counter and Gated Timer.
The pseudo logic equations should be (nearly) as good as circuit diagrams, in showing what sequences occur in a Smart Pin Cell Capture, but much easier to create/copy/paste.
That, plus small code snippets which Init, then launch each mode, should show users how simple the final code can be,
Someone has also suggested GUI configuration support, which could use Graphics, and report these pseudo logic equations as code comments, along with the init/launch code templates.
%10001 = Time A-input high states Continuous high states are counted in clock cycles.
Upon each high-to-low transition, the previous high duration count is placed in Z, and IN is raised. RDPIN/RQPIN can then be used to retrieve the measurement. Z will be limited to $80000000.
During reset (DIR=0), IN is low and Z is set to $00000001.
%10010 = Time X A-input highs Time is measured until X highs are accumulated.
X[31:0] establishes how many highs are to be accumulated.
Time is measured in clock cycles until X highs are accumulated from the input. The measurement is then placed in Z, and IN is raised. RDPIN/RQPIN can then be used to retrieve the measurement. Z will be limited to $80000000.
During reset (DIR=0), IN is low and Z is set to $00000001.
Why are those not one mode, with the usual X=0, X>0 control on X-sampling ?
I'm unclear on why Z limits to $80000000, and why it presets to what is a valid result number ?
I could understand some value being preset, to indicate not-yet-valid, if needed, and Z avoiding that value, but is IN not enough to qualify Valid/new result ?
The pseudo logic docs for these I make as
%10001 : (X=0) Gated Timer, Capture each ~~~~~~~~~~~~~~~~
Gated Timer ( Enabled by Ah, trailing edge capture )
CT.CLK = SC
CT.CE = Ah Increment when A is High
CT.RE = Af
CT.RV = 0/+1 (no missing counts)
Z.D = CT (implicit)
Z.LE = Af + raise IN to signal event
%10001 : (X>0) Gated Timer, Capture after Many ~~~~~~~~~~~~~~~~
Gated Timer ( Enabled by Ah, repeating X times, then trailing edge capture )
CT.CLK = SC
CT.CE = Ah Increment whenever A is High
CT.RE = Af & (xN = X)
CT.RV = 0/+1 (no missing counts)
xNT.CLK = Af Increment after each Ah pulse
xNT.RE = Af & (xN = X) repeat X
Z.D = CT (implicit)
Z.LE = Af & (xN = X) + raise IN to signal event
Z.RE, Z.RV tbc
Chip,
I've not been happy with the 3 of 3 input filters since they were introduced. You must have a 9-bit counter on each input to reach out that many clocks. I'd ditch the 3 samples mechanism, and instead have a simple config decode into a tapping termination compare. With the 9-bit counter resetting on either an input state change or terminal count. This way every sysclock is a valid sample point for superior filtering.
With filter tappings at sysclocks of 1, 3, 7, 15, 31, 63, 127, 255, 511 ... I think, or even numbers might be easier.
Chip,
Please remove mode %10000 = Time A-input states. It's too prone to glitching. Your example of a workaround using mode %10001 is the better solution and could be added to its documentation.
It's also notable that some modes, the later ones, are supersets of others, earlier simpler modes.
An example is mode %10001 = Time A-input high states is eclipsed by both mode %10011 = For X periods, count time and also mode %10101 = For periods in X+ clock cycles, count time.
There is three general groups: Time accumulation, Pulse counting, and Up/Dn positional.
Please remove mode %10000 = Time A-input states. It's too prone to glitching.
Can you expand ? It is a strange claim to say a counter mode is "too prone to glitching" ?!
One counter mode is no more 'prone' than any other, they are all synchronous logic in operation.
An example is mode %10001 = Time A-input high states is eclipsed by both mode %10011 = For X periods, count time and also mode %10101 = For periods in X+ clock cycles, count time.
Almost, but not quite, the details matter.
My wording is deliberately different from Chip's, to try to make those operational differences clearer.
It's also notable that some modes, the later ones, are supersets of others, earlier simpler modes.
Broadly speaking, yes you can reduce modes by applying more of the same rules.
See my example above that merges two modes into %10001 : (X=0) Gated Timer, Capture each
%10001 : (X>0) Gated Timer, Capture after Many
I'm also starting to favour having distinct Selector bits for each of CT.CLK and xNT.CLK sources, as either SysCLK or a Pin
That also reduces/frees up modes, as well as makes things more flexible.
See the discussion around External-Clock Gated Timer case, where it can make more sense to clock xNT from 'the other pin', than Chip's current code does.
Others have mentioned GUI configuration, and the DOCs can include Init and Capture read code snippets for all the common use cases.
Into a spare node space, can fit some missing coverage, with a simple X-mode expansion of
Existing mode, Time A-input states
%10000 = (X=0) Pulse Width Capture (aka Time A-input states )
CT.CLK = SC
CT.CE = 1
CT.RE = Ps
CT.RV = 0/+1 (no missing counts)
Z.D = CT (implicit)
Z.LE = Pe + raise IN to signal event + C = Pin
Example: If Ps=Pe=either edge, Z captures the time since last edge every time.
This can be used to decode FSK or edge-position protocols
The below modes are X(dT) threshold versions of the above
These modes can detect Break (GE) or Glitches (LE) on high speed data streams, where SW checking cannot keep up.
Can be used for AutoBAUD, and capture of peak events.
%10010a : Monostable / PW Detector ~~~~~~~~~~~~~~~~
PWDetectLT ( Compares Pulse width with X, captures @ Pe if Pe occurs before X )
CT.CLK = SC
CT.CE = 1
CT.RE = Ps
CT.RV = 0/+1 (no missing counts)
xNT.CLK = SC Compare width
xNT.RE = Ps
Z.D = CT (implicit)
Z.LE = !(xNT >= X) & Pe Capture @Pe, if Pe < X
+ raise IN to signal event
fC.LE = Z.LE
fC.D = INA Set ERR if last capture not yet read
%10010b : Monostable / PW Detector ~~~~~~~~~~~~~~~~
PWDetectGE ( Compares Pulse width with X, captures @ Pe if X occurs before Pe )
CT.CLK = SC
CT.CE = 1
CT.RE = Ps
CT.RV = 0/+1 (no missing counts)
xNT.CLK = SC Compare width
xNT.RE = Ps
Z.D = CT (implicit)
Z.LE = (xNT >= X) & Pe Capture @Pe, if Pe >= X
+ raise IN to signal event
fC.LE = Z.LE
fC.D = INA Set ERR if last capture not yet read
Edit: To add Carry Flag read as Overrun error indication
JMG,
It must be the Y register being used for the second accumulator. There isn't any more spare flops in the Smartpin.
perhaps, but from the user viewpoint, Y has some config bits & the DOCs say Y - mode-specific parameter (write-only)
If that is later used for counting, that's fine, but I'll give that hidden counter a different name to avoid confusing users.
I'll flesh out the example of how mode %10001 is doable in other mode.
Look forward to seeing how ....
Problem is, they are similar, but not quite identical.
%10101 = WP Timer For whole periods in X+ clock cycles, count time
%10111 = WP Counter For whole periods in X+ clock cycles, count periods
%10110 = PW Gated Timer For whole periods in X+ clock cycles, count PWh time
That 'whole periods' is crucial, and is not present on
%10000 = Time A-input states.
This simpler Gated Timer mode, can capture on a single edge.
Of course, you can change the logic in the other modes, to disable the whole periods, but that's what a separate mode is for....
Comments
The bigger the array, the less significant the row and column circuitry becomes.
Thanks Chip.
When P2 settles, which should be any day now
"SP" in that quote stands for single ported. Those details were generated just before the die was increased in size.
I'm starting with terminology, and I think we need to add a name for the buried CounterTimer, as below.
You may be able to simplify the DOCs and logic, if a single config bit can select PinCK or SysCLK for CounterTimer ?
and your terms of
becomes : Two modes can merge into one here, with an Ar | SC config bit on CT.CLK.
If B is Hi when this is configured and enabled, it will start counting immediately.
Applying X to this mode needs some thought.
Having A count to == X is of less use, as A is being captured by B (and may give any fraction of B as a result)
If the A:B ratio is low, but variable, it could be useful to sum over many B, so dB=X may be more useful ?
X effectively acts as a B prescaler, and some MCUs do offer Capture-edge prescalers.
Usage example: One pin cell can have totalize mode(X=0) for absolute distance, and an adjacent pin cell can attach to the same pins, for velocity.
eg 1-10-100ms for X will read change-in-count on that timebase == velocity.
%10101 = WP Timer For whole periods in X+ clock cycles, count time
%10111 = WP Counter For whole periods in X+ clock cycles, count periods
%10110 = PW Gated Timer For whole periods in X+ clock cycles, count PWh time
X[31:0] establishes the minimum number of clock cycles to track periods for. Periods are A-input rise/edge to A.B-input rise/edge.
Y[1:0] establishes A-input and B-input rise/edge sensitivity: Ps = Pulse Start to Pe = Pulse End %00 = A-input rise to B-input rise (B=A or B=!A is allowed) %01 = A-input rise to B-input edge (B=A or B=!A is allowed) %10 = A-input edge to B-input rise (B=A or B=!A is allowed) %11 = A-input edge to B-input edge (B=A or B=!A is allowed) All modes need at least 2 Ps, one to start, and one (>X) to capture/restart. Trig.S = Ps Trig.R = !CellE %10101 : WP Timer ~~~~~~~~~~~~~~~~~~~~~~ // WP Timer ( Whole periods, >= X, Count Time ) CT.CLK = SC CT.CE = Trig Delays leading edge, for whole period, first reading. CT.RE = Ps & (xNT >= X) CT.RV = 0/+1 (no missing counts) Z.D = CT Z.LE = Ps & (xNT >= X) & raise IN to signal event xNT.CLK = SC Timer xNT.RE = Z.LE Reload X counter when captures to Z %10111 : WP Counter ~~~~~~~~~~~~~~~~~~~~ // WP Counter ( Whole periods, >= X, Count Periods ) CT.CLK = Ps CT.CE = Trig Delays leading edge, for whole period, first reading. CT.RE = Ps & (xNT >= X) CT.RV = 0/+1 (no missing counts) Z.D = CT Z.LE = Ps & (xNT >= X) & raise IN to signal event xNT.CLK = SC Timer xNT.RE = Z.LE Reload X counter when captures to Z %10110 : PW Gated Timer ~~~~~~~~~~~~~~~~ // PW Gated Timer ( Whole periods, >= X, Count PWh ) PW.S = Ps PW.R = Pe | ModeInit CT.CLK = SC CT.CE = PW Pulse width collects fraction of High time. CT.RE = Ps & (xNT >= X) CT.RV = 0/+1 Z.D = CT Z.LE = Ps & (xNT >= X) + raise IN to signal event xNT.CLK = SC Timer xNT.RE = Z.LE Reload X counter when captures to ZContinual recapture on every [Ps & (xNT >= X)] is possible, for no missing edges longer timebase totals, for very high precision (ppb) results.Each smart pin has just a single capture register, so if you want to extract simultaneous info from one signal, attach multiple smart pins.
In all 3 modes, the trigger can be synchronous, so 2 or 3 Smart pins can track down to one SysCLK, the [Ps & (dT >= X)]
Precision Duty Cycle is measured with (PW Gated Timer) / (WP Timer) pair, Reciprocal Frequency Counter is supported with(WP Counter)/(WP Timer) pair.
If you need to include 0 and 100% cases, those have no edges so a separate static pin handler is required.
old text:
A measurement is taken across some number of A-input rise/edge to B-input rise/edge periods, until X clock cycles elapse and then any period in progress completes.
If the A-input rise/edge is ever coincident with the B-input rise/edge at the end of the period, the start of the next period is registered.
Upon completion, the measurement is placed in Z, IN is raised, and a new measurement begins.
RDPIN/RQPIN can then be used to retrieve the completed measurement.
Z will be limited to $80000000.
The first mode accumulates time within each period, for an oversampled period measurement.
The second mode accumulates A-input trigger states within each period, for an oversampled duty measurement.
The third mode counts the periods.
Knowing how many clock cycles some number of complete periods took, and what the duty was, affords a very time-efficient and precise means of determining frequency and duty cycle. At least two of these measurements must be made concurrently to get useful results.
ISTR you could trigger multiple Smart Pin Cells to launch on the same SysCLK edge, (was it using the OUTx as a final GO ?) - but the current DOCs seem to not say that anywhere ?
Using OUTx, I think you can also drive a real pin OUTx, and start a smart Pin cell, on the same SysCLK ? They just need to be in the same group.
..and another question, looking at boundary cases, and extremes of use...
In these modes
%10101 = WP Timer For whole periods in X+ clock cycles, count time
%10111 = WP Counter For whole periods in X+ clock cycles, count periods
%10110 = PW Gated Timer For whole periods in X+ clock cycles, count PWh time
Suppose there is no Period Start (Ps) at all within the X+, but a single Ps arrives later, (rare, but possible)
- does the Z update occur then, or is a second Ps required before Z update ?
ie can we say these modes require at least 2 edges, one of which is > X ?
By releasing a bunch of smart pins from reset all at once, by raising their DIR bits together (OR DIRA,allsmartpins), you would start them off on the same clock edge. In the case of PWM, for example, they would forever be sync'd.
If someone issues a second OR DIRA,xx while the Pin Cell is already active, what happens ?
Any CLR of DIR is ignored / not required ?
So for the above, it would be better to write this small change to reflect this ?
Probably. I'm still mustering the energy to get all your terms into my head. I think I'm going to do it all at once.
I've done the pseudo logic equations, because my feeling is the smart pins are too complex to explain in a few sentences, especially to non-native English speakers.
I've also used terms more familiar to users of other MCU, like Timer, Counter and Gated Timer.
The pseudo logic equations should be (nearly) as good as circuit diagrams, in showing what sequences occur in a Smart Pin Cell Capture, but much easier to create/copy/paste.
That, plus small code snippets which Init, then launch each mode, should show users how simple the final code can be,
Someone has also suggested GUI configuration support, which could use Graphics, and report these pseudo logic equations as code comments, along with the init/launch code templates.
%10001 = Time A-input high states Continuous high states are counted in clock cycles.
Upon each high-to-low transition, the previous high duration count is placed in Z, and IN is raised. RDPIN/RQPIN can then be used to retrieve the measurement. Z will be limited to $80000000.
During reset (DIR=0), IN is low and Z is set to $00000001.
%10010 = Time X A-input highs Time is measured until X highs are accumulated.
X[31:0] establishes how many highs are to be accumulated.
Time is measured in clock cycles until X highs are accumulated from the input. The measurement is then placed in Z, and IN is raised. RDPIN/RQPIN can then be used to retrieve the measurement. Z will be limited to $80000000.
During reset (DIR=0), IN is low and Z is set to $00000001.
Why are those not one mode, with the usual X=0, X>0 control on X-sampling ?
I'm unclear on why Z limits to $80000000, and why it presets to what is a valid result number ?
I could understand some value being preset, to indicate not-yet-valid, if needed, and Z avoiding that value, but is IN not enough to qualify Valid/new result ?
The pseudo logic docs for these I make as
I've not been happy with the 3 of 3 input filters since they were introduced. You must have a 9-bit counter on each input to reach out that many clocks. I'd ditch the 3 samples mechanism, and instead have a simple config decode into a tapping termination compare. With the 9-bit counter resetting on either an input state change or terminal count. This way every sysclock is a valid sample point for superior filtering.
With filter tappings at sysclocks of 1, 3, 7, 15, 31, 63, 127, 255, 511 ... I think, or even numbers might be easier.
I think mode %10010 is different to that. Here's my take:
Please remove mode %10000 = Time A-input states. It's too prone to glitching. Your example of a workaround using mode %10001 is the better solution and could be added to its documentation.
An example is mode %10001 = Time A-input high states is eclipsed by both mode %10011 = For X periods, count time and also mode %10101 = For periods in X+ clock cycles, count time.
There is three general groups: Time accumulation, Pulse counting, and Up/Dn positional.
One counter mode is no more 'prone' than any other, they are all synchronous logic in operation.
My wording is deliberately different from Chip's, to try to make those operational differences clearer.
See my example above that merges two modes into
%10001 : (X=0) Gated Timer, Capture each
%10001 : (X>0) Gated Timer, Capture after Many
I'm also starting to favour having distinct Selector bits for each of CT.CLK and xNT.CLK sources, as either SysCLK or a Pin
That also reduces/frees up modes, as well as makes things more flexible.
See the discussion around External-Clock Gated Timer case, where it can make more sense to clock xNT from 'the other pin', than Chip's current code does.
Others have mentioned GUI configuration, and the DOCs can include Init and Capture read code snippets for all the common use cases.
Existing mode, Time A-input states
Example: If Ps=Pe=either edge, Z captures the time since last edge every time.
This can be used to decode FSK or edge-position protocols
The below modes are X(dT) threshold versions of the above
These modes can detect Break (GE) or Glitches (LE) on high speed data streams, where SW checking cannot keep up.
Can be used for AutoBAUD, and capture of peak events.
%10010a : Monostable / PW Detector ~~~~~~~~~~~~~~~~ PWDetectLT ( Compares Pulse width with X, captures @ Pe if Pe occurs before X ) CT.CLK = SC CT.CE = 1 CT.RE = Ps CT.RV = 0/+1 (no missing counts) xNT.CLK = SC Compare width xNT.RE = Ps Z.D = CT (implicit) Z.LE = !(xNT >= X) & Pe Capture @Pe, if Pe < X + raise IN to signal event fC.LE = Z.LE fC.D = INA Set ERR if last capture not yet read %10010b : Monostable / PW Detector ~~~~~~~~~~~~~~~~ PWDetectGE ( Compares Pulse width with X, captures @ Pe if X occurs before Pe ) CT.CLK = SC CT.CE = 1 CT.RE = Ps CT.RV = 0/+1 (no missing counts) xNT.CLK = SC Compare width xNT.RE = Ps Z.D = CT (implicit) Z.LE = (xNT >= X) & Pe Capture @Pe, if Pe >= X + raise IN to signal event fC.LE = Z.LE fC.D = INA Set ERR if last capture not yet readEdit: To add Carry Flag read as Overrun error indicationIt must be the Y register being used for the second accumulator. There isn't any more spare flops in the Smartpin.
The glitching is as documented by Chip.
I'll flesh out the example of how mode %10001 is doable in other mode.
Y - mode-specific parameter (write-only)
If that is later used for counting, that's fine, but I'll give that hidden counter a different name to avoid confusing users.
I missed that, any links ?
Look forward to seeing how ....
Problem is, they are similar, but not quite identical.
%10101 = WP Timer For whole periods in X+ clock cycles, count time
%10111 = WP Counter For whole periods in X+ clock cycles, count periods
%10110 = PW Gated Timer For whole periods in X+ clock cycles, count PWh time
That 'whole periods' is crucial, and is not present on
%10000 = Time A-input states.
This simpler Gated Timer mode, can capture on a single edge.
Of course, you can change the logic in the other modes, to disable the whole periods, but that's what a separate mode is for....