Smart Pins Docs and features
jmg
Posts: 15,173
in Propeller 2
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
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
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 ?
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/512however, 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 ?
Comments
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 stateThat 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.
IMHO, it will be rare to employ all 64.
Tom
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.
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 ...
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.
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.
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.
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.
@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: 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.
Smartpin Z counter is 32 bit, the same as Cog natural integers. The maths is as simple as a single subtract.
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 ...
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.
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 levelIs 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.
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.
If I recall, the current 512KB of RAM takes over half of the space within the pad frame.
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)
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
From http://forums.parallax.com/discussion/comment/1371876/#Comment_1371876 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.