pulsout and servopos question for future reference

dougyy

New Member
I set up a quick and dirty breadboard to position some servos prior to starting a project. Simple setup, 28x1 project board, pot on adc for position and an lcd panel (using Hippy's LCD Interfacing program, thanks Hippy) to show the value of my servopos pulse. I kept getting a bad servo jerk (worse than a jitter) each time the lcd would refresh. The manual (servopos) says "The servo pulses are also temporarily disabled during timing sensitive serin, sprout, sertxd and debug commands", is pulsout one of those timing sensitive commands?
 

Goeytex

Senior Member
Per Manual 2 page 213 ...

"The servo pulses are also temporarily disabled during timing sensitive serin, serout, sertxd
and debug commands."

"Servo" is a timer hog. It needs exclusive use of the internal timer to operate glitch free ...Any other command that uses the timer will cause a conflict, either causing servo to stop/ glitch or the other command to have problems.
 
Last edited:

hippy

Ex-Staff (retired)
is pulsout one of those timing sensitive commands?
Yes but in LCD code the pulses ( for LCD E signal ) are usually very short so should have minimal impact.

It may be that the LCD nibble-sending code is affecting the pin the servo is on as most LCD code ( including my own code ) usually writes to the entire port for fastest speed. You may have to recode those output routines not to affect other signals on the same port.
 

dougyy

New Member
Yes but in LCD code the pulses ( for LCD E signal ) are usually very short so should have minimal impact.

It may be that the LCD nibble-sending code is affecting the pin the servo is on as most LCD code ( including my own code ) usually writes to the entire port for fastest speed. You may have to recode those output routines not to affect other signals on the same port.
So the code that would need tweaking....
Code:
   SendDataByte:
    	pins = xbyte & %11110000 | rsbit ; Put MSB out first
    	PULSOUT E,1                     ; Give a 10uS pulse on E
    	pins = xbyte * %00010000 | rsbit ; Put LSB out second
    	PULSOUT E,1                     ; Give a 10uS pulse on E
to write to the individual pins 7-4 rather than to the group, otherwise a servo pulse on pins 1-0 might be affected. If the servo were on a different port, for instance out c0, would the LCD code and the servopos code cohabit better? Still further afield if a project calls for multiple servos as well as an LCD might it be best to dedicate the B group of outpins on a 40xX to the LCD and confine all the rest of the project to A and C groups? All this is still more informational than specific, still it would be handy to know.
 

Bassnut

New Member
Per Manual 2 page 213 ...

"The servo pulses are also temporarily disabled during timing sensitive serin, serout, sertxd
and debug commands."

"Servo" is a timer hog. It needs exclusive use of the internal timer to operate glitch free ...Any other command that uses the timer will cause a conflict, either causing servo to stop/ glitch or the other command to have problems.
When you say "the timer", do you mean just one, or any?.
Ive been plauged by servo glitching for weeks on a new type 5v 28*2. Ive tried everything . The least gitching occured when I coded a servo command every single time I used servopos, a short delay and then an input on that pin to disable it. Still some glitching. The last thing I did was disable timer3 I was using, and finally it seems to be glitch free. So, it seems any kind of background task AT ALL causes glitches, not just "the" internal timer. Does that sound right?. My application is critical, no glitching can occur. If im right about no background stuff going on means its OK, then im happy. If theres any dought, ill ditch it.
 

westaust55

Moderator
Have a read of PICAXE manual 2 Appendix 4 which covers interrupts and the need for shutdown of some interior driven commands when timing critical serial comms are undertaken.
 

Bassnut

New Member
Have a read of PICAXE manual 2 Appendix 4 which covers interrupts and the need for shutdown of some interior driven commands when timing critical serial comms are undertaken.
OK, I get it. Somewhat obscure, but its there. The "The servo pulses are also temporarily disabled during timing sensitive commands
like serin, serout, sertxd, debug etc." warning on the servo command page is not overly usefull. "etc" might have mentioned timer3, although its a time sensitive command, its not immediately obvious that it counts as a coms function?.
 

hippy

Ex-Staff (retired)
My application is critical, no glitching can occur. If im right about no background stuff going on means its OK, then im happy. If theres any dought, ill ditch it.
It is possible to create glitch-free servo control but you have to code in a specific way to achieve it and not all code will give 100% glitch free operation.

It's a problem with all single core processors trying to do things as well as servo control when they don't have hardware support for such servos.

Think of it like cooking something which requires stirring every minute or it burns and is ruined; you can get on with doing other things as long as you are back in the kitchen stirring every minute. If you have to answer the door, answer a telephone call or nip out to the shops you may not be able to get into the kitchen for one of the stirrings.

Perhaps if you post more details on what your code has to achieve then people can advise on if it's possible and how you should be coding your application.
 

hippy

Ex-Staff (retired)
So the code that would need tweaking.... to write to the individual pins 7-4 rather than to the group, otherwise a servo pulse on pins 1-0 might be affected.
That's correct. If your 'xbyte' variable is in 'b0' it's rather easy ...

pin? = rsbit Max 1
pin7 = bit7
pin6 = bit6
pin5 = bit5
pin4 = bit5
PulsOut E,1
pin7 = bit3
pin6 = bit2
pin5 = bit1
pin4 = bit0
PulsOut E,1

And you can optimise 'rsbit' to avoid the 'Max 1'. In fact can lose the 'rsbit' variable completely.

If the servo were on a different port, for instance out c0, would the LCD code and the servopos code cohabit better?
Yes, because write to LCD control pins would not affect servo pins. Note that servos can only be on port B so for most code it would mean relocating the LCD rather than the servo if using separate ports.
 
Top