![]() |
System Clock?
I'm pretty new at this programming stuff, and as we're trying to get a speed control on our robot's wheels together, I concluded that we needed some way to record time. I came up with the following, which will keep track of the time since powerup:
Code:
/* clock.h */ All times are of type clock_int, which is an unsigned long int (32 bits). clock_init() is called in User_Initialization and will set up the interrupts for the timer. Clock_Interrupt_Handler() is called from the interrupt handling routine; it checks to see if the timer triggered the interrupt, and if so, increments clock_time. Get_Clock_Time() safely returns the value of clock_time. The timer interrupt will be so arranged as to trigger every .1 msec. Thus, the clock ticks every .1 msec. Doing the math on that shows me that the RC could run for nearly 5 days continuously before the clock resets to 0. I think it's a pretty safe bet that no match will go on that long, so I now have a safe way of timing things by simple subtraction. Comments? I'll be the first to admit I'm a n00b. Is this a totally insane way of doing this? Is there some RC feature that does this for me? Or am I a Clever Boy for putting it together? |
Re: System Clock?
you claimed to be "new" at this, have you tried the clock? I plan on making use of it, it's a good idea.
|
Re: System Clock?
Another question: Is .1msec too small an interval? I'm concerned that it will chew up all the processor time and make everything die a horrible death.
|
Re: System Clock?
Programming isn't my field of expertise, so correct me if I'm wrong, but isn't user_routines (or whatever that user function is called) called every 26.5ms? If so, couldn't you just count how many time's it's been called. Increment some variable or something. I'm not sure how exact the time is on it though...
|
Re: System Clock?
Quote:
Quote:
|
Re: System Clock?
Quote:
It's not 26.2ms, unless my conversion was wrong.. I had (counter*26.2)/1000 or..maybe it was 10000 Which should give me seconds.. but didn't. Not too sure what was going on there, but it didn't seem that accurate |
Re: System Clock?
Quote:
What happens is that if your code is too slow, it might not make it back in time to read the very next data packet, and thus might miss a loop. What you need to do is to keep track of the packet number of the last data packet you read, and multiply the difference between that number and the current packet number by 26.2 before adding to your match timer. BTW, DON'T multiply by 26.2 (a float). DO multiply by 262, and simply consider your match timer to be in units of 10ths of milliseconds instead of milliseconds. The same goes for any other floating point operations. You need to realize that the PIC processor does not natively support floating point operations, and any floating point calculations you request will be performed in software -- which takes up more code space, AND takes MUCH longer. IF you are currently using floats, this COULD be why you are missing data packets, and why your timer was not accurate. Better yet than multiplying by 262 is to not multiply at all! Just leave your timer in units of 26.2ms clock ticks. (You still need to account for missed packets.) OK. this post is getting too long. If you need more details, just ask. (Or search. I'm pretty sure this has all been discussed before. :) ) |
Re: System Clock?
Quote:
It wasn't working right, and didn't seem to be a good way of doing it, so I didn't. That was just supposed to be until my team got the sensors I needed mounted. |
| All times are GMT -5. The time now is 13:04. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi