Smart Pins Docs and features

1234568

Comments

  • jmgjmg Posts: 10,346
    cgracey wrote: »
    You can always reset a smart pin by dropping its DIR low for a clock or two.
    Does doing that, remove any 'previous value' carry-overs or bias ? If so, that may be enough to document and include in examples of FSK type use.

  • Yes. The mode stays set but all operating state of that mode is reset. Any counting starts afresh upon DIR high release.
  • evanhevanh Posts: 4,048
    edited August 26 Vote Up0Vote Down
    jmg wrote: »
    So that means the trailing bias is still there ? - this seems to be an effect whereby the previous settings, carry-forward into the next pulse frame.
    Or you can also think of this as a lead-in delay effect, where the first edge is not quite where expected, as the something 'old' needs to be flushed first..

    Similar to if you imagine a BAUD Speed register in a UART, that updated after the Start BIT end.
    Yes, like that. With no buffering of the Y register it can't be set until after DIRH, then the first period is always a low-out period.

    ozpropdev wrote: »
    Sure, a "dummy" reset of the smartpin would work.
    Did that comment mean a dummy reset can remove that lead-in/carry-forward effect in %00100 smart pin mode ?
    The dummy reset reduces the lead-in null period to whatever the setup time is by having two values for X period, fired off in quick succession. First period is tuned to match the setup time, with the second period being the objective timebase.

    It's a method to streamline the setting of Y pulses without buffering.

    EDIT: X period is already effectively buffered I think. Any change to it doesn't take effect until the active period has completed.
  • cgracey wrote: »
    The trailing bias is still there. The 16-bit timebase you set becomes the granularity of all activity. This has a hidden value, though, in that you can start up a whole bunch of pins at once, then write their pulse counts before the current timebase period, and they will all start in sync. And later, when you update each one, the whole group will remain locked to the same timebase.

    You can always reset a smart pin by dropping its DIR low for a clock or two.

    Yeah, sorry, calling it buggy wasn't very fair. I know neither mode was particularly intended for stepper pulses. Steppers always want to be adjusting the individual pulse periods to match the desired velocity of the motion profile so both X and Y have to be loaded at each segment transition.
  • evanhevanh Posts: 4,048
    edited August 26 Vote Up0Vote Down
    Hmm, I guess that's the crux of the concern: X is buffered but Y isn't.
  • jmgjmg Posts: 10,346
    evanh wrote: »
    ... I know neither mode was particularly intended for stepper pulses. Steppers always want to be adjusting the individual pulse periods to match the desired velocity of the motion profile so both X and Y have to be loaded at each segment transition.
    By using the dummy reset approach, can this now work for velocity profiling ? (no unexpected pulse rates?)

  • evanhevanh Posts: 4,048
    edited August 26 Vote Up0Vote Down
    Kind of, it means the setup time has to roughly fit the minimum transition time from one pulse to the next. This puts cap on max pulse frequency.

    Although, I am now wondering how much of glitch it really is, to have say a whole pulse time missing, when the segment length is going to be quite long at those frequencies.

    The glitches could accumulate to be a measurable synchronous motion error if not accounted for.

  • jmgjmg Posts: 10,346
    evanh wrote: »
    Kind of, it means the setup time has to roughly fit the minimum transition time from one pulse to the next. This puts cap on max pulse frequency.

    Although, I am now wondering how much of glitch it really is, to have say a whole pulse time missing, when the segment length is going to be quite long at those frequencies.

    The glitches could accumulate to be a measurable synchronous motion error if not accounted for.
    I can also think of FSK type apps, where you want to output one of two (or more) edge-spacings, with no 'unexpected intermediate' values, but maybe another mode is better for that ?

  • evanhevanh Posts: 4,048
    edited August 26 Vote Up0Vote Down
    I've never tried to build a stepper based system. In reality there is probably going to be lots of time gaps anyway.

    The above glitches would add periods to the timing, extending the finish time, but won't affect the number of pulses produced. So any such minor timing errors will vanish whenever these motion gaps occur.

    Still, I think buffering Y is a good idea anyway.
  • jmg wrote: »
    .. but maybe another mode is better for that ?
    They're the only modes that can define the number of transitions to output.
  • That mode %00100 was intended just to send out X clocks to a SPI chip or synchronous serial transceiver. The streamer is much better for seamless patterns.
  • evanhevanh Posts: 4,048
    edited August 26 Vote Up0Vote Down
    Oops, sorry, I've crossed X and Y over in my above postings. X is period and Y is count. So Y is the one not buffered. Maybe I should edit all those ... done.

    It would be nice to at least have Transition Output mode, %00101, have both registers buffered.

  • evanh wrote: »
    Oops, sorry, I've crossed X and Y over in my above postings. X is period and Y is count. So Y is the one not buffered. Maybe I should edit all those ... done.

    It would be nice to at least have Transition Output mode, %00101, have both registers buffered.

    You mean so that, additionally, Y is buffered? I need to see if we have the flops available for that.
  • evanhevanh Posts: 4,048
    edited August 26 Vote Up0Vote Down
    I don't think the Streamers can seamlessly transition its timebase any better. The seamless method of producing variable pulse rate would involve building the frequency dependant square wave it in a large buffer ... on-the-fly, for each motor.

    Actually, I just realised, this way, a single Streamer can feed many steppers. Maybe not so bad. EDIT: The memory layout could be a nightmare for a Cog to process, though.
  • cgracey wrote: »
    You mean so that, additionally, Y is buffered? I need to see if we have the flops available for that.
    Yes, much appreciated.
  • evanhevanh Posts: 4,048
    edited August 26 Vote Up0Vote Down
    Chip,
    Reducing the used size of Y to 16 bits would be fine for most uses I suspect. That would be a decent saving in flops. Running a stepper even up to, say, 5 MHz pulse rate (10 MHz transition rate), that still allows down to a lowly 200 Hz segment update rate. 1000 Hz segment update rate opens the top end right out to 25 MHz pulse rate. I'd call that flexible.

    EDIT: Second thoughts, maybe its not as flexible as first imagined. Without dithering, the granularity of the velocity becomes an issue when closing in on the timebase. So, the fastest pulse rates of each timebase is off limits.

    What is good guidance I'm not sure. Maybe divide by 10. So, with the 16-bit pulse stream, don't go faster than 2.5 MHz pulses when on 1000 Hz segments.

    The 32-bit version is limited by the system clock. At sys.clock of 200 MHz, that would make the pulse rate limit around 10 MHz. That doesn't seem a huge bonus given the same could be achieved on 16 bits with a 4 kHz segment rate.
  • Hmm, dithering is desirable. NCO's can sort that can't they? This is getting complex ...
  • Right, I declare everyone should use DAC/PWM output for motion control. Steppers are annoying!
  • jmgjmg Posts: 10,346
    evanh wrote: »
    Chip,
    Reducing the used size of Y to 16 bits would be fine for most uses I suspect. That would be a decent saving in flops.
    I'm not sure that's true, as Y is needed in many modes....
    I would be VERY wary about shrinking a size to 16b, as one of my peeves is 32b MCUs, crippled with 16b Timers/Counters.....
  • I am only referring to it's use in that one mode. How each mode uses X, Y and Z is quite independent. Chip was concerned about the cost, in flops, of adding a whole register buffer for mode %00101.
  • I guess that reasoning wasn't as clearly stated as needed.
  • cgraceycgracey Posts: 7,837
    edited August 26 Vote Up0Vote Down
    evanh wrote: »
    cgracey wrote: »
    You mean so that, additionally, Y is buffered? I need to see if we have the flops available for that.
    Yes, much appreciated.

    We have 16 flops free in mode %00100, but to use them as a buffer for Y, we would have 32+16 bits for Y, in total. We could either make the Y buffered at 16 bits or 24 bits, or (32+16)/2. The latter would introduce some unique mux paths into the smart pin which would grow it, somewhat. Not sure if it is worth doing. There are often a few ways to do similar things between the smart pin modes and the streamer. I kind of like the idea of keeping Y at 32 bits for mode %00100.
  • jmgjmg Posts: 10,346
    evanh wrote: »
    I am only referring to it's use in that one mode. How each mode uses X, Y and Z is quite independent. Chip was concerned about the cost, in flops, of adding a whole register buffer for mode %00101.
    Yes, but buffering is generally useful in most modes, and it is usually best to KISS.
    PWM modes for example, benefit from an update-on-flyback, which needs a buffer.
    I also like the general idea of being able to 'arm' a group of smart pins, and then 'go' atomically.
    I think that is mostly there, and that also needs buffering, if that 'go' is more an 'update'.


  • The smart pin modes work by mux'ing some particular mode's circuitry to the X/Y/Z flops, including D, Q, and ENA signals. The logic compiler is able to reduce overall logic by recognizing common sub-circuits that exist across multiple modes' circuits. For example, every mode-specific circuit that writes the bus data to the X register (say, via WXPIN) winds up using the same set of gates. This way, the number of (large, power-hungry) flops are fixed (and limited!), and finer-granularity logic provides the personality.
  • evanhevanh Posts: 4,048
    edited August 27 Vote Up0Vote Down
    cgracey wrote: »
    We have 16 flops free in mode %00100, but to use them as a buffer for Y, we would have 32+16 bits for Y, in total. We could either make the Y buffered at 16 bits or 24 bits, or (32+16)/2. The latter would introduce some unique mux paths into the smart pin which would grow it, somewhat. Not sure if it is worth doing. There are often a few ways to do similar things between the smart pin modes and the streamer. I kind of like the idea of keeping Y at 32 bits for mode %00100.
    It's Transition Output mode, %00101, that I'm asking for this, btw. It's the simpler of the two modes. Maybe mode %00101 can fit the full 32 bits.

    If a typo on your mode number then I'm obviously happy to go with just 16 bits for this mode. I'd prefer this over no buffering of Y. No need for messing around with 24 bits, imho.
  • evanhevanh Posts: 4,048
    edited September 23 Vote Up0Vote Down
    I think this might have gone off the radar with the trip to China.

    Chip,
    I'd like you to double check mode %00101, Transition Output, to see if it can fit a full 32 bit buffer register for Y.

    Leave mode %00100 as is.

  • evanh wrote: »
    I think this might have gone off the radar with the trip to China.

    Chip,
    I'd like you to double check mode %00101, Transition Output, to see if it can fit a full 32 bit buffer register for Y.

    Leave mode %00100 as is.

    I did look into this when I got back from China. I can't remember the specifics, but I realized it couldn't be expanded without breaking the mold for smart pin resources. So, I decided to just leave it the way it is.

    I've been working the last few weeks on getting everything ready for OnSemi to start the synthesis work. The test chip is off on the shuttle now and should be back in 12 weeks. Hopefully, we'll have this synthesis and integration all done around then, too.
  • Thanks for the update. It probably still involved shrinking the register size, which I know wasn't desirable.

    It's likely not a big issue anyway, tiny timing gaps probably won't even be noticed in real stepper applications.
  • Dave HeinDave Hein Posts: 5,279
    edited September 24 Vote Up0Vote Down
    cgracey wrote: »
    I've been working the last few weeks on getting everything ready for OnSemi to start the synthesis work. The test chip is off on the shuttle now and should be back in 12 weeks. Hopefully, we'll have this synthesis and integration all done around then, too.
    That's good news to hear that the P2 is nearing synthesis. I believe there were some changes to some instructions recently. Maybe it would be good to get an update to the FPGA images so they match the design that is going to OnSemi.

    So it looks like the test chip should be back the middle of December. It's exciting to realize that the P2 could be in silicon sometime next year.

  • Yes, a few minor changes have been made and some bugs were fixed. I will get a new release out.
Sign In or Register to comment.