Real time clocks, out of the question?
 

Hullo everyone. I'm Evan Wilson, lead programmer for Team 2172, St. Edward High School.

Our robot is all crated and shipped off... with horrible loop-counting timekeeping. In the past, I've heard of creating a real time clock with the Timer1 module in the PIC controller.

Is it humanly possible to create such a program? I DO know some PIC assembly, and certainly C. I assume this would be intensively assembly. Also, is there actually a crystal in the controller already? When reading the datasheet for the chip, it almost made it sound as if I'd need to do some whacked out solder job...

I would like to have gotten this done for this year's competition, but seeing as we have no adult mentors (and I'm a junior with a bit of a tight schedule) we couldn't cram in the work for that.

Anyways, thanks to anyone who could help, give links, etc.

Re: Real time clocks, out of the question?
 

Hi, We too have had te same problem, in easyC there are a total of 6 timers, however, we haven't been able to get any of them to work, i believe timer 1 is used for the camera, but we cant seem to get any of the other timers to work. If any other teams have been able to get them to work, it would be extremely helpfull.
Thanks
Malhon

Re: Real time clocks, out of the question?
 

Well, in my case, I've used MPLAB the whole way. But does easyC actually have timers? I dug into the datasheet and found the Timer0 and Timer1 modules in the microcontroller and wasn't sure how to use them.

http://users.tkk.fi/~jalapaav/Electr...ock/index.html

That seems a little helpful.

Re: Real time clocks, out of the question?
 

Yes, EasyC does have timers, six of them. I believe we have used up to three at once, and they all work fine.

What exactly isn't working for your? Could you post your code?

Thanks,
Nathan

Re: Real time clocks, out of the question?
 

Well, the problem is that I don't have any. Without EasyC, I just have the arm calculating based on loop counting. Multiples of 26.2 ms. There's no way I can switch to EasyC this year. I guess that would be a logical solution for next year.

Is there anyone here who has ever written a timer and interrupt routine for a real time clock? That's really the only thing I could worry about anyways. Otherwise I'll just have to stick with loop counting.

Re: Real time clocks, out of the question?
 

Timers are simple to use, no soldering required.
IFI has a white paper on coding timers that goes into the bits and bytes of it all:
http://www.ifirobotics.com/docs/time...004-jan-14.pdf

For a description of the timer library calls see the MPLAB-C18-Libraries.pdf manual under C:\mcc18\doc.

Here's a sample using the timer libraries:

Re: Real time clocks, out of the question?
 

Thank you very much. I hope my assembly serves me well.
I think I can dig up the differences in the new controller.

Want to be a mentor...

just kidding.

Re: Real time clocks, out of the question?
 

I wrote some real-time clock code for the EDU-RC a few years ago. Here's a link: http://kevin.org/frc/2005/edu_clock2.zip.

-Kevin

Re: Real time clocks, out of the question?
 

Okay. Thanks very much Kevin and Mark. The last thing I need to make sure of is the value for the system clock. In the edu_clock code, it's specified as 10MHz. Does anyone know if there would be a difference in the PIC18F8722? I seem to remember reading something about 32.blablabla MHz somewhere. Or maybe it's changeable...

After this, I deserve to be put back into grade school if I can't do the math.

THANKS

Re: Real time clocks, out of the question?
 

It's the same 10MHz for the PIC18F8722 we use.

Re: Real time clocks, out of the question?
 

Remember to preset and start the timers before using them. Timers won't work if they aren't running.

Re: Real time clocks, out of the question?
 

There's a nice set of interface functions for using Timer1 here: http://www.chiefdelphi.com/forums/sh...ht=wallclock.c

Re: Real time clocks, out of the question?
 

The way Kevin's code sets up the interrupt is the best. The other example code posted/referenced all appear to reload the Timer register each time the interrupt is serviced, and the interrupt service latency then becomes an additive value to the timer's period. To some extent, only reloading the upper byte will help avoid the problem, but its easy to avoid the problem all together by just configuring the timer differently. An added bonus is that a few instruction cycles are removed from the ISR by not having to reload the register each time.


Another thing to remember here is that this microcontroller does not have a divide instruction, so including divide operations in an interrupt routine is forcing the microcontroller to execute a lot of instructions on a frequent basis.


Some of the examples provided utilize variables wider than 8 bits, but I didn't notice any cautionary notes for routines that access these variables outside of the interrupt service routine. Because this micrcontroller operates on 8 bits at a time, if a routine were testing a 16 or 32 bit variable and an interrupt occurred in the middle of such a test, the ISR will end up invalidating the foreground operation that it interrupted. No amount of 'volatile' declarations will fix that problem. If the timer value absolutely MUST be greater than 8 bits, then the foreground operations that access this variable must temporarily disable the relevant timer interrupt prior to accessing or manipulating the variable, then re-enable the interrupt after the operation is complete.


I tend to use timers that count down to zero because most microcontrollers are able to test for a zero condition in a single instruction, whereas testing for a specific value tends to use two or more instructions... and this is something which is true for the PIC18.

In other words:

Will generate fewer instructions than:


As such I tend to write timer ISR's this way:

In order to use these timers in the foreground code, it is as simple as:


Likewise, if you want the expiration of a timer to set an event flag, the ISR could be modified like this:

So the foreground code could do something like this:

Clearly individual timers can be declared as needed, at whatever the most appropriate resolution for a given function may be. In general, I have found that most timers can be designed to work within an 8 bit value... in other words, if I need a timer that normally needs to run for a 1 second period, that a 10ms resolution timer, loaded with 100 provides more than enough precision.

Re: Real time clocks, out of the question?
 

I wrote some code that starts uses the timer mentioned above that turns on an LED 1:30 seconds into the operator controller part.

Our team has a "Heads up display" we used last year for shooting, we remade it this year but this was the only use we could come up with.

Re: Real time clocks, out of the question?
 

Alright. I have another question about how the timer variables work in all of these. I've used storage classes/qualifiers occasionally but I don't understand the significance of using, say, extern and volatile to store the timer variables. Could anyone shed some light on this?

Re: Real time clocks, out of the question?
 

'extern' is much like a function prototype, meaning that it is allowing you declare the variable within the local scope such that the compiler will know what the variable type is and can generate the appropriate code. When the linker pulls all of the object files together, it will resolve the external dependancies of each of the object files, and if you haven't declared the variable itself anywhere within the program, will generate an error and abort.

'volatile' tells the compiler that the variable may change on its own and to generate code as appropriate. For optimization purposes, a compiler may read a variable from memory into a temporary register, and subsequent read/write operations to that variable _may_ only occur to the register without updating the memory location. Telling the compiler that the variable is volatile causes the compiler to re-read the variable's memory location each time it is used, and to write it back to memory each time it is updated.

'volatile' would be used for things like hardware periphial registers, as well as things like variables that might change inside of an interrupt routine.

Since the compiler can't know why you are telling it that the variable is volatile, it wouldn't generate additional instructions to disable interrupts during critical regions to ensure that a multi-byte variable read/write operation is performed without the potential for another interrupt routine corrupting the operation. Pre-emptive multi-tasking operating systems generally pose the same potential for corruption that an interrupt routine does.

The 'static' qualifier allows variables to be declared within a local, rather than global, scope and simply tells the compiler to declare the variable in a memory location that is static, rather than allocating it on the stack frame (or emulated equivilent thereof) of the local function.

Any variable declared outside of a function is normally considered a global variable, but unless other source files provide an 'extern' reference, the variable's use will remain limited to that source file, and is sometimes referred to as a 'local global'. The caveat here is that if you were to declare another 'local global' in another source file, the linker will (usually) have a problem with the duplicate declarations, and generate an error.



Recognizing that Microchips documentation already presumes a certain familiarity with the "C" language and doesn't really get into all of the specifics, for those that already have a general grasp on the "C" language, two books that I would recommend are:

The C Programming Language by Brian Kernighan and Dennis Ritchie, who are the origional authors of "C".
A book on C by Al Kelly and Ira Pohl.

K&R's book is very terse with minimal examples, but is the bible. The 2nd one is also a bit terse, and goes into depth more than K&R's book.

I've included links to Amazon's website as a convienent reference, but retailers such as Barnes & Noble also generally carry these and other good reference books where you can browse before you buy.

Re: Real time clocks, out of the question?
 

Strangely enough, K&R is sitting right here on my bookshelf. Somehow I hadn't remembered "volatile". I'll go reread through the data types/variables stuff again.

Not to seem pestery... but I've once again confused myself in this code. I read through the PIC's datasheet (timer section) and studied up on the registers. On the good side, I now completely understand all the scalers, clocks, and flags, but I could not seem to understand how the high and low byte registers worked/were needed. I don't see how an integer could go past 65,535, so why does the high byte happen to be able to have a value over that?

I also could not find an equivalent for the PR2 register for Timer1. Is that simply not present and do I have to use conventional math to downscale further?

Thanks again for the help.

Re: Real time clocks, out of the question?
 

Timer's 2 & 4 are 8 bit wide timers and have the "PR" registers, the other timers are 16 bit.

Timer 1 is a bit special and can be used for a low power, real time clock function.

Without a specific reference, I'm not sure what you mean about the high byte having a value greater than 65535. My only guess would be that by setting a value to zero, you'll get an effective divide rate of 65536, but I don't immediately see that in the documentation.

The reason that the 16 bit counter is split into two 8 bit registers is that the CPU only operates on data 8 bits at a time. So a 16 bit read/write operation requires two data bus operations to manipulate the 16 bit value.

Does that help or did I miss one or more of the questions?

Re: Real time clocks, out of the question?
 

Ahhh, that explains things a bit. I should have thought about that. RD16 two bytes wide, duh.

Thanks for that tidbit.

And the high and low bytes. In the wallclock code (http://www.chiefdelphi.com/forums/sh...t=wallclock.c), the high byte value is.... NEVER MIND

Someone can't count their zeros.

I still don't exactly understand what the purpose of the high and low bytes are. Is it like an loop condition? Above the max value for a 16bit number counts as an overflow and it resets, setting the flag with it?

THANK YOU

Re: Real time clocks, out of the question?
 

One of the interrupt options is to interrupt on timer overflow, and that is how some of the other examples posted work.

If you:

- stop the timer
- load a 16 bit value into the timer register
- reset the interrupt flag
- start the timer

You will get an overflow interrupt in however many timer ticks it takes for the pre-load value to reach the point of overflow (0xffff -> 0x0000).


Having the timer value available could also be useful for calculating the period between two events, such as a transition on an input pin that triggers an interrupt. The input interrupt could read the current timer value, and subtract the timer value of the last input transition to calculate the amount of time elapsed since the last input interrupt.

Ideally, one would use something like the CCP module to time stamp an input transition, but in the case of IFI's RC, those pins aren't available as for user Digital I/O pins.

As an example, for something like motor velocity control, at slow speeds, if a rotational speed slower than 1 pulse per sample period was desired, you could use period measurement to gain some additional resolution, and above a certain rotational speed, you could switch to counting the number of pulses per period method.

Each microcontroller manufactuer has their own ideas on the degree's of flexibility that they make available. Microchip's 8 bit PIC family is pretty average. Some parts have less flexibility, others have quite a bit more. In this case, you have to do the best you can with what they give you...

Re: Real time clocks, out of the question?
 

I thought the WPI library had built in timers? What's the difference between those and "real time" timers?

Thanks,
Nathan

Re: Real time clocks, out of the question?
 

Setting up just a realtime clock isn't that hard. I was thinking of doing it myself. I just have to figure out how to configure which timer to achieve something reasonable.

Re: Real time clocks, out of the question?
 

Here is the code we used for a "clock". It uses Timer 2 and has a number of options for flexibility. It is not a "real time clock" in the sense that it doesn't compute hour/minute/second but works off clock "ticks", which for a 2 minute match, or a 15 second autonomous, works fine for us. By default, it's configured to count milliseconds (1 tick = 1 millisecond), but has 2 other predefined options for increased accuracy.

Mike

Re: Real time clocks, out of the question?
 

In teaching timers I use a demonstration program to calculate all the possible timer prescaler/postscaler combinations for a given Hertz or time period. It's an easy beginner exercise to write such a program for the PIC (or VB), and also can be used to teach them about maintaining the Master processor communication leading to an easy elimination of the Master handshake.

Here's a sample output calculating 2400 Hz used with an LCD display off a digital output.