I understand your point, "what's wrong with 1us", but if it's wrong it's wrong and it should be corrected.
Especially on a processor capable of 50ns instruction resolution.
W9GFO,
Try the attached modified servo32v6 and see if that at least fixes the timing inconsistency from pin to pin.
The pulse width differences on the scope could be rounding error in servo32, but I'll tackle that next after
the pin timing is reported to be consistent.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Try the attached modified servo32v6 and see if that at least fixes the timing inconsistency from pin to pin.
The pulse width differences on the scope could be rounding error in servo32, but I'll tackle that next after
the pin timing is reported to be consistent.
I just ran it and found no difference in pulse lengths between the pins, Meaning, all pins are the same value (yay!). They all report 1500 uS - or 1497 uS if I don't add 3 to the phsa count.
BTW, I think it's pretty cool that something programmed in Spin can measure down to the millionth of a second, with relatively simple code.
Just got back from seeing Transformers II for the first time. I did not see any jitters in their servos.·
This is good news! But it still doesn't explain the 3us descrepancy when you issue 1500. I guess one step at a time. I'm sure it will be easier to find now that all zones seem to be playing together. I just wish I was a little further along with PASM.
W9GFO said...
I just ran it and found no difference in pulse lengths between the pins, Meaning, all pins are the same value (yay!). They all report 1500 uS - or 1497 uS if I don't add 3 to the phsa count.
To be more accurate, the discrepancy is actually 3.65us or 292 clocks from when the initial SyncPoint is referenced to the counter. The overhead within each ZoneCore requires the 292 clocks for processing the correct pulse widths from the SyncPoint. Since there are 80 clocks per 1us ... 292/80 = 3.65us
So what I did after determining the SyncPoint at the start of each ZoneCore, I added a line that reads...
add SyncPoint, #296 'Add overhead offset to counter Sync point
...Why 296 rather than 292? Since I 'added' another PASM line of code, I also added 4 more clocks to the overhead,
so 292 became 296.
The purpose of adding to SyncPoint is to project a future amount of time that we actually want to start timing the pulse.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔ Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 7/19/2009 6:06:59 AM GMT
Comments
I understand your point, "what's wrong with 1us", but if it's wrong it's wrong and it should be corrected.
Especially on a processor capable of 50ns instruction resolution.
W9GFO,
Try the attached modified servo32v6 and see if that at least fixes the timing inconsistency from pin to pin.
The pulse width differences on the scope could be rounding error in servo32, but I'll tackle that next after
the pin timing is reported to be consistent.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
I just ran it and found no difference in pulse lengths between the pins, Meaning, all pins are the same value (yay!). They all report 1500 uS - or 1497 uS if I don't add 3 to the phsa count.
BTW, I think it's pretty cool that something programmed in Spin can measure down to the millionth of a second, with relatively simple code.
Thanks for your work on this object Beau.
Rich H
Edited in an attempt to be more clear
Post Edited (W9GFO) : 7/19/2009 3:47:23 AM GMT
So, let me just double check what you are saying...
The timing inconsistency from pin to pin has been corrected in the latest servo32v6 object correct?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
This is good news! But it still doesn't explain the 3us descrepancy when you issue 1500. I guess one step at a time. I'm sure it will be easier to find now that all zones seem to be playing together. I just wish I was a little further along with PASM. Ditto. Thanks Beau!
Jim
Affirmative!
At least as well as I am able to measure.
Rich H
Ok, I think I figured out the 3us discrepancy.
To be more accurate, the discrepancy is actually 3.65us or 292 clocks from when the initial SyncPoint is referenced to the counter. The overhead within each ZoneCore requires the 292 clocks for processing the correct pulse widths from the SyncPoint. Since there are 80 clocks per 1us ... 292/80 = 3.65us
So what I did after determining the SyncPoint at the start of each ZoneCore, I added a line that reads...
...Why 296 rather than 292? Since I 'added' another PASM line of code, I also added 4 more clocks to the overhead,
so 292 became 296.
The purpose of adding to SyncPoint is to project a future amount of time that we actually want to start timing the pulse.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Post Edited (Beau Schwabe (Parallax)) : 7/19/2009 6:06:59 AM GMT
Thanks again!
Rich H
OBEX updated to version Servo32v6 ...
obex.parallax.com/objects/51/
... Good catch by the way on the error!!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Beau Schwabe
IC Layout Engineer
Parallax, Inc.
Thanks Beau,
It is working perfectly as far as I can tell.
Rich H