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
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.
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?
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.
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.
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.
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:
... 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.
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
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?
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.
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.
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.
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.
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?
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.
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.
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 ?
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?
Comments
Here's another test using pulse mode %00100.
I'm not seeing lag here either.
What am I missing?
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.
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.
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:
(edit: updated to use DIRL/DIRH instead of WRPIN.)
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.
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.
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.
Remember that the transition count means edges, which differs to pulse mode.
And why doesn't WXPIN reset the counter immediately?
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.
Here's your mode %00101 where I've highlighted the segments in red. There is no yellow x's to place.
You don't actually want it to be reset when chaining segments, but a DIRL/DIRH pair would do it.
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.
It's no different to, say, a comport. Only after the setup is done does the hardware actually do the shifts.
However, uncontrolled gaps in the stream is not normal, and certainly is not desirable.
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.
Edit: by the way, does anyone know if this is the behavior that Chip actually intended?
Notice how when it does 'jump', it jumps by a whole prior period, result is quite large gaps.
Which specific mode are you referring to ?
One mode to me looks ok, and the other mode looks like it needs fixing.
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:
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 ?
Both screenshots show that. How is that not the same?