System Clock?

[Orborde]

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:

/* clock.h */ 

#ifndef CLOCK_H
#define CLOCK_H

typedef unsigned long int clock_int;

/* sets up the clock interrupts and such */
void clock_init();

/* runs every time the clock hits an interrupt */
void Clock_Interrupt_Handler();

/* starts the clock ticking */
void clock_start();

/* halts the clock */
void clock_stop();

/* returns the current clock time safely */
clock_int Get_Clock_Time();

#endif


/* clock.c */
#include "ifi_aliases.h"
#include "ifi_default.h"
#include "ifi_utilities.h"
#include "clock.h"

volatile clock_int clock_time;	// time elapsed since last boot * .1msec

/* sets up the clock interrupts and such */
/* call this from User_Initialization */
void clock_init()
{
	clock_time = 0;
};

/* runs every time the clock hits an interrupt */
void Clock_Interrupt_Handler()
{
	//
};
/* starts the clock ticking */
void clock_start()
{
	// enable the clocking interrrupt
};

/* halts the clock */
void clock_stop()
{
	// disable the clocking interrupt
};

unsigned long int Get_Clock_Time()
{
	unsigned long int time;
	
	/* halt the clock for reading */
	clock_stop();

	/* read the time */
	time = clock_time;

	/* start the clock again ASAP */
	clock_start();

	return time;
};

Explanation of the above:
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?

[stephenthe1]

you claimed to be "new" at this, have you tried the clock? I plan on making use of it, it's a good idea.

[Orborde]

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.

[sciguy125]

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...

[Astronouth7303]

Originally Posted by sciguy125

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...

26.2ms. This can work, it's easier to just use given milliseconds.

Originally Posted by Orborde

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.

It is probably a little small.

[devicenull]

Originally Posted by sciguy125

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...

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

[Greg Ross]

Originally Posted by devicenull

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

If you're going to use the loop time to keep track of elapsed time, you'll need to check the packet number, and account for missed packets (loops).

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. )

[devicenull]

Originally Posted by gwross

If you're going to use the loop time to keep track of elapsed time, you'll need to check the packet number, and account for missed packets (loops).

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. )

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.