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

P2 Smart Pins

MJBMJB Posts: 1,235
edited 2015-09-29 00:15 in Propeller 2
In searching for SETNIB as discussed in the other thread I found an old post of mine about Smart Pins and their potential use for decoding Delta-Sigma bit streams and jmg's and evanh's and another one additions.

Here evanh's schema for it.
104154&d=1380541194

Maybe now we have Smart Pin time ;-)
«13456711

Comments

  • jmgjmg Posts: 15,175
    MJB wrote: »
    Smart Pins and their potential use for decoding Delta-Sigma bit streams ...
    Maybe now we have Smart Pin time ;-)
    Devices that create such bit-streams are usually two-lines, CLK and DAT.
    CLK can be generated or driven, depending on the model.
    The other class of 2-line counting is Quadrature Encoders, so there could be some overlap in config setup here.
    ie
    Qa,Qb for 4 quadrant,
    CLK,Dirn for Up/Down (1 quadrant)
    CLK, CE for 1st order Sigma and general gated-counting.

  • evanhevanh Posts: 16,042
    edited 2015-09-29 05:22
    All these things can be treated synchronously (Use the provided clock to stay phase aligned) or asynchronously (Ignore clock if it exists by oversampling > 2x).
  • MJBMJB Posts: 1,235
    edited 2015-09-29 09:32
    or just count in edge mode - gate time given by system counter + SW

    by using evanh's scheme where each counters output can be muxed to the next as input even higher order can be easily achieved.
    would only require one bit (or part of) in the counter config register

    - and of course some code ;-)
  • evanhevanh Posts: 16,042
    MJB wrote: »
    ... even higher order can be easily achieved.
    would only require one bit (or part of) in the counter config register

    - and of course some code ;-)

    Yes, totally (the software decimation is trivial), and each further chained counter adds, with a matching additional software cycle, the next order. However, the downside is I think the settling time also increases so multi-order capture like that pretty much can't be muxed between multiple bit-streams. The number of analogue inputs would be limited by counters.

    Someone was speculating that extra orders can be accomplished all in software post processing. I wasn't able to counter such a statement but there wasn't any examples of how it would be done either.

    The only reason I know this per bit-clock accelerating summing method works is because it is the standard method of extracting higher orders from ADC bit-streams. The maths is way over my head.
  • MJBMJB Posts: 1,235
    edited 2015-09-29 17:04
    two links - one even with verilog code
    triadsemi.com/2007/01/25/how-to-design-a-16-bit-sigma-delta-analog-to-digital-converter/

    https://maximintegrated.com/en/app-notes/index.mvp/id/1870

    appnote.tsa002.figure09.gif

    from this schema it looks the accumulators are clocked so it is not the whole chain who has to settle but only the stages - and that's what the couners do anyhow.

    The decimation clock DEC_CLK runs much slower and can be done in SW.

    So with chained counters like this a multi order SINC filter seems possible.
    And if you could use the standard pin functions and use the unused counter for this - would be great.
  • MJBMJB Posts: 1,235
    maybe now it is time to remind Chip ...

    Delta-Sigma bit stream decoder for smart-pins
  • cgraceycgracey Posts: 14,209
    MJB wrote: »
    maybe now it is time to remind Chip ...

    Delta-Sigma bit stream decoder for smart-pins

    But, we only have a first-order integrator. I think the only useful thing we can do is count highs over a period. We also have a counting mode that increments on this pin's high and decrements on the adjacent pin's high, for differential measurements.
  • MJBMJB Posts: 1,235
    cgracey wrote: »
    MJB wrote: »
    maybe now it is time to remind Chip ...

    Delta-Sigma bit stream decoder for smart-pins

    But, we only have a first-order integrator. I think the only useful thing we can do is count highs over a period. We also have a counting mode that increments on this pin's high and decrements on the adjacent pin's high, for differential measurements.

    evanh's schema in the first post shows - given the Prop1 counters - how counters could easily be chained to create higher order integrators
    by just putting a MUX in there.

    So when each smart pin has one counter
    then just feeding it's output to the next pins input
    would do it - right?
    maybe this is possible already.
    Ideally of course without loosing the default IO functions of all but the first input pin. By just using their counters.




  • jmgjmg Posts: 15,175
    MJB wrote: »
    ...
    ... by just putting a MUX in there.

    Easy enough to type, but that 'just a MUX' is a 32 bit MUX plus 32bit data path between each pin cell adder.

    Chip is trying to lower the logic cost now, not increase it.

  • MJBMJB Posts: 1,235
    edited 2016-01-03 23:44
    jmg wrote: »
    MJB wrote: »
    ...
    ... by just putting a MUX in there.

    Easy enough to type, but that 'just a MUX' is a 32 bit MUX plus 32bit data path between each pin cell adder.

    Chip is trying to lower the logic cost now, not increase it.
    if there is a good reason not putting it in then this is fine with me.

    Just wanted to make sure it is not overlooked and accidentally forgotten.

    you jmg have been part of the discussion long ago ;-)

  • cgraceycgracey Posts: 14,209
    edited 2016-01-04 00:54
    I think that to get generally-expected sigma-delta ADC performance, we'd need a special decimation filter, which is not trivial. Also, we need a second order analog integrator, which we don't have.
  • jmgjmg Posts: 15,175
    edited 2016-01-04 02:02
    cgracey wrote: »
    I think that to get generally-expected sigma-delta ADC performance, we'd need a special decimation filter, which is not trivial. Also, we need a second order analog integrator, which we don't have.
    - not only that, the analog side needs very good Analog noise floor, which is not going to be the case in P2.

    The main target for external SDM should be the common isolated ADCs ( ADI, TI etc) that have either
    CLK from host + Summation Data
    or
    CLK to host + Summation Data
    ie they are 2 pin interface devices.

    Simplest handling is what is done now, aka ClkEnable a counter. That can give useful results with dual-read rates,
    eg 10 MHz CLK in counter mode, gives any/all of these
    ~ 152 readings per second to 16b,
    ~38 rps to 18b,
    ~19 rps to 19b,
    ~9 rps to 20b
    Flipped to give 10.00 rps, that needs 10.48576MHz clock, at 20b ADC, and you have whole cycles of 50Hz or 60Hz for mains immunity.

    If you need more bits/unit time, how fast can a P2 COG do the filtering ?

    Addit : Checking newer parts like ADE7912/ADE7913 , they now seem to include the filters.
    These parts have an SPI inteface, and sample at 8ksps with 3 kHz signal bandwidth.
  • MJBMJB Posts: 1,235
    jmg wrote: »
    MJB wrote: »
    ...
    ... by just putting a MUX in there.

    Easy enough to type, but that 'just a MUX' is a 32 bit MUX plus 32bit data path between each pin cell adder.

    Chip is trying to lower the logic cost now, not increase it.
    with paired pins only one mux and datapath is needed per 2 pin cell
    saving half of it - if there is a 'pin cell'

    we'll see
  • evanhevanh Posts: 16,042
    edited 2016-01-04 20:11
    I originally posted that modified counter diagram for the purpose providing for external bit-stream generators that already have higher order modulators, namely the ones with electrical isolation like the AD7401.

    That said, I do remember also coming across a statement in those datasheets stating that best results are achieved when using a filter/decimator order that is one higher than that used for the modulator. So, supposedly, the Prop2's first order modulators can still benefit from this.
  • evanhevanh Posts: 16,042
    jmg wrote: »
    Checking newer parts like ADE7912/ADE7913 , they now seem to include the filters.
    These parts have an SPI inteface, and sample at 8ksps with 3 kHz signal bandwidth.

    That's not newer so much as bit-stream vs SPI. Bit-stream only won't have the filter/decimator while an SPI interface must have it.
  • evanhevanh Posts: 16,042
    edited 2016-01-04 20:38
    cgracey wrote: »
    I think that to get generally-expected sigma-delta ADC performance, we'd need a special decimation filter, which is not trivial.

    That's fine done in software. The software only samples the final stage counter, and only at the decimation rate. The calculation is only an extra subtract or two at the decimation rate. It's just more of what you're already doing for first-order decimation. A Cog could do millions per second.
  • evanhevanh Posts: 16,042
    Here's my earlier attempt to find a little knowledge on the subject - http://forums.parallax.com/discussion/comment/1234234/#Comment_1234234

    Ariba asks if the extra orders can not be also achieved in software after the decimation, thereby having no need of the extra hardware at all ... ?
  • jmgjmg Posts: 15,175
    evanh wrote: »
    That's not newer so much as bit-stream vs SPI. Bit-stream only won't have the filter/decimator while an SPI interface must have it.

    Well, yes, but the point is more recent isolated SDM parts have the filter inbuilt, for what seems like OK prices/channel.
    It seems to me those are useful if you need the 3KHz bandwidth for power harmonics etc, but for your more industrial uses, 10 sps is ok - plus that buys mains immunity, and if you need mains immunity, faster sps are not much use.

  • evanhevanh Posts: 16,042
    edited 2016-01-05 02:44
    Historically, I remember searching for only bitstream parts because I didn't want to deal with the myriad of config you inevitably end up with when using SPI.

    EDIT: One nice feature of the pure bitstreaming is it can be filtered to a DC level with a plain R-C filter, making for easy monitoring with a scope.
  • cgraceycgracey Posts: 14,209
    Can you guys think of any novel/useful two-wire measurements?

    We have the following:

    - A-high inc, B-high dec (relative duty)
    - A-rise inc, B-rise dec (relative frequency)
    - A-B encoder

    We have both current and previous states of two pins to work with.
  • TubularTubular Posts: 4,705
    edited 2016-01-18 23:38
    a xor b (phase detection)

  • Cluso99Cluso99 Posts: 18,069
    Chip,
    Not sure if there is anything that can be done in the SmartPin section to help USB & CRC.
    Here is a link to the thread where I discussed helper instructions
    forums.parallax.com/discussion/151821/usb-helper-instruction-p2-possible-additional-instructions
  • jmgjmg Posts: 15,175
    cgracey wrote: »
    Can you guys think of any novel/useful two-wire measurements?

    We have the following:

    - A-high inc, B-high dec (relative duty)
    - A-rise inc, B-rise dec (relative frequency)
    - A-B encoder

    We have both current and previous states of two pins to work with.

    Phase A-B and Time interval A-B, but I think those may already be in there ?

  • RaymanRayman Posts: 14,768
    edited 2016-01-19 00:57
    I guess for a delay generator, you'd want to set a say 16-bit value to some # of clocks
    so that when A went high, b would go high that many clocks later...

    If there was a C, maybe you'd want the option that C=A or B or C= A and B, etc.
    Maybe that's already there, I don't know...
  • Will the smart pin max pulse count rate be limited to ~(sysclk/2) like the P1?
    On P1 we can generate a nice range of frequencies at a pin but with a 80MHz clock we can
    only measure frequencies up to ~37MHz before we hit the wall.
    It would be nice if P2 could internally measure/verify frequencies it has generated.

  • cgraceycgracey Posts: 14,209
    Tubular wrote: »
    a xor b (phase detection)

    We've got this covered. The A pin can be a logical function of A and B: AND/OR/XOR, with inversion options for each input.
  • cgraceycgracey Posts: 14,209
    Cluso99 wrote: »
    Chip,
    Not sure if there is anything that can be done in the SmartPin section to help USB & CRC.
    Here is a link to the thread where I discussed helper instructions
    forums.parallax.com/discussion/151821/usb-helper-instruction-p2-possible-additional-instructions

    Ay, ay, ay.... USB. Thanks for remembering and researching this. We'd need to identify what functions are required. I know there's a complex response involving CRC that needs to be in hardware.
  • cgraceycgracey Posts: 14,209
    jmg wrote: »
    cgracey wrote: »
    Can you guys think of any novel/useful two-wire measurements?

    We have the following:

    - A-high inc, B-high dec (relative duty)
    - A-rise inc, B-rise dec (relative frequency)
    - A-B encoder

    We have both current and previous states of two pins to work with.

    Phase A-B and Time interval A-B, but I think those may already be in there ?

    We've got those.
  • cgraceycgracey Posts: 14,209
    Rayman wrote: »
    I guess for a delay generator, you'd want to set a say 16-bit value to some # of clocks
    so that when A went high, b would go high that many clocks later...

    If there was a C, maybe you'd want the option that C=A or B or C= A and B, etc.
    Maybe that's already there, I don't know...

    Anyone second this automatic delay function? I never thought about something like this.
  • cgraceycgracey Posts: 14,209
    ozpropdev wrote: »
    Will the smart pin max pulse count rate be limited to ~(sysclk/2) like the P1?
    On P1 we can generate a nice range of frequencies at a pin but with a 80MHz clock we can
    only measure frequencies up to ~37MHz before we hit the wall.
    It would be nice if P2 could internally measure/verify frequencies it has generated.

    Yes, we have Nyquist limitations.
Sign In or Register to comment.