Smart Pins Docs and features - Page 2 — Parallax Forums

# Smart Pins Docs and features

• Posts: 14,133
evanh wrote: »
If any fractional increase in HubRAM is contemplated it'll need to be as an extra 16 blocks if I'm not mistaken.

From http://forums.parallax.com/discussion/comment/1371876/#Comment_1371876
```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.
• Posts: 18,069
evanh wrote: »
If any fractional increase in HubRAM is contemplated it'll need to be as an extra 16 blocks if I'm not mistaken.

From http://forums.parallax.com/discussion/comment/1371876/#Comment_1371876
```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.
• Posts: 18,069
cgracey wrote: »
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"
• Posts: 15,278
Cluso,
"SP" in that quote stands for single ported. Those details were generated just before the die was increased in size.
• Posts: 15,278
edited 2017-05-22 11:58
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.
• Posts: 15,278
Not to mention the trials Chip went through trying to get any Cog talking to any Cog.
• Posts: 15,154
edited 2017-05-25 03:35
cgracey wrote: »
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

```
```- 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.
• Posts: 15,154
edited 2017-05-25 03:38
and this for more modes.
```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.
• Posts: 15,154
edited 2017-05-25 03:34
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.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.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.
• Posts: 14,133
Jmg, looks good. I will review all this in the morning.
• Posts: 15,154
edited 2017-05-23 22:44
cgracey wrote: »
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 ?
• Posts: 14,133
Jmg,

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.
• Posts: 15,154
edited 2017-05-23 21:59
cgracey wrote: »
Jmg,

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
```
• Posts: 14,133
jmg wrote: »
cgracey wrote: »
Jmg,

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.
• Posts: 15,154
edited 2017-05-23 22:44
cgracey wrote: »
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.
• Posts: 15,154
edited 2017-05-24 19:52
Looking at these ones...

%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
```
• Posts: 15,278
jmg wrote: »
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
Here's a couple of variations I drew up a long time ago. Note the second one saves a couple of flops by providing the two bottom bits of the counter:
• Posts: 15,278
edited 2017-05-24 14:30
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.
• Posts: 15,278
Ah, one of those tappings would need to be deleted to fit in an encoded packing of three bits.
• Posts: 15,278
edited 2017-05-24 14:55
JMG,
I think mode %10010 is different to that. Here's my take:
```CT.CLK  = SC
CT.CE   = 1    Increments always
CT.RE   = (Y == X)
Y.CLK   = Ah    Increments while A is high
Y.RE    = (Y == X)   repeat X
Z.D     = CT (implicit)
Z.LE    = (Y == X)  + raise IN to signal event
```
• Posts: 15,278
Another interpretation for mode %10010 could be:
```CT.CLK  = SC
CT.CE   = 1    Increments always
CT.RE   = (Y == X)
Y.CLK   = Af    Increments one per A pulse
Y.RE    = (Y == X)   repeat X
Z.D     = CT (implicit)
Z.LE    = (Y == X)  + raise IN to signal event
```
• Posts: 15,278
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.
• Posts: 15,278
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.
• Posts: 15,154
evanh wrote: »
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.

• Posts: 15,154
evanh wrote: »
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.

• Posts: 15,154
evanh wrote: »
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.

• Posts: 15,154
edited 2017-05-26 03:49
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

```
• Posts: 15,278
JMG,
It 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.
• Posts: 15,154
evanh wrote: »
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.
evanh wrote: »
The glitching is as documented by Chip.
I missed that, any links ?
evanh wrote: »
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....

• Posts: 15,278
jmg wrote: »
evanh wrote: »
The glitching is as documented by Chip.
I missed that, any links ?
http://forums.parallax.com/discussion/162298/prop2-fpga-files-updated-19-may-2017-version-19