View Single Post
  #3   Spotlight this post!  
Unread 01-03-2006, 12:28
Mark McLeod's Avatar
Mark McLeod Mark McLeod is offline
Just Itinerant
AKA: Hey dad...Father...MARK
FRC #0358 (Robotic Eagles)
Team Role: Engineer
 
Join Date: Mar 2003
Rookie Year: 2002
Location: Hauppauge, Long Island, NY
Posts: 8,801
Mark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond reputeMark McLeod has a reputation beyond repute
Re: loosing encoder count

In addition to Eugene's suggestion here are some random observations.

I assume the printf's are only there due to the prior dropped count problem, since they can delay you enough themselves to cause dropped counts.

You know you are purposely dropping a count whenever you get to "p!!!!!!!"

I also assume you are enabling low priority interrupts in general (GIEL)somewhere.

I might add "section("MATH_DATA")" to your pragma to be on the safe side, but it doesn't look like you need it the way the code appears now.

Your pan & tilt lines are reversed in code verses your later comments. Certainly crossing the B lines will drive you crazy, e.g.,
Code:
	/*==== ENCODER PINS ====
	 *Pan	A: INT2/RB2/digital input 01
	 *Tilt	A: INT3/RB3/digital input 02
	 *Pan	B: RB4/digital input 3
	 *Tilt	B: RB5/digital input 4
*/
Whenever you reverse direction or hover at one position your logic is susceptible to extraneous counts as the A line can flicker on/off.
__________________
"Rationality is our distinguishing characteristic - it's what sets us apart from the beasts." - Aristotle

Last edited by Mark McLeod : 01-03-2006 at 12:52.