 |
 |
| View previous topic :: View next topic |
| Author |
Message |
coderchick
Joined: 12 Jun 2008
Posts: 25
|
| get_timerX() not working properly....? |
 Posted: Thu Jun 12, 2008 4:27 pm |
 |
|
Ok, here we go, below is my "problem code". What I'm trying to do is sense when a button is double clicked. I know that when a button is pressed and held down, this function is called every 19ms, and when a "double click" occurs there is a much longer pause. So instead of using a counter, I thought using get_timerX() would be better, as long as the button was held down and the timer was reset at the end of the DoubleClick function, I should always have the same value for dclick, right? No, instead, according to the debugger, the value I get for dclick ranges from 78 to 225 or whatever. Do I have this set up correctly? I know for a fact that this function is called every 19ms, so why am I constantly such a huge value range from my timer?
| Code: |
setup_timer_3(T3_INTERNAL|T3_DIV_BY_4); //double click timer, 209ms overflow
void DoubleClick()
{
int dclick;
dclick = get_timer3();
button = TRUE;
if (dclick >= 150 && dclick <= 200)
{
function1();
dclick_set = TRUE;
}
else if (!dclick_set || dclick > 200)
{
function2();
}
set_timer3(0);
}
|
_________________
KMoe
~We the willing, led by the unknowing, are doing the impossible for the ungrateful. We have done so much, for so long, with so little. We are now qualified to do anything with nothing -M. Theresa |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Thu Jun 12, 2008 11:21 pm |
|
|
Post a small test program that calls your function, and demonstrates
the problem. Then I can test it tomorrow on a PicDem2-Plus board.
The test program should be compilable without errors, and should have
the #include statement for the PIC, #fuses, #use delay(), main(), etc.,
and all variable declarations. It should also be very short.
Also post your compiler version. |
|
|
Ttelmah
Guest
|
|
| Posted: Fri Jun 13, 2008 2:26 am |
|
|
You don't give us much hope of answering, since you don't give the processor clock rate, at the very least....
However, trying to work backwards: '209mS'. Since Timer3, is a 16bit timer, would imply it being clocked at 313569Hz. Using /4 prescaler, would imply an instruction clock at 1.25MHz, and a master oscillator at 5MHz. If this is not the clock rate you are using, then you have the first part of your answer.
Then, in 19mSec, this will count: 313569*0.019 counts. 5957....
What is happening, is that you are looking at only the low byte of a 16bit value. The change from 78 to 225, would represent a change of just 147 counts or 468uSec. Though you say the code is being called 'every 19mSec', there is almost certainly some granularity in this figure (other things happening, or just when in a particular loop a hardware change occurs), so you are seeing this much change. It'd only represent a change from 19.16mSec, to 19.49mSec.....
I'd suggest switching to using the /1 prescaler, can reading only the _MSB_ of the returned 16bit value. (effectively giving 1/64th the current count) This would give an expected count of 93, and this would change by only a couple of counts for the same range.
As PCM programmer says (here in part, and in other threads), the _best_ way to track down a problem, is to make small programs containing just the 'problem' parts. This then increases the chance of finding what is going on, and also makes something postable, that (since it is a 'runnable' program), we an see everything that is necessary to have a hope of diagnosing what is happening.
Best Wishes |
|
|
coderchick
Joined: 12 Jun 2008
Posts: 25
|
|
| Posted: Fri Jun 13, 2008 4:20 pm |
|
|
Unfortunately, my code is kinda large, and when I posted the question I took just a snippet of it and was hoping for the best...sigh, oh well. What I'm trying to do is communicate with a Sony camcorder through it's LANC/Ctrl-L protocol. I've got the majority of it down, except this double clicking feature, when the button is hit once, it zooms normally, when it is double clicked, it zooms fast. I wanted to use the get/set_timer function to keep track of the time between the double click and I fear that the external interrupts I'm using may be causing the difference in the timer values.
I did as PCM suggested and ran a small program that was just the double click feature (see code below). No interrupts, no other data acquisition, just a button and looking for a double click.
| Code: |
#include <18F6527.h>
#device adc=8
#FUSES NOWDT //No Watch Dog Timer
#FUSES HS //High speed Osc (> 4mhz)
#FUSES PUT //Power Up Timer
#FUSES NOPROTECT //Code not protected from reading
#FUSES NODEBUG //No Debug mode for ICD
#FUSES BROWNOUT //Reset when brownout detected
#FUSES BORV25 //Brownout reset at 2.5V
#FUSES LVP //Low Voltage Programming on B3(PIC16) or B5(PIC18)
#FUSES NOCPD //No EE protection
#FUSES NOWRT //Program memory not write protected
#use delay(clock=5000000)
#define NUM5 PIN_D2
#define BUTTON_DWN 0x01
int dclick_set = FALSE;
int normal[2] = {0x28, 0x37};
int fast[2] = {0x28, 0x1C};
void DoubleClick(int n_button[], int f_button[])
{
int fast_mode;
int dclick;
dclick = get_timer3();
if (dclick >= 150 && dclick <= 200)
{
fast_mode = TRUE;
dclick_set = TRUE;
}
else if (!dclick_set || dclick > 200)
{//returns to normal
fast_mode = FALSE;
dclick_set = FALSE;
}
else if (dclick_set)
{//stays in fast mode
fast_mode = TRUE;
}
/*commented out to test double click functionality
if (fast_mode)
{
enqueue (&hi_que, f_button);
}
else
{
enqueue (&hi_que, n_button);
}
*/
set_timer3(0);
}
void main()
{
setup_adc_ports(NO_ANALOGS);
setup_adc(ADC_OFF);
setup_psp(PSP_DISABLED);
setup_wdt(WDT_OFF);
setup_timer_3(T3_INTERNAL|T3_DIV_BY_4);
setup_comparator(NC_NC_NC_NC);
setup_vref(FALSE);
while (TRUE)
{
if (input(NUM5) == BUTTON_DWN)
{
DoubleClick(normal, fast);
delay_ms(15);
}
}
}
|
Here the get_timer works great and gives me a constant value when the button is being held down, and a larger value when it is double clicked. However, as soon as my external ints. are added back in, it'll go all haywire on me. Is this more/better info? Does anyone have an idea around this?
_________________
KMoe
~We the willing, led by the unknowing, are doing the impossible for the ungrateful. We have done so much, for so long, with so little. We are now qualified to do anything with nothing -M. Theresa |
|
|
Ttelmah
Guest
|
|
| Posted: Sat Jun 14, 2008 4:32 am |
|
|
Read what I have posted. It explains what is happening. The interrupt is creating the granularity in when the routine is being called (it will). It won't matter, if you change to using the timer with the count returned incrementing slower,as I have suggested.
It does though also suggest that you are taking a long time in the interrupt...
Best Wishes |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
