Shop OBEX P1 Docs P2 Docs Learn Events
Smart Pins Docs and features — Parallax Forums

Smart Pins Docs and features

This from questions in another thread...

The current DOCs say this :

Each smart I/O pin has the following functions:

8-bit, 120-ohm (3ns) and 1k-ohm DACs with 16-bit oversampling, noise, and high/low digital modes
Delta-sigma ADC with 5 ranges, 2 sources, and VIO/GIO calibration
Logic, Schmitt, pin-to-pin-comparator, and 8-bit-level-comparator input modes
3-of-3 input filtering with selectable sample rate
Incorporation of inputs from relative pins, -3..+3
Negative or positive local feedback, with or without clocking
Separate high and low output drive modes: logic/1.5k/15k/150k/1mA/100uA/10uA/float
Programmable 32-bit clock output, transition output, NCO/duty output
Triangle/sawtooth/SMPS PWM output, 16-bit frame with 16-bit prescaler
Quadrature decoding with 32-bit counter, both position and velocity modes
Twelve different 32-bit measurements involving one or two signals
USB full-speed and low-speed (via pin pairs)
Synchronous serial transmit and receive, 1..32 bits
Asynchronous serial transmit and receive, 1..32 bits, up to clock/3


but that list does not separate config, from modes, so should be split into 2 sections.
eg Pin Config suggests 3-of-3 Filtering is not a mode, but can apply at any time.

If I work backwards from the Config registers, it seems there should be two lists

Under Pin config, there is the low-level and smart-pin configuration for each I/O pin:
D/# = %AAAA_BBBB_FFF_PPPPPPPPPPPPP_TT_MMMMM_0

AAAA,BBBB set the relative pin MUX placement
FFF sets 3-of-3 input filtering with selectable sample rate
PPPPPPPPPPPPP Controls DAC & Drive, and looks to be only partially filled (for FPGA subset?)
TT pin DIR/OUT control

and these features belong under Mode, being a one-of-these choice.

Programmable 32-bit clock output, transition output, NCO/duty output
Triangle/sawtooth/SMPS PWM output, 16-bit frame with 16-bit prescaler
Quadrature decoding with 32-bit counter, both position and velocity modes
Twelve different 32-bit measurements involving one or two signals
USB full-speed and low-speed (via pin pairs)
Synchronous serial transmit and receive, 1..32 bits
Asynchronous serial transmit and receive, 1..32 bits, up to clock/3

Full mode list is
%MMMMM:	
00000   = smart pin off (default)
00001   = long repository              (P[12:10] != %101)
00010   = long repository              (P[12:10] != %101)
00011   = long repository              (P[12:10] != %101)
00001   = DAC noise                    (P[12:10]  = %101)
00010   = DAC 16-bit dither, noise     (P[12:10]  = %101)
00011   = DAC 16-bit dither, PWM       (P[12:10]  = %101)
00100*  = pulse/cycle output
00101*  = transition output
00110*  = NCO frequency
00111*  = NCO duty
01000*  = PWM triangle
01001*  = PWM sawtooth
01010*  = PWM switch-mode power supply, V and I feedback
01011   = periodic/continuous, A-B quadrature encoder
01100   = periodic/continuous, inc on A-high
01101   = periodic/continuous, inc on A-rise
01110   = periodic/continuous, inc on A-high, dec on B-high
01111   = periodic/continuous, inc on A-rise, dec on B-rise
10000   = time A states
10001   = time A-high states
10010   = time X A-highs
10011   = for X periods, count time
10100   = for X periods, count states
10101   = for periods in X+ clocks, count time
10110   = for periods in X+ clocks, count states
10111   = for periods in X+ clocks, count periods
11000*  = USB host, low-speed          (even/odd pin pair = DM/DP)
11001*  = USB host, high-speed         (even/odd pin pair = DM/DP)
11010*  = USB device, low-speed        (even/odd pin pair = DM/DP)
11011*  = USB device, high-speed       (even/odd pin pair = DM/DP)


Questions were asked ( by dMajo) round a) Quad signal filtering, b) Quad reset & c) Quadrature choices

a) It seems the filtering is there, via the FFF field, for these choices
		000 = A, B (default)
		100 = A, B, filtered 3-of-3 at clock/1
		101 = A, B, filtered 3-of-3 at clock/8
		110 = A, B, filtered 3-of-3 at clock/64
		111 = A, B, filtered 3-of-3 at clock/512
however, it also says
The resultant ‘A’ will drive the IN signal in non-smart-pin modes.
but does that mean the filtering is not present in Smart-Pin case, or just that filtering is also available in Non-smart pin (direct SW read) ?

b) Quad reset is not in HW, as that would need a 3rd pin path, but the P2 has interrupts, and the docs say
The quadrature encoder can be “zeroed” by pulsing DIR low at any time. There is no need to do another WXPIN.
During reset (DIR=0), IN is low and Z is set to the adder value (0/1/-1)

So it looks like an interrupt from the Reset (Z) pin can SW reset ? - at up to ?? MHz speeds ?

c) The all-edges Quad mode is supported, but missing seems to be CLOCK and DIRECTION encoder support ?
It is common for Steppers to use CLK & DIRN, so an ability to 'clip onto' that control interface to extract position accumulate, is useful.

Using the nearby-mux feature, it should be possible to have a Stepper.CLK generated by NCO hardware or SW, and Stepper.DIRN by SW, and an attached smart pin, reading the (assumed) position.
Unclear if that could pack into 2 pin cells, issues are mainly around OUT.IN ? I think yes ?

( There is another mode that is Clock UP, Clock DN signals, and some gated (clock enable) modes )
To add CLK & DIRN looks trivial, but should that be a unique mode, or a sub-mode of Quadrature ?
«13456717

Comments

  • evanhevanh Posts: 15,091
    edited 2017-05-12 23:08
    b) is a non-issue. Setting the hardware counter is the wrong solution. Treat it as a read-only counter. Any use of quadrature counters is via software, so software can keep a copy of the "zero" positions to be used as needed.

    c) would need a new mode. Although it could be merged with the plain A-input count-up mode, %MMMMM = 01101. The difficulty with making them a single mode is the B-input becomes active and has to be muted somehow if not wanting to use it. The best I came up with was to set the B-input selector config to %BBBB = 1100, and do an OUTH to that smartpin so that the forced high is treated as a steady low at the smartpin B input.
    D/# = %AAAA_BBBB_FFF_PPPPPPPPPPPPP_TT_MMMMM_0
    
    %BBBB:    ‘B’ input selector
              0xxx = true (default)
              1xxx = inverted
              x000 = this pin’s read state (default)
              x001 = relative +1 pin’s read state
              x010 = relative +2 pin’s read state
              x011 = relative +3 pin’s read state
              x100 = this pin’s OUT bit from cogs
              x101 = relative -3 pin’s read state
              x110 = relative -2 pin’s read state
              x111 = relative -1 pin’s read state
    
  • jmgjmg Posts: 15,140
    edited 2017-05-13 01:26
    evanh wrote: »
    c) would need a new mode. Although it could be merged with the plain A-input count-up mode, %MMMMM = 01101. The difficulty with making them a single mode is the B-input becomes active and has to be muted somehow if not wanting to use it. The best I came up with was to set the B-input selector config to %BBBB = 1100, and do an OUTH to that smartpin so that the forced high is treated as a steady low at the smartpin B input.
    Yes, that could give a means to disable & force, if the OUT bit is spare and available ?
    That would allow CLK.DIRN as well as UP and DOWN counters, in the one mode.
    It may simplify overall modes, as it gives a means to remove the B condition.

    Another means to 'disable B' could be to test for (BBBB==AAAA,) as it makes little/no sense to map the SAME pin to a dual-pin use.
    With that, you could add CLK and CLKENABLE modes to the COUNT A modes.
  • The smart pubs overlap. Can't these things be done using more than one of them operating on the same physical pin?

    IMHO, it will be rare to employ all 64.
  • How do you use the smart pins for ADC?

    Tom
  • jmgjmg Posts: 15,140
    potatohead wrote: »
    The smart pubs overlap. Can't these things be done using more than one of them operating on the same physical pin?
    Not sure what you mean here ?
    There are a number of modes that use two pins, A,B in some combination. Those make no sense 'using more than one of them operating on the same physical pin'

    You can map up to 4 Smart Pin cells onto one single pin, but that is not a two-pin operation.
    That might be done if you wanted to capture frequency and precision duty cycle, for example.

  • evanhevanh Posts: 15,091
    potatohead wrote: »
    The smart pubs overlap. Can't these things be done using more than one of them operating on the same physical pin?

    IMHO, it will be rare to employ all 64.
    I can't see a way to use a second Smartpin to manage combining clock + direction inputs.

    That said, I've not got my head around the differing descriptions in the later, more complex, counter modes. For example, %10111 = For periods in X+ clock cycles, count periods, might do the job ...
  • evanhevanh Posts: 15,091
    twm47099 wrote: »
    How do you use the smart pins for ADC?
    That one would be mode %01100 = Count A-input highs. It works with the simplest of delta-sigma ADC hardware, which is what the Prop2 has built-in.

    Regular sampling of the Z register, "decimating", gives you an ever increasing value. In software you then subtract the previously sampled value, "derivative", to give you the ADC level.
  • jmgjmg Posts: 15,140
    evanh wrote: »
    That said, I've not got my head around the differing descriptions in the later, more complex, counter modes. For example, %10111 = For periods in X+ clock cycles, count periods, might do the job ...
    Not quite - those modes are for whole-entity counting, for higher precision measurements.
    The >= X sets a minimum capture time, but that time rounds up to the next whole cycle of Fin

    FWIR, this comment
    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.
    means there is a single capture destination, so if you want Time and Periods, you need two Pin cells working closely sync'd.
    Likewise, if you want precise duty cycle, you need both LOW and HIGH time captures (of one, or many, whole cycles), that's also 2 Pin cells.
  • evanhevanh Posts: 15,091
    edited 2017-05-13 07:25
    evanh wrote: »
    twm47099 wrote: »
    How do you use the smart pins for ADC?
    That one would be mode %01100 = Count A-input highs. It works with the simplest of delta-sigma ADC hardware, which is what the Prop2 has built-in.
    Maybe modes %10011 = For X periods, count time and %10101 = For periods in X+ clock cycles, count time could do it as well. I'm not clear on how those work though.
  • evanhevanh Posts: 15,091
    jmg wrote: »
    [/i] means there is a single capture destination, so if you want Time and Periods, you need two Pin cells working closely sync'd.
    Likewise, if you want precise duty cycle, you need both LOW and HIGH time captures (of one, or many, whole cycles), that's also 2 Pin cells.
    I'm guessing but the important part here is that B input can control A rise counting.

    What I'm thinking is maybe the timeout can be set way high and effectively ignored. Then use two Smartpins, one counts up on A rises with B low say, and the other Smartpin counts up on A rises and B high. Then software subtracts the second Z from the first Z to get the total count.
  • jmgjmg Posts: 15,140
    jmg wrote: »
    ...
    Another means to 'disable B' could be to test for (BBBB==AAAA,) as it makes little/no sense to map the SAME pin to a dual-pin use.
    With that, you could add CLK and CLKENABLE modes to the COUNT A modes.

    I also note X[] is used in other modes for control, so here X[31] could be used for Control-Via-B Enable , where B is CTR DIRN or CLK ENABLE, depending on mode, and that leaves X[30..0] as SysCLKs to measure over. That's still 13 seconds, at 160MHz so should be enough, more is easily managed in software as needed.

  • evanhevanh Posts: 15,091
    evanh wrote: »
    twm47099 wrote: »
    How do you use the smart pins for ADC?
    That one would be mode %01100 = Count A-input highs. It works with the simplest of delta-sigma ADC hardware, which is what the Prop2 has built-in.

    Regular sampling of the Z register, "decimating", gives you an ever increasing value. In software you then subtract the previously sampled value, "derivative", to give you the ADC level.
    There is still the question of enabling the ADC hardware as the input source for the Smartpin. That's not clearly documented as yet - It doesn't exist in the FPGA of course.
  • dMajodMajo Posts: 855
    edited 2017-05-13 14:30
    This is a common encoder output
    A:11000011110000111100001111000011 (eg 1024ppr) 11000011
    B:11110000111100001111000011110000 (eg 1024ppr) 11110000
    Z:11110000000000000000000000000000 (eg 1024ppr) 00001111
    
    Here the Z pulse is synced with A/B and with direct reset/preset guaranty that, during the further rotation/movement , A/B signals are not lost

    @evanh: b) is an issue. Because normal counter modules the counter increases and decreases AND (P)RESETS without user action, autonomously.
    You can handle it via sw, but it will slow the bandwidth and/ore lose adjacent a/b pulses/edges
    Having an internal/sw relative zero will force math operations between the real-time counter and internal zero memory. This math is not simple add/sub but also take in account the hw counter roll-over.

    Pulse&Dir:
    In this mode the rising-edge of A increase/decrease the counter based on state of B. This can be used with the same A/B/Z encoder (where also B pulses with 90° phase shift) but can be also used with any clock source on A and stable state on B.

    An other thing I would like to understand is if there is an differential input mode (ed with adjacent pin) that beside for normal input can be also used in quadrature mode as many encoders provide differential outputs (so a total of 6 signals for A/B/Z).


    BTW:
    jmg wrote: »
    Separate high and low output drive modes: logic/1.5k/15k/150k/1mA/100uA/10uA/float
    How do you understand the floath output?
    Is it open collector/drain with selectable stable/driven high/low state?
    Using this will be enough to drive the out or, as P1, you will still need to drive DIR and preset OUT?
    The former (driving OUT in any case) will make the code more compact in case of configurable drivers as it will be enough to setup it at the beginning and non continuously switch betbeen OUT and DIR instructions in the code.
  • evanhevanh Posts: 15,091
    dMajo wrote: »
    You can handle it via sw, but it will slow the bandwidth and/ore lose adjacent a/b pulses/edges
    Just don't go re-zeroing at speed. If there is concern for on-the-fly lost position then it's time to fix the faulty equipment.
    Having an internal/sw relative zero will force math operations between the real-time counter and internal zero memory. This math is not simple add/sub but also take in account the hw counter roll-over.
    Smartpin Z counter is 32 bit, the same as Cog natural integers. The maths is as simple as a single subtract.
  • evanhevanh Posts: 15,091
    edited 2017-05-13 23:26
    dMajo wrote: »
    An other thing I would like to understand is if there is an differential input mode (ed with adjacent pin) that beside for normal input can be also used in quadrature mode as many encoders provide differential outputs (so a total of 6 signals for A/B/Z).
    Nope. The closest is the USB modes but that's a special case with non-differential states as well.

    It wouldn't be desirable anyway as it doubles the pin count requirement. Use cheap line receivers and save the Prop pins for something more useful.
  • evanh wrote: »
    dMajo wrote: »
    You can handle it via sw, but it will slow the bandwidth and/ore lose adjacent a/b pulses/edges
    Just don't go re-zeroing at speed. If there is concern for on-the-fly lost position then it's time to fix the faulty equipment.
    This is an answer of the person that only knows linear axis. There is also rotating axis where the the position are degrees.
    evanh wrote: »
    It wouldn't be desirable anyway as it doubles the pin count requirement. Use cheap line receivers and save the Prop pins for something more useful.
    Pins could be more useful for something else only when you don't have them enough. Otherwise external components, even if cheap, only increases PCB complexity and BOM costs.
  • evanhevanh Posts: 15,091
    edited 2017-05-14 01:42
    dMajo wrote: »
    This is an answer of the person that only knows linear axis. There is also rotating axis where the the position are degrees.
    Don't worry, using an offset as the zero reference makes no difference to the overall effort of managing rotating machinery. I've done my fair share in that department. Modulo'ing became almost invisible to me back in the day. I learnt pretty quickly that (x - limit > 0) was far superior to (x > limit). ie: everything becomes relative calculations even though the numbers are representing absolute positions.
    evanh wrote: »
    It wouldn't be desirable anyway as it doubles the pin count requirement. Use cheap line receivers and save the Prop pins for something more useful.
    Pins could be more useful for something else only when you don't have them enough. Otherwise external components, even if cheap, only increases PCB complexity and BOM costs.
    People do like to complain about BOM a lot more than it really matters.

    Differential is not there in the Prop2. Maybe is can be considered for a Prop3 feature. Maybe a Smartpin cell could be two pins for each cell and have more complexity per cell ...
  • jmgjmg Posts: 15,140
    dMajo wrote: »
    An other thing I would like to understand is if there is an differential input mode (ed with adjacent pin) that beside for normal input can be also used in quadrature mode as many encoders provide differential outputs (so a total of 6 signals for A/B/Z).
    USB modes have some form of Differential IP, not sure is that is true differential, or the common mode range it will have.
    That may be limited to USB only, the DOCs are sparse on this detail.

    You can still usefully use differential sensors, for the better EMC specs, just with single ended RX.

    Keep in mind proper differential buffers have a much wider common mode tolerance than a CMOS logic process can give, so if you really need differential signals because everything is very noisy, you are best to put in proper RS485 like buffers.
  • AleAle Posts: 2,363
    I have a dumb question, what features from smart pins are available in the current FPGA images ? I'd assume anything ADC/DAC related is out, isn't it ?
  • evanhevanh Posts: 15,091
    edited 2017-05-19 10:00
    Ale wrote: »
    I have a dumb question, what features from smart pins are available in the current FPGA images ? I'd assume anything ADC/DAC related is out, isn't it ?

    Everything except the P's are done. I think the documented part below is correct for the FPGA. There is four external flash DACs routed to these config bits on the Prop123 boards and maybe some on the other boards too. The meaning of the P's will change for the final silicon.
    D/# = %AAAA_BBBB_FFF_PPPPPPPPPPPPP_TT_MMMMM_0
    
    %P..P:     low-level pin control (needs final silicon to fully operate)
               %0000CIOHHHLLL = digital mode (default = %0000000000000)
                          %C: 1 = clocked I/O (extra clock for IN and OUT)
                          %I: 1 = invert IN output
                          %O: 1 = invert OUT input
                          %HHH: 000 = drive high, other = float when driven high
                          %LLL: 000 = drive low, other = float when driven low
               %101xxDDDDDDDD = DAC mode, %DDDDDDDD: DAC output level
    
  • evanhevanh Posts: 15,091
    ADC's won't be present on the FPGA.
  • Cluso99Cluso99 Posts: 18,066
    Chip,
    Is there any variant of P2 that would give 1MB of HUB?
    eg 8 Cogs and 32 Smart Pins ???

    If 32 Smart Pins, every second pin could likely be a good option since the Smart pins can reach +/-3pins.
  • evanhevanh Posts: 15,091
    Using MRAM would fit in 2 MB of HubRAM easy.
  • cgraceycgracey Posts: 14,131
    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.
  • jmgjmg Posts: 15,140
    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.

    How granular and layout-time-flexible, is the RAM sizing ?
    It seems LSB of 4 is one constraint, a larger constraint is likely memory matrix size ?
    eg if the cells are 128x256x16 bytes, ~ 15% of spare equivalent memory area could result in ~600,000 bytes, ~17% spare would allow a '600k' tag.

  • cgraceycgracey Posts: 14,131
    edited 2017-05-22 01:48
    jmg,

    If I recall, the current 512KB of RAM takes over half of the space within the pad frame.
  • jmgjmg Posts: 15,140
    edited 2017-05-22 01:55
    cgracey wrote: »
    jmg,

    If I recall, the current 512KB of RAM takes over half of the space within the pad frame.
    Yes, but the memory-footprint is a large XY matrix, so it is possible to change the size in other than 1:2:4 steps.
    You should be able to 'fill with memory' as part of the design flow ? (my % examples were for spare-room increments, not the memory die-space usage estimates)


  • cgraceycgracey Posts: 14,131
    edited 2017-05-22 02:10
    Jmg, I suppose that is possible. I've never asked OnSemi about any weird memory sizes, though.
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    Jmg, I suppose that is possible. I've never asked OnSemi about any weird memory sizes, though.
    I guess it depends on how well their memory compilers are written :)
    I could understand needing to keep a rectangular array, and whole X or Y additions, but it should be practical (in theory) to allow intermediate RAM sizes
  • evanhevanh Posts: 15,091
    edited 2017-05-22 03:13
    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.
Sign In or Register to comment.