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

P2 Smart Pins

1567911

Comments

  • re:Hopefully, I will get new FPGA files out tomorrow.

    Great!! I'm looking forward to trying it out.

    re:smart pin documentation

    We will certainly appreciate that. :)
  • RaymanRayman Posts: 13,800
    edited 2016-02-06 21:45
    Guess the ROM is the last thing to do?

    Will smartpins help SDRAM?
  • That and a discussion on what might need closer testing, or another pass. We probably have gaps still.

    All assuming this round of smart pin functionality gets us to a good place.
  • cgraceycgracey Posts: 14,133
    Rayman wrote: »
    Guess the ROM is the last thing to do?

    Will smartpins help SDRAM?

    Yes, the ROM needs completion.

    Smart pins will be useful for generating the SDRAM clock, while the streamer will move the data, as the cog writes the address and control signals.
  • I've been thinking what hardware we might want to hook up and test. I think I2S should be relatively straightforward using the same strategy Chip just outlined.

    There's uSD cards, obviously

    This Linear tech ADC series might test things a bit as serial clock pushes up towards 90 MHz. Could be good for digitizing greyscale video
    http://www.linear.com/product/LTC2315-12

    The TSL3301 line scan array too, though its much slower.
  • cgracey wrote: »
    jmg wrote: »
    cgracey wrote: »
    I'm not there yet.

    A good test framework for Capture, is a Reciprocal Frequency Counter.
    This has 2 x 32 bit counters, that capture on the same edge.
    One counter is Time (SysCLK/N clocked), and the other is Cycles (Fin clocked)

    The Arm-capture is done at a relatively slow rate, 10ms to 1000ms, and when Armed, the next Fin edge triggers both Time & Cycles captures, once. (ie Capture is always whole cycles, rounds up in time to the next Fin edge)
    This trigger element can be as simple as a D-FF with CLK and RS signals, or anything that HW triggers and SW clears.

    I'm not sure is this will need 2 Pin cells, or 3, with the 3rd one providing D-FF emulation ? (hopefully 2)

    This will give 0.5Hz to 40MHz type dynamic range, with no range-select needed & many of these can manage from one COG.

    Where less dynamic range is tolerable, designs can capture Time after /M Fin Cycles, and /M is chosen to give a useful period read rate. eg 1MHz in may capture every 4096 edges, for a 4.096ms update rate.
    At 80MHz this update is ~3ppm LSB

    A variant of this captures Fin Cycles count, after a fixed time, but this has low precision at low frequencies, tho it does give Hz rather than Period result.

    Timer Interval A-B :
    Capture side is simple - Chosen Pin edge loads time.

    This does need to be Arm-capture as a pair, so you know you have a single-span time from A to B & it should work down to very narrow 1 SysCLK wide pulses.

    Some systems give the option to Clear-On-capture, others capture without clear, and the user subtracts previous value.

    Okay. I just reread this. I think I get it.

    We are measuring both the period and the number of periods over an interval. The first gives us low-frequency accuracy and the second gives us high-frequency accuracy.

    This can certainly be done with two smart pins looking at the same physical pin. Or, it can be done by one smart pin which first takes one type of reading and then the other.

    Yes. This is done also on PLC's counter cards. It is called "frequency measurement" (where a number of periods, of the input signal, are counted in a given time window) and "period measurement" (where a number of periods, of an internal reference frequency, are counted in a given window determined by the input signal period.
    Yes, frequency measurement gives better accuracy over high frequencies while period measurement gives better accuracy on low frequencies.

    But it will be nice if 3 smart pins can source from the same (couple of) pin(s) so that you can have the incremental counter(1) value from quadrature (incremental) encoder and its frequency(2)/period(3) measurements. 1 gives position while 2 and 3 gives speed.

    I hope that the quadrature mode can count for both cases:
    1) A=pulse B=direction (standard counting)
    2) by evaluating A and B rising and falling edges (4 times increased resolution)
  • jmgjmg Posts: 15,140
    Tubular wrote: »
    I've been thinking what hardware we might want to hook up and test. I think I2S should be relatively straightforward using the same strategy Chip just outlined.
    Yes, I think I2S should be able to use Smart Pin's ability to 'link-nearby', and generate a CLK/16/24/32 as needed, for the LRCLOCK
    (uses opposite edge to the data sample edge)
    The streamer should provide the data.



  • jmgjmg Posts: 15,140
    dMajo wrote: »
    Yes. This is done also on PLC's counter cards. It is called "frequency measurement" (where a number of periods, of the input signal, are counted in a given time window) and "period measurement" (where a number of periods, of an internal reference frequency, are counted in a given window determined by the input signal period.
    Yes, frequency measurement gives better accuracy over high frequencies while period measurement gives better accuracy on low frequencies.
    Reciprocal Counting measures (Whole Cycles > Gate Time)/(Time for those Cycles), and does the calculation.
    This means it has (essentially) the same precision no matter where in the range it is.
    A common spec is so many Digits per Second (of nominal gate time), set by SysCLK.
    The required Division (and SysCLK multiply) is why it is called Reciprocal Counting.

    dMajo wrote: »
    But it will be nice if 3 smart pins can source from the same (couple of) pin(s) so that you can have the incremental counter(1) value from quadrature (incremental) encoder and its frequency(2)/period(3) measurements. 1 gives position while 2 and 3 gives speed.
    Good point, there is a near-adjacent mapping Chip has mentioned, but the Pin cells may set the upper total limit here.
    Just 2 pins are needed per Quad, and one Cell can do Quad_Ctr, but Period and Cycles need a Pin Cell each, and maybe one more for the capture control.
    Hopefully, it can be done in 3 Pin Cells, not 4, as that avoids consuming pins.

    I'm not sure if a Side-linked Pin Cell means that Pin's IO is mapped to the Pin Cell not the pin, but I think so.
    ie I think the IN and OUT are used by the Pin Cell as flag/control, so are Pin Cell or pin, not both, which means a side linked Pin Cells, consumes that Pin ? (not avail as IO at that time ?)

    dMajo wrote: »
    I hope that the quadrature mode can count for both cases:
    1) A=pulse B=direction (standard counting)
    2) by evaluating A and B rising and falling edges (4 times increased resolution)
    2) has certainly been mentioned, 1) seems an easy subset ?
  • cgraceycgracey Posts: 14,133
    The quadrature mode can keep a running count, or report periodically over any 16-bit number of clocks, giving delta (speed), without losing any counts.
  • cgraceycgracey Posts: 14,133
    I got the final Prop123_A9 compile done for the current Prop2 with smart pins. Next, I need to do the DE2-115 and the two DE0-Nano versions. I still need to make some smart pin example programs for the .zip file and I want to come up with some better names for the smart pin instruction mnemonics. I hope to get this done tonight, before I go to bed.
  • Looks like I will have to dust down the DE2-115 again, I'd like to see how it goes with the W5500 and SD cards.
  • jmgjmg Posts: 15,140
    cgracey wrote: »
    .. and I want to come up with some better names for the smart pin instruction mnemonics.

    It could be nice to have all pin-operating mnemonics using a common root.
    The PIN you have now, seems to have good clarity ?

    PIN support on P2 is rather different from Generic ARM parts, so being able to show-case all the pin-opcodes makes that difference easier for new users to follow.

  • Maybe. Smartpin commands are a specific mode of pin operation. When one is ignoring them, the existing mnemonics are reasonable. Differentiating that isn't a bad thing.
  • jmgjmg Posts: 15,140
    edited 2016-02-07 05:04
    cgracey wrote: »
    The quadrature mode can keep a running count, or report periodically over any 16-bit number of clocks, giving delta (speed), without losing any counts.

    So if you wanted both Position control, and Speed, you could cross-configure two pin cells, both as Quadrature ? (uses 2 pins and 2 pin cells)
    One CTR is set to update on-demand, and the other updates on-timebase, where some 16 bit timescale is chosen to give Delta(speed).
    Read the first one for accurate Position, and the second one for Speed indication.

  • cgraceycgracey Posts: 14,133
    jmg wrote: »
    cgracey wrote: »
    The quadrature mode can keep a running count, or report periodically over any 16-bit number of clocks, giving delta (speed), without losing any counts.

    So if you wanted both Position control, and Speed, you could cross-configure two pin cells, both as Quadrature ? (uses 2 pins and 2 pin cells)
    One CTR is set to update on-demand, and the other updates on-timebase, where some 16 bit timescale is chosen to give Delta(speed).
    Read the first one for accurate Position, and the second one for Speed indication.

    Or, have one short-period quadrature mode cause interrupts that grab the delta and add it into an accumulator. Then you get both speed and position.
  • cgracey wrote: »
    I got the final Prop123_A9 compile done for the current Prop2 with smart pins. Next, I need to do the DE2-115 and the two DE0-Nano versions. I still need to make some smart pin example programs for the .zip file and I want to come up with some better names for the smart pin instruction mnemonics. I hope to get this done tonight, before I go to bed.
    Exciting times ahead! :) Refresh....refresh....refresh...

  • jmgjmg Posts: 15,140
    cgracey wrote: »
    Or, have one short-period quadrature mode cause interrupts that grab the delta and add it into an accumulator. Then you get both speed and position.

    Yes, but that's a more Classic-MCU approach, and I was wanting to check what the Pins themselves are capable of, leaving interrupts for something else.
    (or allowing 3,4,5 AXIS control in one COG )

    Is it possible to 'cross-configure' two pin cells, both as Quadrature ? (uses 2 pins and 2 pin cells, one fast update, one slower delta)
  • cgraceycgracey Posts: 14,133
    jmg wrote: »
    cgracey wrote: »
    Or, have one short-period quadrature mode cause interrupts that grab the delta and add it into an accumulator. Then you get both speed and position.

    Yes, but that's a more Classic-MCU approach, and I was wanting to check what the Pins themselves are capable of, leaving interrupts for something else.
    (or allowing 3,4,5 AXIS control in one COG )

    Is it possible to 'cross-configure' two pin cells, both as Quadrature ? (uses 2 pins and 2 pin cells, one fast update, one slower delta)

    Yes, you can do that.

    Think of this, though: If you set up three encoders and six triangle PWMs, all with the same period, and start them on the same clock, you can use any one of them to trigger a single interrupt in which all three encoders can be read for speed and accumulated for position, and all six PWMs can be updated with next samples. Actually, it would be better to compute the PID loops and just wait for any of those pins' IN to go high, and then read and update everything. All with one cog in a simple loop.
  • cgraceycgracey Posts: 14,133
    It's getting late and I only have the Prop123-A9 board compiled, so far. I had some "combination loops" in the pin mux's and I had to make some changes and recompile. I also had to update the assembler and spin files. I still need to do the DE2-115 and the two DE0-Nano's. Also, I need to make some example programs, yet, for the smart pins.

    At this point, it will be Monday when I get these files out. Sorry for all these delays, but I think you will find it worthwhile.
  • evanhevanh Posts: 15,126
    If software is part of the servo loop then the "classic" approach is all that's useful, although, in the case of the Prop, it probably wouldn't use interrupts per se. The only time anything more is useful is if the Prop hardware is expected to handle the servo function itself - which would be going overboard IMHO.
  • cgraceycgracey Posts: 14,133
    edited 2016-02-07 12:04
    I wonder if 64 smart pins are going to make 16 cogs look like total overkill.
  • cgracey wrote: »
    I wonder if 64 smart pins are going to make 16 cogs look like total overkill.

    Yeah, I've been wondering that myself as a cog is meant to be the smarts itself and we just needed some extra pin functionality. As I have mentioned before I don't think of these as smart pins at all, I think of them as peripherals, one for each pin!

  • rjo__rjo__ Posts: 2,114
    cgracey wrote: »
    I wonder if 64 smart pins are going to make 16 cogs look like total overkill.

    I like the idea that the P2 is now completely open to parallel processing... with plenty of room(cogs).

    On the other hand, if you can improve throughput by cutting out 8 cogs... then that would trump parallelism in my mind. Adding another fifo sure seems desireable:)

    It was looking like the available opcode space was getting down to nil. There are lots of general opcodes that could be added... and possibly some specialized ones:)




  • rjo__rjo__ Posts: 2,114
    currently... rdfast->do something->wrlut->stream lut back to hub takes 3x clocks compared to having 2 directional fifo's: rdfast->do something->wrfast

    Of course I could be completely wrong... this is how I understand it today:)
  • Heater.Heater. Posts: 21,230
    Nooo....

    8 cores is so last decade. Even a Raspberry Pi has 4 now a days.

    I want to be able to, for example, parallelize a big FFT over 8 COGS using OpenMP or whatever and still have 8 COGS left for other stuff and still have those high IQ pins.

    I want all my cakes and eat them :)

  • rjo__rjo__ Posts: 2,114
    ok:)
  • rjo__rjo__ Posts: 2,114
    might be a record around here... question solved in 3 posts!!!
  • rjo__rjo__ Posts: 2,114
    but we still need another fifo.
  • Heater.Heater. Posts: 21,230
    What we need is the chip. Before I shuffle of this mortal coil.
  • rjo__rjo__ Posts: 2,114

    Heater. wrote: »
    What we need is the chip. Before I shuffle of this mortal coil.

    I think what you meant to say is that reducing the cog count and adding another FIFO is a perfect FPGA exercise...and a good place to start the P3 design.

    I couldn't agree more:)
Sign In or Register to comment.