Smart Pins Docs and features

24567

Comments

  • 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.
  • 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.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • 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" ;)
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • evanhevanh Posts: 3,960
    Cluso,
    "SP" in that quote stands for single ported. Those details were generated just before the die was increased in size.
    $50,000 buys you a discrediting of a journalist
  • evanhevanh Posts: 3,960
    edited May 22 Vote Up0Vote Down
    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.
    $50,000 buys you a discrediting of a journalist
  • evanhevanh Posts: 3,960
    Not to mention the trials Chip went through trying to get any Cog talking to any Cog.
    $50,000 buys you a discrediting of a journalist
  • jmgjmg Posts: 10,208
    edited May 25 Vote Up0Vote Down
    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
    
    
    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.
  • jmgjmg Posts: 10,208
    edited May 25 Vote Up0Vote Down
    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.
  • jmgjmg Posts: 10,208
    edited May 25 Vote Up0Vote Down
    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.
  • jmgjmg Posts: 10,208
    edited May 23 Vote Up0Vote Down
    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 ?
  • 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.
  • jmgjmg Posts: 10,208
    edited May 23 Vote Up0Vote Down
    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
    
  • 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.
  • jmgjmg Posts: 10,208
    edited May 23 Vote Up0Vote Down
    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.
  • jmgjmg Posts: 10,208
    edited May 24 Vote Up0Vote Down
    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
    
  • evanhevanh Posts: 3,960
    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:
    741 x 413 - 5K
    845 x 584 - 7K
    $50,000 buys you a discrediting of a journalist
  • evanhevanh Posts: 3,960
    edited May 24 Vote Up0Vote Down
    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.
    $50,000 buys you a discrediting of a journalist
  • evanhevanh Posts: 3,960
    Ah, one of those tappings would need to be deleted to fit in an encoded packing of three bits.
    $50,000 buys you a discrediting of a journalist
  • evanhevanh Posts: 3,960
    edited May 24 Vote Up0Vote Down
    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
    
    $50,000 buys you a discrediting of a journalist
  • evanhevanh Posts: 3,960
    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
    
    $50,000 buys you a discrediting of a journalist
  • evanhevanh Posts: 3,960
    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.
    $50,000 buys you a discrediting of a journalist
  • evanhevanh Posts: 3,960
    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.
    $50,000 buys you a discrediting of a journalist
  • jmgjmg Posts: 10,208
    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.


  • jmgjmg Posts: 10,208
    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.

  • jmgjmg Posts: 10,208
    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.

  • jmgjmg Posts: 10,208
    edited May 26 Vote Up0Vote Down
    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
  • evanhevanh Posts: 3,960
    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.
    $50,000 buys you a discrediting of a journalist
  • jmgjmg Posts: 10,208
    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....



  • evanhevanh Posts: 3,960
    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
    $50,000 buys you a discrediting of a journalist
Sign In or Register to comment.