Starting work on smart pins

cgraceycgracey Posts: 13,125
edited 2015-12-01 - 01:34:39 in Propeller 2
I've started working on the smart pins.

The MSGOUT needed a little fixing, and it seems to be working now.

What is needed, next, is the message receiver that goes into the pin circuit.

I realized that pin message I/O could be done in the background and also be event/interrupt sources, so that you could automate smart-pin updating with interrupts, never stalling the cog.

I figure the first thing I'll make is a PWM. There are lots of simple output modes to tackle.

Later, I'll get the pin to output messages, so that we can implement ADC counters, rotary encoders, and what not.

In the next FPGA release, there will be some rudimentary smart pin circuits. Thanks to Ariba, we have some MAC-like instructions now to facilitate DSP, without needing dedicated accumulators.
«13

Comments

  • YES!

    I assume we can continue with minor bug fixes to the core, should they be found.

    Personally, I'm pleased that the DSP level of functionality made a return. Was looking forward to learning more about that on the P2.

  • potatohead wrote: »
    YES!

    Agreed! It may seems like the smart pins are just one last feature to add, but I suspect it will be one of the most important capabilities of the P2! I am very much looking forward to it.
  • jmgjmg Posts: 14,540
    cgracey wrote: »
    I figure the first thing I'll make is a PWM. There are lots of simple output modes to tackle.
    Sounds good.
    Can the PWM Clock be higher than the Core clock ?
    A number of parts offer this, and this allows highest resolution PWM, with still modest power envelopes.
    Then there is dual-edge (up/down counters) and deadband and trigger/reset actions.

    Some parts push the PWM edge resolution beyond the clock, 1ns or 150ps but that may be outside P2 scope ?


  • jmg wrote: »
    cgracey wrote: »
    I figure the first thing I'll make is a PWM. There are lots of simple output modes to tackle.
    Sounds good.
    Can the PWM Clock be higher than the Core clock ?
    A number of parts offer this, and this allows highest resolution PWM, with still modest power envelopes.
    Then there is dual-edge (up/down counters) and deadband and trigger/reset actions.

    Some parts push the PWM edge resolution beyond the clock, 1ns or 150ps but that may be outside P2 scope ?


    I think it would take a PLL with multiple taps to get better than the clock.

    Jmg, how do these up/down trigger things work?
  • jmgjmg Posts: 14,540
    edited 2015-12-01 - 03:27:06
    cgracey wrote: »
    I think it would take a PLL with multiple taps to get better than the clock.
    Some parts do have a separate PLL for PWM, but I was thinking more of one PLL, with either taps, or a separate divider for the Core SysCLK from the PWM clock.
    cgracey wrote: »
    Jmg, how do these up/down trigger things work?

    Classic first generation PWM is a sawtooth counter, but that makes all trailing edges the same.
    Common these days is adding modes for Up/Down counter (aka triangle counter ) that still has the Compare, but now both edges modulate, and you can define deadbands with simple differences in compare levels.
    When driving high power FETS, some define the additional deadband in SW, and you can also buy MOSFET gate drivers that sense D-S voltage and delay gate hand-over to avoid crowbar conduction effects.

    Trigger options are for current sense & trip use in SMPS / Motor drive, where an external signal truncates the current PWM until the next cycle.
  • I suspect it will be one of the most important capabilities of the P2! I am very much looking forward to it.

    Me too. And a lot of this will cover interesting, and new ground for me. Fun times ahead!

  • AribaAriba Posts: 2,387
    edited 2015-12-01 - 04:38:38
    Here is a visualitation of jmg's proposal:
    symmetricPWM.png
    If you drive a FET full-bridge then this is the simplest way to get symmetrical PWM with adjustable deadtime.
    It needs 2 output pins per counter, I think many of the Smartpin modes will use 2 paired pins. Encoder inputs for example (for that an up-down counter is also useful).

    Andy
    469 x 321 - 9K
  • Ariba wrote: »
    Here is a visualitation of jmg's proposal:
    symmetricPWM.png
    If you drive a FET full-bridge then this is the simplest way to get symmetrical PWM with adjustable deadtime.
    It needs 2 output pins per counter, I think many of the Smartpin modes will use 2 paired pins. Encoder inputs for example (for that an up-down counter is also useful).

    Andy

    Easy peasy. Just run an NCO with two comparators - one for out1 and one for out2. I think the smartpin may be a two-pin affair.
  • Jmg/Andy, using an up-down counter reduces the PWM resolution by a factor of 2. I prefer having two compare registers per pin, one for the rise and one for the fall, which allows for individual dead times for the two switches without reducing the resolution, as long as the pins are using a shared counter. This shared counter / separate rise & fall registers for each pin method also allows phased PWM.

    For phased PWM, the disadvantage (compared to a phase register for each phase, dead band registers, and a shared duty cycle register) is that you have to compute and write the fall register for each phase for every duty cycle change (whilst taking into account the dead band for the calculation), but it's more flexible than a single duty cycle register for multiple phases.

    One of the reasons I use the propeller is its PWM capability. It takes more cogs than I'd like (one per phase), but it's capable of phased PWM, dead time, and software stepping to increase the effective resolution without reducing the PWM rate, and all of these simultaneously.

    16 cogs and 200 MHz goes a long way towards giving me the PWM chip of my dreams, but putting it in hardware with two compare registers per PWM pin with fault interrupts (already implemented !) would be even better.
  • cgracey wrote: »

    Easy peasy. Just run an NCO with two comparators - one for out1 and one for out2. I think the smartpin may be a two-pin affair.

    Right time to ask about maybe including a dumb, asynchronous two pin invert? as in using 2 pins as an inverter, one input one output? This, with expected counter modes would make very high resolution inductive/capacitive/T.O.F. sensors trivial.
  • rabaggett wrote: »
    cgracey wrote: »

    Easy peasy. Just run an NCO with two comparators - one for out1 and one for out2. I think the smartpin may be a two-pin affair.

    Right time to ask about maybe including a dumb, asynchronous two pin invert? as in using 2 pins as an inverter, one input one output? This, with expected counter modes would make very high resolution inductive/capacitive/T.O.F. sensors trivial.

    We've got all that in the analog pin, already. I will post a table within an hour.
  • RaymanRayman Posts: 11,494
    edited 2015-12-01 - 17:46:36
    Is there a way to do analog input/output with P123 or DE2 boards? Or, is it digital only?

    Ok so I know there's analog output via those dac chips. Guess just asking about analog input possibility
  • PinModes.png

    PinA = this pin
    PinB = neighbor pin (pin pairs are even/odd)

    The "Input" column shows what is returned via INA/INB.

    Mode %0000_000000000 (default) is a normal digital I/O pin.

    Mode %0010_001011011 would be a dual-pin, unclocked, inverter with 100k-ohm feedback.

    Mode %0100_001110110 would be a single-pin, unclocked, Schmitt-trigger relaxation oscillator with +/-10uA current feedback.


    1679 x 860 - 67K
  • TubularTubular Posts: 4,155
    edited 2015-12-01 - 18:11:13
    Rayman wrote: »
    Is there a way to do analog input/output with P123 or DE2 boards? Or, is it digital only?

    Ok so I know there's analog output via those dac chips. Guess just asking about analog input possibility

    There's a 4 pin analog header on the P123-A9, just above the breadboard.
  • jmgjmg Posts: 14,540
    altosack wrote: »
    Jmg/Andy, using an up-down counter reduces the PWM resolution by a factor of 2.
    That does not have to be the case,
    eg You can use one LSB for odd/even and another LSB for rise/fall to get to half-clock PWM granularity, (assumes 50% clock)
    altosack wrote: »
    I prefer having two compare registers per pin, one for the rise and one for the fall, which allows for individual dead times for the two switches without reducing the resolution, as long as the pins are using a shared counter. This shared counter / separate rise & fall registers for each pin method also allows phased PWM.

    For phased PWM, the disadvantage (compared to a phase register for each phase, dead band registers, and a shared duty cycle register) is that you have to compute and write the fall register for each phase for every duty cycle change (whilst taking into account the dead band for the calculation), but it's more flexible than a single duty cycle register for multiple phases.
    That's quite an overhead cost, both in SW and with two compare blocks, so this is sounding like another possible operating mode.

    A common MCU timer option is a Pin-Toggle-on-Match, & what you describe could be achieved with two compare registers using that mode.

    PWM designs also usually have a delayed update design, where the set-points only refresh at a PWM cycle end. This avoids missing an edge effect, where a SW change moves a set-point to the other side of the present counter value.
  • jmgjmg Posts: 14,540
    Rayman wrote: »
    Is there a way to do analog input/output with P123 or DE2 boards? Or, is it digital only?

    Ok so I know there's analog output via those dac chips. Guess just asking about analog input possibility

    I think the Pin buffer on FPGAs has a small hysteresis, so you could likely do some simple threshold-based analog work, with that caveat.
    Linear ramps ie RC flyback timing should mostly work, and Delta-Sigma would have to operate across that hysteresis-band, and cross talk could be significant.
  • Thanks, I see the 4-pin analog header on my newly arrived A9 board.

    I think I remember Chip's chart from P2-hot days...
  • Those 4 pins are sigma-delta ADC inputs, so that we can exercise the Goertzel circuit in the streamer.
  • jmg wrote: »
    altosack wrote: »
    Jmg/Andy, using an up-down counter reduces the PWM resolution by a factor of 2.
    That does not have to be the case...
    Actually, it does: any trick you do with up/down (such as using both clock edges like dsPIC MC and xmegaAU) can also be done with single slope, which will always have twice the resolution as up/down.
    PWM designs also usually have...
    I don't think Parallax wants to compete with microcontrollers dedicated to motor control and SMPS, but to make something flexible that can cover most of the bases, today and tomorrow, even if it takes somewhat more software than those other chips. Flexibility is why I suggest two (16-bit ?) compare registers per pin and common time bases.

    In the end, I'll be happy with being able to duplicate P1 capabilities, with x2 speed and x2 cogs, even if I have to dedicate cogs to phases like I do now.
  • jmgjmg Posts: 14,540
    altosack wrote: »
    I don't think Parallax wants to compete with microcontrollers dedicated to motor control and SMPS, ...
    Are you sure ? -+ those are two very large application areas you have dismissed so easily there.
    I would expect Parallax certainly do want to make a part that can be easily used for motor control and SMPS.


  • jmg wrote: »
    altosack wrote: »
    I don't think Parallax wants to compete with microcontrollers dedicated to motor control and SMPS, ...
    Are you sure ? -+ those are two very large application areas you have dismissed so easily there.
    I would expect Parallax certainly do want to make a part that can be easily used for motor control and SMPS.


    Totally agree!

    The motion control market is huge and growing. I have used a couple of dedicated, $30+ motion IC's for my benchmark and have exceeded their capabilities already on the P1 using only two cogs.
  • Mickster wrote: »
    jmg wrote: »
    altosack wrote: »
    I don't think Parallax wants to compete with microcontrollers dedicated to motor control and SMPS, ...
    Are you sure ? -+ those are two very large application areas you have dismissed so easily there.
    I would expect Parallax certainly do want to make a part that can be easily used for motor control and SMPS.


    Totally agree!

    The motion control market is huge and growing. I have used a couple of dedicated, $30+ motion IC's for my benchmark and have exceeded their capabilities already on the P1 using only two cogs.

    With smart pins, that could be bettered with only one cog.
  • Totally mindblowing possibilities - and this is from a guy that doesn't understand much of what is discussed on the P2 forum :lol:
  • cgraceycgracey Posts: 13,125
    edited 2015-12-02 - 20:49:29
    I've been working out the serial messaging to/from pins for the last few days and I'm now thinking that we can just use hub instructions to transfer data in parallel, instead. The infrastructure is already in place and this would save 2,000 flops, in exchange for some mux's. It would also be way faster to have deterministic hub timing (not the crazier hub RAM timing), over serial messaging.
  • Parallel between where and where?
  • jmgjmg Posts: 14,540
    cgracey wrote: »
    I've been working out the serial messaging to/from pins for the last few days and I'm now thinking that we can just use hub instructions to transfer data in parallel, instead. The infrastructure is already in place and this would save 2,000 flops, in exchange for some mux's. It would also be way faster to have deterministic hub timing (not the crazier hub RAM timing), over serial messaging.

    What about the routing overhead, and simultaneous access to Pins from COGs, as well as mapping of Pins to COGs ?
    Parallel is faster, but I thought there were quite high costs to doing parallel from any of 16 COGS to any of 32-64 Pin cells ?
    A time-slot mux (same as HUB) could reduce logic, but would that lose the ability of all COGS to lock onto one pin edge on the same SysCLK ?
    Perhaps a mix ? - a direct connect path for low latency connected-sense, and access is time-slot parallel - that's faster in bursts than serial and could be even 8 bits DDR connected, to transfer 32b in one opcode time.

  • cgracey wrote: »
    I've been working out the serial messaging to/from pins for the last few days and I'm now thinking that we can just use hub instructions to transfer data in parallel, instead. The infrastructure is already in place and this would save 2,000 flops, in exchange for some mux's. It would also be way faster to have deterministic hub timing (not the crazier hub RAM timing), over serial messaging.
    Do you mean using a hub style rd/wr instruction instead of the special smart pin (serial) instructions?
    ie they would be accessible each hub slot (1:16 clocks)
  • cgraceycgracey Posts: 13,125
    edited 2015-12-02 - 21:54:48
    I'm thinking that the hub already has huge parallel conduits to all the cogs. Just picture the CORDIC system. It takes commands from 16 cogs, in turn. That mechanism can be also used to drive 32-bit data to I/O pins.

    Serial would be less routing, but bigger logic blobs on the pins.

    I'm not sure yet. I could do a hybrid parallel/serial system, like 4-bit data paths that take 8 clocks to move a long.
  • altosackaltosack Posts: 131
    edited 2015-12-02 - 23:18:07
    jmg wrote: »
    altosack wrote: »
    I don't think Parallax wants to compete with microcontrollers dedicated to motor control and SMPS, ...
    Are you sure ? -+ those are two very large application areas you have dismissed so easily there.
    I would expect Parallax certainly do want to make a part that can be easily used for motor control and SMPS

    I think you've misunderstood me a bit. Of course Parallax wants to make motor conteol and SMPS easy with the P2, but I don't think they want to directly support all the hardware modes that microcontrollers dedicated to motor control and SMPS support.

    Instead, a very flexible counters / compare registers approach should let us support all those modes with software, like the P1 does now, but even better, without the need for each pair of pins to be babysat by a cog.

    One way to do this is with two compare registers per pin and shared period counter(s), as I mentioned previously.

    Another way is to have PHSx and FRQx registers for each pin. Two cogs could take care of reloading many PHSx registers at intervals (the period would have to have 16 clock granularity);. I cobbled together some PASM for this; it ends up being limited by the hub access window, with one read and two writes being necessary for the diode pin. The number of phases possible with two cogs depends on the PWM rate: 4 @ 800 kHz, 16 @ 200 kHz.
  • cgracey wrote: »
    I'm thinking that the hub already has huge parallel conduits to all the cogs. Just picture the CORDIC system. It takes commands from 16 cogs, in turn. That mechanism can be also used to drive 32-bit data to I/O pins.

    Serial would be less routing, but bigger logic blobs on the pins.

    I'm not sure yet. I could do a hybrid parallel/serial system, like 4-bit data paths that take 8 clocks to move a long.

    Yes, the cogs already have a nice pathway to the hub and cordic system. I suppose it would just be a 32-way link to a 32-way bus around the smart pins. A cog using the 1:16 hub could deliver/receive a 32-bit long to/from the smart pins every 16 clocks. That is 2x the clock speed !!!

    Might it be possible (and worth it) to window the smart pins into a small block in the hub ram ???
    Might even be possible to use the streamer/lut mechanism to stream to/from the smart pins ???
Sign In or Register to comment.