Real time clock + external interrupt in one PIC possible?

[mpgmike]

Something like this:

"ON INTERRUPT GOTO Handler"

DISABLE
Handler:
IF INT0IF = 1 THEN
  Counter = Counter + 1
  INT0IF = 0
ELSEIF TMR1IF = 1 THEN
  Speed = Counter
  Counter = 0
  TMR1IF = 0
  TMR1H = (Preload value, HIGHBYTE)
  TMR1L = (Preload value, LOWBYTE)
ENDIF
RESUME
ENABLE

[Mugelpower]

Thank you for the example,

but could you explain to me what TMR1H and TMR1L are for?

regards from an inept programmer...

[mpgmike]

Timer1 can create an Interrupt when it "rolls over" from $FFFF to $0000. This creates TMR1IF = 1. Timer1 is a 16-bit counter/timer, which means it can reach 65,535d (Hex $FFFF) before going back to zero and tripping an Interrupt Flag. Since it is a 16-bit counter, the value in the counter needs 2 bytes, which are TMR1H(IGHBYTE) and TMR1L(OWBYTE). If you are running your OSC at 4 MHz, then your Fosc/4 = (4,000,000 / 4) 1,000,000 Instruction Cycles per Second. This equates to (1 / 1,000,000) 0.000001 second (1 us) time frame per Instruction Cycle. Options for Prescaler in the Timer1 SFR goes as high as 1:8. At max 1:8 you can get 8 us (0.000008 second) clicks on your Timer1. Since Timer1 maxes out at 65,535, you can run Timer1 up to 0.52428 seconds. This isn't a very "friendly" time frame to work with. However, it is slightly over a half second. If we calculate 0.5 seconds divided by our 0.000 008 second TMR1 clicks, we get 62,500 TMR1 increments yield 1/2 second (0.5 seconds).

Back to computerese, a byte = max 255 while a word = max 65535. The architecture of the 8-bit Microchip MCUs means each address holds 8 bits, or 1 byte. In order to assign 16 bits to the Timer1 counter, it takes 2 addresses, or 2 bytes. Microchip has decided to name the 2 bytes required by Timer1 "TMR1H" for the upper byte value and "TMR1L" for the lower byte value. Sometimes it's easier to deal with our familiar decimal system. PBP lets us do that. Sometimes it's easier to deal with binary, as in setting Special Function Registers. PBP lets us do that as well. Sometimes you are forced to work with hexadecimal. Well, I find working with Hex easier with a calculator that came standard on both my MAC OS and Windows 10. It has Programmer function that easily converts any format (decimal, octal, hexadecimal, or binary) to any format (ditto).

Back to your original question, since Timer1 trips a flag when it overflows, if you want a 1 second increment, it can't happen. [You could work with some of the slower factory oscillator speeds available in ALL PIC MCUs and do the conversion math for PBP.] Best you can get at PBP's slowest OSC speed is 0.52428 seconds. If you could work with 0.5 seconds, then all we have to do is start Timer1 part way through it's counting sequence so when it flips, we got a 1/2 second.

Review, 4 MHz OSC + 1:8 Prescaler X 65,535 gives us 0.52428. If we want 0.50000 then all we have to do is take 0.5 and divide it by 0.000 008 and we get 62500. We don't want to START there, we want to END there. So we must subtract 62,500 from 65,535 and get 3035. That's bigger than 255, which means it is bigger than a byte. In order to contain such a large number, it takes 2 bytes (which max out at 65,535). I like working with decimal since that's what I grew up using. However, PIC requires that this decimal number be separated into it's upper byte and lower byte. You could convert it to binary and get %0000 1011 1101 1011, or convert it to hex and get $0B DB. If you wanted to load TMR1 with binary you would:

TMR1H = %00001011
TMR1L = %11011011

Hex is shorter and accomplishes the same thing:

TMR1H = $0B
TMR1L = $DB

Of course you could do it with decimal and:

TMR1H = 11
TMR1L = 219

Bottom line, Timer1 will start counting at 3035 through 65,535 and trip a flag at the 1/2 second mark. With that flag (TMR1IF) you can direct your code to an Interrupt Handler to do whatever you require. Though lengthy, I hope this helps.

[Mugelpower]

Thank you mpgMike,

so you convinced me to use an external real time clock. That needs an interrupt because the real time clock isn´t in sync with the pic s own clock.

I need to get 0.1 sec timing increments because 1 sec isn´t fine enough for starting time, max time is about 600 sec so I need a long variable to calculate with.

Hope i can work things out how to get the pic to use the real time clock but I guess there are lots of examples out there.

For explanation: we (my wife and I) drive so called Oldtimer-rallyes in a 1983 Mustang convertible and were on an event last weekend where we had to drive at an average speed of 28 km/h as constant as possible AND the starting point of the road was equipped with a clock and a light gate for the starting point. The end point of the distance was kept hidden so no one knew how long the distance was and so we couldn´t calculate anything. Only possible way was to drive as constant as possible with the given speed of 28 km/h. And to make things worse, there are heroes out there driving the distance
in 0,1 sec of the calculatet time . There were two of these hidden drives , the first we were 13 seconds off (which threw us out of the reach of a cup), the second we made it in 0,5 seconds of the sheduled time.
My wife wasn´t happy about driving home without a cup (first event this year we drove without cup so shes used to getting something and shes the driver) so my task is it to get something done to increase our chances next time.

Oh yeah the other guys use GPS and mobile phone apps and such.
I hope you appreciate that the old guy (54 years) tries to solve the problem with PIC Hardware/software.......haha


regards

Miguel David

[HenrikOlsson]

Why would you use an external real time clock for this? Those are meant to keep real time as in years, days, hours, minutes - they're not meant for timing applications where you need 0.1 second resolution or better.

Instead of using interrupts to count the pulses from the driveshaft why don't you use one of the timers to count the pulses for you and use another timer as the timebase? Mike gave you an exceptional explaination of how to use a timer to generate an accurate timebase with just about any resolution. I honestly believe it's going to be a lot easier AND give you better results then trying to use an external RTC chip.

Also, timing 600 seconds with 0.1 second resolution is only 6000 "counts" so it not require a LONG. If 600 seconds is the longest time you can get 10ms resolution and still stay within the bounds of a WORD variable.

What is the longest time you'll likely want to measure? Are you getting 1 pulse per revolution of the driveshaft? What's the distance traveled per pulse?

/Henrik.

[HenrikOlsson]

By the way, if the PIC isn't supposed to do much more than count the pulses and keep time there's really no need to complicate things with interrupts etc. If you'll answer the questions in my previous post I'll get you something you can use as a startingpoint.

/Henrik.

[Mugelpower]

Hello Henrik,

thank you in advance for your input. I get one pulse per driveshaft revolution that drives the car ca. 0.6m .
I don´t expect any road mission like this to exceed 8 minutes so 600 seconds as upper limit should do.

regards and greetings to sweden (had some nice days in Malmö 4 years ago)

Mugelpower