Shop OBEX P1 Docs P2 Docs Learn Events
Smart Pins Docs and features - Page 6 — Parallax Forums

Smart Pins Docs and features

13468917

Comments

  • evanhevanh Posts: 15,091
    Here's a quick example of nice clean and easy mode %00101: (four chained segments of 5 transitions each)
    		wxpin   #15, #tpin           '15 clocks per transition period (operate on whole periods)
    		wypin   #5, #tpin            '5 transitions (this starts a fresh countdown of Y)
    		waitse1                      'wait till final period has started (Y == 0)
    		wxpin   #30, #tpin           'set size of next transition period
    		wypin   #5, #tpin            'set number of transitions starting from next period
    		waitse1                      'rinse and repeat ...
    		wxpin   #60, #tpin
    		wypin   #5, #tpin
    		waitse1
    		wxpin   #15, #tpin
    		wypin   #5, #tpin
    
    1040 x 480 - 7K
  • @evanh
    Here's another test using pulse mode %00100.
    I'm not seeing lag here either.
    	setse1  #(%001_000000 | tpin)
    	wrpin	#_pulse,#tpin
    	wxpin   ##30 << 16 | 60, #tpin
    	dirh	#tpin
    
    	wypin   #2, #tpin
    	outh	#marker1
    	nop
    	outl	#marker1
    	waitse1
    		
    	wxpin   ##15 << 16 | 30, #tpin
    	wypin   #2, #tpin
    	outh	#marker1
    	nop
    	outl	#marker1
    	waitse1
    
    	wxpin   ##60 << 16 | 90, #tpin
    	wypin   #2, #tpin
    	outh	#marker1
    	nop
    	outl	#marker1
    	waitse1
    
    
    795 x 148 - 55K
  • evanhevanh Posts: 15,091
    In that above example, probably the first WXPIN #15 starts a 15 clock period, with Y ==0, before WYPIN #5 is issued. So the first transition will have several clocks of leading delay.
  • evanhevanh Posts: 15,091
    edited 2017-07-18 12:31
    ozpropdev wrote: »
    Here's another test using pulse mode %00100.
    I'm not seeing lag here either.
    There is a whole extra pulseless period between the segments that you are not specifying.

  • SeairthSeairth Posts: 2,474
    edited 2017-07-18 12:49
    If I understand correctly, in mode %00100 when the cycle starts, it should go high until X[15:0] is not greater than X[31:16]. In Oz's last screenshot, it appears to me that there's upwards of a 60 clock cycle delay between the first WYPIN and the first expected transition. Similarly, there's approximately 45 clocks between the next WYPIN and expected transition. And then only about 20 clock between the third WYPIN and expected transition.

    What am I missing? :confused:


    Edit: and can someone explain why every cycle seems to be starting precisely on a 30-clock boundary? Coincidence? Or is there something else about the smart pins that I don't understand?

    Edit2: Oh wait! This would all make sense if the smart pin's counter continued decrementing X[15:0] over and over again, even when Y reached zero. If that's true, then I think that needs to be changed. First, it means that the smart pins are wasting energy when "idle" (the counters are running for no good reason). Second, it means that changing the pins behavior is always affected by the pins prior behavior, which is not good.
  • evanhevanh Posts: 15,091
    Seairth wrote: »
    Edit: and can someone explain why every cycle seems to be starting precisely on a 30-clock boundary? Coincidence? Or is there something else about the smart pins that I don't understand?

    It's not matched to a CNT value, we just trigger the capturing at the first leading edge of the output. The image is aligned to that.

    There is any amount of unaccounted for ticks prior.
  • evanhevanh Posts: 15,091
    Seairth wrote: »
    First, it means that the smart pins are wasting energy when "idle" (the counters are running for no good reason).
    I wouldn't worry about the tiny power consumption but also remember this is only occurring when both the Smartpin mode is configured and enabled.
  • I just picked values that line up nicely to my grid. :)

    For both pulse and transition modes issuing a new WYPIN command will not start until one more base period has occurred after the ACK signal.

    This can be seen in both my screenshots that after the smartpin ack's on completion the new command doesn't wait for the new base period but one more "previous" base period.
  • evanhevanh Posts: 15,091
    DIRL #x disables the specified Smartpin operation while configured.
  • SeairthSeairth Posts: 2,474
    edited 2017-07-18 13:20
    ozpropdev wrote: »
    I just picked values that line up nicely to my grid. :)

    For both pulse and transition modes issuing a new WYPIN command will not start until one more base period has occurred after the ACK signal.

    This can be seen in both my screenshots that after the smartpin ack's on completion the new command doesn't wait for the new base period but one more "previous" base period.

    Okay, I think I understand what's going on. In the above examples, the only way to get rid of those gaps would be to use WRPIN to disable the smart pin while updating the X any Y parameters:
    	dirl    #tpin
    	wxpin   ##15 << 16 | 30, #tpin
    	wypin   #2, #tpin
    	dirh    #_pulse, #tpin
    

    (edit: updated to use DIRL/DIRH instead of WRPIN.)
  • evanhevanh Posts: 15,091
    edited 2017-07-18 13:23
    ozpropdev wrote: »
    ... in both my screenshots that after the smartpin ack's on completion the new command doesn't wait for the new base period but one more "previous" base period.
    In your earlier mode %00101, there is a phase lag from issuing to doing a segment but not the extra delay between segments like there is for mode %00100.

    The lag, in both modes, is the good part. It allows time for getting the setup done before it's needed. The inline delay in mode %00100 is the bad part because it can't be removed.
  • evanhevanh Posts: 15,091
    Here's my previous run with the marker added:
    		dirl    #tpin
    		dirh    #tpin                're-sync output to the program execution
    
    		wxpin   #15, #tpin           '15 clocks per transition period (operate on whole periods)
    		wypin   #5, #tpin            '5 transitions (this starts a fresh countdown of Y)
    		outh	#marker
    		outl	#marker
    		waitse1                      'wait till final period has started (Y == 0)
    
    		wxpin   #30, #tpin           'set size of next transition period
    		wypin   #5, #tpin            'set number of transitions starting from next period
    		outh	#marker
    		outl	#marker
    		waitse1                      'rinse and repeat ...
    
    		wxpin   #60, #tpin
    		wypin   #5, #tpin
    		outh	#marker
    		outl	#marker
    		waitse1
    
    		wxpin   #15, #tpin
    		wypin   #5, #tpin
    		outh	#marker
    		outl	#marker
    
    1490 x 480 - 11K
  • The way I see it, both modes are behaving the same.

    When both modes are started from smartpin reset they both wait one base period before things start happening. (as per Chip's docs)

    When both modes finish with a "ack" and a new command is issued the current base period must occur before the new base period and command are started.

    The delays between operations match the base periods used.

    I must be misunderstanding your observations. :)




  • evanhevanh Posts: 15,091
    Oz,
    Here's your mode %00100 where I've highlighted the segments in red and the undefined delay gaps with a yellow "x".

    Those yellow gaps are not present in mode %00101. Every transition and period is specified in the segment values when using mode %00101.
    795 x 300 - 50K
  • The gaps are there in mode %00101.
    Remember that the transition count means edges, which differs to pulse mode.
  • SeairthSeairth Posts: 2,474
    edited 2017-07-18 17:41
    How would one cause a transition or pulse to start on a specific clock cycle? It seems you would have to actually call WXPIN some integer multiple of the desired period prior to the start clock cycle. In other words, if you want to start transitioning on clock N, you would have to call WXPIN exactly (N - m*X[15:0]) clocks beforehand (where m is an integer greater than zero), then call WYPIN within X[15:0] clocks prior to N.

    And why doesn't WXPIN reset the counter immediately?
  • jmgjmg Posts: 15,140
    ozpropdev wrote: »
    The way I see it, both modes are behaving the same.
    ...
    I must be misunderstanding your observations. :)
    There is still an unwanted effect there.

    evanh wrote: »
    Oz,
    Here's your mode %00100 where I've highlighted the segments in red and the undefined delay gaps with a yellow "x".

    Those yellow gaps are not present in mode %00101. Every transition and period is specified in the segment values when using mode %00101.
    Markers make the effect clearer.
    The Fast to slow gear change take too long, but conversely, the slow to fast is actually too quick.
    It looks to me like one-more of the previous time is somehow hanging about in a register.

    From the other image with markers, it also seems to have a similar one-more effect.
    ie the marker applies, but you still get out one more dT related to the OLD value, not a new one.

    In mode mode %00101, you could argue that is useful as it means only valid frequencies output. - no middle values, or runt pulses.

    Put another way, mode %00100 behaves like it generated an extra invisible pulse, of the old frequency.

    I think the key is observe time marker-to-first edge.

    Even the very first marker, seem to have >dT lag?, whilst the 3rd marker-to-edge, is faster than the new edge rate.
    To me, a small fix-up is needed here.
  • evanhevanh Posts: 15,091
    ozpropdev wrote: »
    The gaps are there in mode %00101.
    Remember that the transition count means edges, which differs to pulse mode.
    Oz,
    Here's your mode %00101 where I've highlighted the segments in red. There is no yellow x's to place.
    798 x 164 - 48K
  • evanhevanh Posts: 15,091
    edited 2017-07-18 23:10
    Seairth wrote: »
    How would one cause a transition or pulse to start on a specific clock cycle? It seems you would have to actually call WXPIN some integer multiple of the desired period prior to the start clock cycle. In other words, if you want to start transitioning on clock N, you would have to call WXPIN exactly (N - m*X[15:0]) clocks beforehand (where m is an integer greater than zero), then call WYPIN within X[15:0] clocks prior to N.
    Correct. That's not a big deal though, synchronising the first segment of multiple Smartpins can be achieved with a single DIR register access.
    And why doesn't WXPIN reset the counter immediately?
    You don't actually want it to be reset when chaining segments, but a DIRL/DIRH pair would do it.
  • evanh wrote: »
    Oz,
    Here's your mode %00101 where I've highlighted the segments in red. There is no yellow x's to place.
    The segments end at the ACK signal though, so there is a gap.


  • jmgjmg Posts: 15,140
    ozpropdev wrote: »
    The segments end at the ACK signal though, so there is a gap.
    It depends what you call a gap.

    I'd say that mode %00101 has a carry forward, of one present time (half?) period, before the next time period applies.
    Edge to edge dT values are always either exactly old, or exactly new values.

    mode %00100 is a little more broken, there is something of a carry forward effect in time, but without output changes, so you can get gaps larger than old or new dT.


  • evanhevanh Posts: 15,091
    ozpropdev wrote: »
    evanh wrote: »
    Oz,
    Here's your mode %00101 where I've highlighted the segments in red. There is no yellow x's to place.
    The segments end at the ACK signal though, so there is a gap.
    That's only the setup for the segment to follow. It still has to be actioned by the hardware. That's an inherent lag of handing off to the hardware.

    It's no different to, say, a comport. Only after the setup is done does the hardware actually do the shifts.
  • evanhevanh Posts: 15,091
    Adding buffering makes that lag even more pronounced. It's normal and sometimes, with feedback situations, is a compromise.

    However, uncontrolled gaps in the stream is not normal, and certainly is not desirable.
  • Here's another test of the pulse mode.
    In this example i'm firing off 4 cogs running the same test with a different delay between the first and second segments.
    Note how the second segment aligns to the next nearest base period.


    795 x 352 - 130K
  • SeairthSeairth Posts: 2,474
    edited 2017-07-19 03:13
    I get what's happening. And I'm not saying it is wrong, just that it feels wrong (to me). But it could also be that my understanding is lacking, and that the current behavior is in fact the most desirable behavior.

    Edit: by the way, does anyone know if this is the behavior that Chip actually intended?
  • jmgjmg Posts: 15,140
    ozpropdev wrote: »
    Here's another test of the pulse mode.
    In this example i'm firing off 4 cogs running the same test with a different delay between the first and second segments.
    Note how the second segment aligns to the next nearest base period.
    Nice traces.
    Notice how when it does 'jump', it jumps by a whole prior period, result is quite large gaps.

  • jmgjmg Posts: 15,140
    Seairth wrote: »
    I get what's happening. And I'm not saying it is wrong, just that it feels wrong (to me). But it could also be that my understanding is lacking, and that the current behavior is in fact the most desirable behavior.

    Edit: by the way, does anyone know if this is the behavior that Chip actually intended?

    Which specific mode are you referring to ?
    One mode to me looks ok, and the other mode looks like it needs fixing.
  • Here's the same style test in transition mode.
    Note I made the first segment 3 transitions to highlight the gap.
    IMO both pulse and transition modes behave the same.

    Dazed and confused..... :zombie:
    799 x 359 - 128K
  • jmgjmg Posts: 15,140
    ozpropdev wrote: »
    Here's the same style test in transition mode.
    Note I made the first segment 3 transitions to highlight the gap.
    IMO both pulse and transition modes behave the same.
    They are similar, but not quite the same final outcome.
    Even %00101 looks slightly broken on that last waveform.
    It's ok for a rapid change, but the delayed load shows the old base count is still being used, before applying the new one on next rollover.
    This even tho the old one has long since elapsed.
    That's unwanted behaviour, as the previous well-elapsed mode should not carry-forward to delay a new mode.
    It simply makes the new value lead-in unpredictable.

    It's a similar problem in MCU reload timers:
    If you can only access the reload register, you always have to wait for the old value to time out, before the new one can apply.
    If you load both time & reload, at the same time, then you properly sync a new timeout, with no ghost of the old value.

    Maybe, as in a MCU, this needs a user choice of wait-for-rollover, or update-on-start ?
  • jmg wrote: »
    They are similar, but not quite the same final outcome.
    Even %00101 looks slightly broken on that last waveform.
    It's ok for a rapid change, but the delayed load shows the old base count is still being used, before applying the new one on next rollover.
    This even tho the old one has long since elapsed.
    That's unwanted behaviour, as the previous well-elapsed mode should not carry-forward to delay a new mode.
    It simply makes the new value lead-in unpredictable.
    A reload in both modes waits for the next base period rollover.
    Both screenshots show that. How is that not the same?


Sign In or Register to comment.