unexplained gosub delay

KidE

Hi All,

As a good soldier iḿ following the basics book and while doing some experimenting of my own i ran into some strange behaviour while working with gosub routines which i cannot overcome.

My 1st code runs pefectly but if i turn the pot the servo takes small steps to get to its new position.

' {$STAMP BS2}
' {$PBASIC 2.5}

rcLR              PIN     1
rcUD              PIN     2

serLR             PIN     14
serUD             PIN     15

scaleFactor       CON     143
offset            CON     400
delay             CON     10

timeLR          VAR     Word
accuLR          VAR     Word
timeUD          VAR     Word
accuUD          VAR     Word

'Main
PAUSE 1000

DO
  GOSUB getrc
  GOSUB calcPulse
  GOSUB dispPulse
LOOP


getrc:
  HIGH rcLR
  HIGH rcUD                           ' charge the cap
  PAUSE 1                             '   for 1 ms
  RCTIME rcLR, 1, timeLR                ' measure RC discharge time
RETURN

calcPulse:
  timeLR = timeLR */ scaleFactor
  timeLR = timeLR + offset
  accuLR = (accuLR + timeLR) /2
RETURN

dispPulse:
   PULSOUT serLR, accuLR

RETURN

If i remove all the gosub stuff it runs perfectly.

' {$STAMP BS2}
' {$PBASIC 2.5}

rcLR              PIN     1
rcUD              PIN     2

serLR             PIN     14
serUD             PIN     15

scaleFactor       CON     143
offset            CON     400
delay             CON     10

timeLR          VAR     Word
accuLR          VAR     Word
timeUD          VAR     Word
accuUD          VAR     Word

'Main
PAUSE 1000

DO
  HIGH rcLR
  HIGH rcUD                           ' charge the cap
  PAUSE 1                             '   for 1 ms
  RCTIME rcLR, 1, timeLR                ' measure RC discharge time

  timeLR = timeLR */ scaleFactor
  timeLR = timeLR + offset
  accuLR = (accuLR + timeLR) /2
   PULSOUT serLR, accuLR
   PAUSE 10
LOOP

Why its that? i looked in my books but i just cant find a explanation for this

erco

That is curious. Are you sure these are your exact program listings? Program #1 doesn't have the typical PAUSE statement after the servo PULSOUT, was that your intent? The 3 gosubs in #1 shouldn't slow things down as much as the PAUSE 10 in #2.

KidE

indeed because i was testing to find out where the behaviour was coming from. If you change the pause 10 in the second program to 100 it matches the behaviour of program one. ??? yes beat me cause i'm lost here.

erco

As an aside, if you use lower R and C values, then RCtime executes faster. You'll have to recalibrate for lower values returned, but then your first program could execute faster, possibly eliminating servo stutter. But I can't say why the second program works better than the first.

Maybe PhiPi or Tracy Allen can weigh in here on gosub execution speeds. Tracy has a website at http://www.emesystems.com/BS2speed.htm with lots of juicy timing info and more.

Zoot

The first program should behave as the second one, but a bit faster w/o the 10ms pause.

Can you "attach" both versions as actual .bs2 files? Something seems odd here. A BS2 gosub might take 750us, so say 2.25ms extra for the gosubs. Still that would be like having a PAUSE 2 or PAUSE 3 in the second program, not a PAUSE 10 or PAUSE 100.

erco

According to Tracy's web site, each gosub & return takes 787 microseconds, so the three of them in your first program should take about 2.4 milliseconds. That's chump change compared to the PAUSE 10 in your second program, which you say works better. The plot thickens.

Edit: Zoot beat me to it!

erco

Q: Are you using an analog or a digital servo? I found that digital servos can go much slower than analog in certain cases: http://forums.parallax.com/showthread.php?126078-Poor-Man-s-BS1-Slow-Scan-Camera&p=943617&viewfull=1#post943617

Try a different servo, at any rate.

Mike Green

The use of GOSUB / RETURN can't really explain a difference between the two programs. As described at the app-notes link here, the timing for GOSUB / RETURN is around 800us. In your first program, this is spread out over 3 such pairs with a distributed delay of around 2.5ms. In the 2nd program, there's a single delay of around 10ms after the PULSOUT. Servo motors require a delay between pulses of around 20ms. The execution time of an RCTIME statement is variable. Depending on this delay, you may have an inadequate delay or excessive delay and the servo can shutdown between pulses, thus "stutter" or it can get confused and miss some pulses and also "misbehave". Typically, the delay time is adjusted based on the RCTIME value, so it stays roughly around 20ms. The PAUSE time would be computed rather than a constant.

In the program with the GOSUBs, you need to do the same thing. You need to add a variable PAUSE based on the RCTIME value. It's just that the PAUSE time would be slightly different because of the difference in the overall execution time of the main loop.

erco

And just for fun, try this in your first program, which sends a second servo pulse:

DO
GOSUB getrc
GOSUB dispPulse
GOSUB calcPulse
GOSUB dispPulse
LOOP

BTW, did you leave any DEBUG statements in your first program? Does "dispPulse" mean "display Pulse" on a debug screen? That would clearly slow down a program and make your servo stutter, my good soldier.

KidE

Yes indeed General leaving the debug away did the trick in the GOSUB program.

I stripped and added a debug and this cleared the issue. With DEBUG ON you have a servo with huge jitter. with DEBUG OFF it runs very smooth as desired.

dispPulse:
   'DEBUG HOME, DEC5 timeLR, TAB, DEC5 accuLR
   PULSOUT serLR, accuLR
   PAUSE 20
RETURN

And up went the learning curve again ;-)

Thanks all for the good feedback (in which i find this forum really excels)

Mike Green

Important point ... When you provide code, make sure it's the actual code that exhibits the behavior you're describing.

KidE

Yeah I know and I'm very sorry for that. I'll pay more attention next time.