RTC Interfacing.

Go To Last Post
21 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

I have to implement RTC for that I was searching in the forums. In some posts I found that it can't be implemented with avr mega16. Is it really so?

Now, how can I know on which micro it can be implemented. Is there any micro which has RTC feature already?

If you please send me some links from where I can find about this RTC Implementation. I used google but success has yet to come for me.

Thanks,
Anmol Kumar

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Software or Hardware Clock ?
If hardware, what chip you are talking about ?

Harald.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have to capture the date and time at particular time. So, which one for me hardware or software ?

Sorry for this one. Actually I have no idea about this one.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I think, I don't understand what you want to do.
Please explain a little bit more of you project.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Its a software for monitoring the remote site data. It captures the data (through some sensors) and transmit those values at some specified location through wavecom GSM modem (using AT commands). So, I have to send the date and time also with these values read from sensor.

Thanks,

Anmol Kumar

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The technique requiringthe least amount of hardware is to implement the RTC in software. You do this by setting up one of the AVR timers to generate interrupts with a given frequency (eg 1 KHz). Lets call these "ticks". You then service these interrupts and maintain a count of how many such ticks you have seen. When you've seen 1000 of'em you increment the variable containing the number of seconds elapsed (and zero the ticks variable). Whenever you increment the seconds variable to be > 60 you increment your minutes variable (and zero the seconds variable). 60 minute increments the hour counter. 24 hours increment the day counter etc etc.

Any modern AVR will have enough hardware to do this. The hardware requirements will be governed much more by other thngs, like other peripherals (a display maybe?, buttons to start and stop the clock?, send time over the U(S)ART? etc). In your case I suspect the GSM transmission to be much more complex.

Depending on how accurate your timing needs to be you need to take great care in selecting the clock source (eg. chrystal) that the AVR runs from.

On my bench is a ATmega88 toy project. It runs 4 clocks, and displays them on a LCD display: Ordinary clocks (real time, like your wrist watch), stop-watches with lap times (1/100 of a second resolution), or (down-counting) alarm timers. Clock source is an 8 MHz chrystal. The RTC drifts a few seconds per 24 hours.

Hoe are you using the 16-bit timer(s) on the Mega16 presently?
What clock source is the Mega16 running off today?

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

anmol2701 wrote:
Its a software for monitoring the remote site data. It captures the data (through some sensors) and transmit those values at some specified location through wavecom GSM modem (using AT commands). So, I have to send the date and time also with these values read from sensor.

Thanks,

Anmol Kumar


WHY does the monitoring site have to send date and time? Those sensors you're reading the data from didn't report date and time to the AVR, did they? The AVR is just acting as the first device in a communications chain, interfacing your sensors to a modem, with the ultimate consumer of the data being at the central site receiving the modem traffic. Why not make it the central site's responsibility to add date/time information to the sensor outputs, rather than the little AVR sensor-to-modem glue chips? Are the communications delays imposed by the modem and through-the-air broadcast channel that significant or variable?

Wouldn't it be nicer to avoid having to implement a RTC in each of your remote data collection stations, and then worry about how to synchronize all their RTCs to a common reference? Just let your central site do the work.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you have constant mains power, you can do this easily with an AVR and a temporary battery backup.

If you are running on very small battery, you can do it with an AVR that sleeps a lot. This takes a bit of care.

The easiest is probably an external RTC chip like the DS13x7. Just needs a tiny backup battery.

Several mcus will have hardware RTC. e.g. most ARM's.
But you always have to worry about sleeping and battery life.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:
The technique requiring the least amount of hardware is to implement the RTC in software....

The technique explained by you I found this one in this link

http://www.atmel.com/dyn/resourc...

But it says that it can be implemented only on those micros that features the RTC module. So, how can I know or which part in datasheet of micro specifies that it has the required feature.

Moreover, it specifies for the same I require only 32.768 watch crystal. I am using avr mega16 and stk500.

JohanEkdahl wrote:

Hoe are you using the 16-bit timer(s) on the Mega16 presently?
What clock source is the Mega16 running off today?

I am running calibrated internal RC Oscillator. If I want to use crystal which one is suitable for me to purchase.

blueled wrote:
check this:

https://www.avrfreaks.net/index.p...

Tutorial.

Already gone through this link . Thanks for replying.

Levenkay wrote:

WHY does the monitoring site have to send date and time? Those sensors you're reading the data from didn't report date and time to the AVR, did they? The AVR is just acting as the first device in a communications chain, interfacing your sensors to a modem, with the ultimate consumer of the data being at the central site receiving the modem traffic. Why not make it the central site's responsibility to add date/time information to the sensor outputs, rather than the little AVR sensor-to-modem glue chips? Are the communications delays imposed by the modem and through-the-air broadcast channel that significant or variable?

Wouldn't it be nicer to avoid having to implement a RTC in each of your remote data collection stations, and then worry about how to synchronize all their RTCs to a common reference? Just let your central site do the work.

Actually site sends an SMS when an alarm (an error) is generated at the remote site. So, I have to know when that error is/was generated.
None of my sensor is sending date and time (up to my knowledge)

david.prentice wrote:
If you have constant mains power, you can do this easily with an AVR and a temporary battery backup.

This one is good for me I have constant mains power and I'll add a temporary battery backup. But, the problem is how to do, from where to begin? Is it software or hardware RTC. What components are required to achieve this task.

david.prentice wrote:

Several mcus will have hardware RTC. e.g. most ARM's.

Is my AVR Mega16 contains this feature (hardware RTC). The following link contains the datasheet of micro

http://www.atmel.com/dyn/resourc...

I again thank you all for giving such a nice support/help/guidance to me.

Waiting for response of yours.

Anmol Kumar

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Did you not see this in the mega16 datasheet?

Quote:
The clock source for Timer/Counter2 is named clkT2S. clkT2S is by default connected to
the main system I/O clock clkIO. By setting the AS2 bit in ASSR, Timer/Counter2 is asynchronously
clocked from the TOSC1 pin. This enables use of Timer/Counter2 as a Real
Time Counter (RTC). When AS2 is set, pins TOSC1 and TOSC2 are disconnected from
Port C. A crystal can then be connected between the TOSC1 and TOSC2 pins to serve
as an independent clock source for Timer/Counter2. The Oscillator is optimized for use
with a 32.768 kHz crystal. Applying an external clock source to TOSC1 is not
recommended.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you want to use a 32 KHz "clock crystal" then you need an AVR with a timer that can use such a crystal. The respective data sheets will tell you if that is the case or not.

If you don't need to use a 32 KHz crystal then any modern AVR, preferrably with a 16 bit timer/counter available can be used to implement a RTC in software. The RTC accuracy will be the same as the accuracy of the AVR clock source.

I re-iterate: I have a RTC application running on an ATmega88, mounted on the STK500 and with a 8MHz crystal. The clock drifts a few seconds per 24 hours. The timer/counter is not reserved entirely for this RTC functionality - it produces 1 ms ticks for both the RTC functionality and to debounce the STK500 buttons.

If the AVR has a 50 ppm accurate crystal as it processor driving clock then you will gain nothing by attaching a 50 ppm 32KHz "clock crystal".

Bottom line: As long as your AVR (processor driving) clock source is accurate enough, most any modern AVR will be able to run a software-based RTC application (and have plenty of processor cycles left to do other stuff in the application).

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Wasn't much else that got me going tonight so I ended up writing up the following rant/essay:

I'll have to correct myself on the previous post. The RTC application I had on my desk was using the 8-bit Timer/Counter0 of the ATmega88. I found this out when I was returning to the code today to seee if I could cut it down to the bare bones. I could. :wink: Here it is, self explanatory I hope:

#include 
#include 

void InitTimer()
{
	// The AVR is running from a 8 MHz crystal
	// If we prescale with /64 and count 125 timer clock ticks we will get an 
	// interrupt every 1 ms (1 KHz)
	// WGM02:00 = 010 = CTC mode
	TCCR0A |= (1<<WGM01) | (0<<WGM00);
	TCCR0B |= (0<<WGM02);

	// Counting 125 clock ticks means TOP = OCR0A should be 124
	OCR0A = 124;

	// Enable the interrupt
	TIMSK0 |= 1<<OCIE0A;
	sei();

	// Start the timer by setting the prescaler
	// CS02:00 = 010 = prescaler divide by 64
	TCCR0B |= (0<<CS02) | (1<<CS01) | (1<<CS00);

}


volatile unsigned char seconds = 0;

ISR(TIMER0_COMPA_vect)
{
	static int millisecondTicks = 0;
	millisecondTicks++;

	if (millisecondTicks >= 1000)
	{
		seconds++;
		millisecondTicks = 0;
    }
}

int main(void)
{
	// LEDs on PORTD
	DDRD = 0xFF;

	// Start the timer
	InitTimer();

	while(1){
		// Do whatever you want here with the ticks generated by
		// the TC0 ISR. Here's a simple example - output the seconds
		// count to the LEDs (inverted, as the STK500 LEDs are active low)
		PORTD = ~seconds;
	}

	return 0;
}

So far this is tested and proven on my desk. What follows is free thoughts and sketched code that I did not bother to implement and test. If you find any bad ideas, misteaks or types then shoot!

Now, obviously, if you'd like to have full RTC functionality then youd need to do those "when seconds >= 60: increment minutes, zero seconds", "when minutes >= 60: increment hours, zero minutes" etc etc. That is all plain vanilla C programming, and the domain knowledge should be possessed by everyone, so I left it out in order to let the code expose the crucial timer tick generation.

As I said, my clock is off by a few seconds per 24 hours. Makes sense, as 100ppm (assuming that is the accuracy of the crystal) of 86400 (the number of seconds in 24 hours) is 8.64. If the clock needs adjusting this is done by adjusting the TOP value. AS I am using a 8 bit counter, and am counting 125 prescaled CLKs to get a millisecond my smallest possible adjustment is 86400/125 (which makes for a whopping 10 minutes!)

If I moved to the 16 bit Timer/Counter1 I could run with a prescaler of 1 (the timer is clocked at 8 MHz), a TOP of 7999 (counting 8000 timer ticks before generating an interrupt). This would give me a smallest adjustment of 86400/8000 = 10.8 seconds. Still to much.

So one technique to get finer resolution in the adjustments would be to adjust the TOP value for some of the millisecond interrupts. In the ISR we'd do something like this (returning to the 8-bit T/C0):

   OCR0A = 124;
   if (millisecondTicks >= adjustFactor) {
      OCR0A = 123;
   }

If adjustFactor is > 1000 then the condition will never be true and the seconds count at (nominally) 1 Hz. Now, when adjustFactor is 1000 this means that the last count up to TOP before we have done a full new second will demand only 124 timer ticks, not 125. This, in turn means that we have adjusted the clock with 1/125/1000 (one of thousand timer wraps is 1/125 shorter than the normal case). We have adjusted the clock to run 1/125000 faster, or 86400/125000 = 0.6912 seconds per 24 hours. That's a pretty neat smallest adjustment. If we need to slow the clock down we of course do

   OCR0A = 124;
   if (millisecondTicks >= adjustFactor) {
      OCR0A = 125;
   }

instead.

So:

1. Doing RTC in AVR firmware is possible.

2. You don't need a "32 KHz clock crystal" to make an accurate firmware RTC. You do need an accurate clock source.

In fact, when I was a noob here I was a victim for that 32 KHz crystal delusion. Lee was in his biting mood and struck without mercy! I can still feel the beating I got... Oh, OK, exaggerating a wee bit but the core story is absolutely true, down to Lee's old favorite "OK, I'll bite" prelude to the kill... Nowadays he seems to be backing up trucks mostly. 8)

BTW, how hard would it be to detect every fourth or eight millisecond, and use that for calling the button debounce function. No, not hard at all. :wink: You are now using one hardware timer/counter for two purposes. And you might well find a third use for it that would work.

Good night!

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

Last Edited: Tue. Jul 8, 2008 - 11:18 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am surprised that you get such a large error in 24 hours. The official English interpretation of "few" is 5 - 7. So you would lose 3 minutes in a month.

My old feeder used to keep time to about a minute a year, with no special effort. I think I must have been lucky. crystals are normally 20ppm i.e 1.7 seconds a day or 10 minutes a year.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
As I said, my clock is off by a few seconds per 24 hours.

The RTC chip that we have applied in applications--maybe about 10 different production designs over the years--is the Maxim/Dallas DS1305/1306 SPI interface model. That series does not have an internal "tweak" register as some do.

We haven't had any problems per se with timekeeping. My rule of thumb for testing is a minute a month is OK; that is 2 seconds per day. I remember testing a batch of several dozen boards in one of our first applications of the chip, and checking the results a few days later. When plotted it looked like the classic bell curve, and there were no outliers beyond 2 seconds/day.

In my expreince, many PC clocks are no better or worse than that. We call that "good enough" and do not do any special trimming of caps or other to make it "better". But that is for general logging and timing and scheduling on industrial apps. Most are "visited" regularly" anyway. If you are doing unattended telescope operation, say, then your requirements are quite different.

Quote:

In fact, when I was a noob here I was a victim for that 32 KHz crystal delusion. Lee was in his biting mood and struck without mercy! I can still feel the beating I got...

I obviously made an impression. No, I don't remember that one but you plainly do. Given the join dates that would have been back when we both had more hair. I'll have to see if I can search it out. ;) Take care, Johan.

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Lee, just to be absolutely clear: The event occured, but I did exaggerate quite a bit above.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you have a GSM modem, you can pull the date/time from the network, which in turn can be use to sync your internal RTC. But if the GSM network is always available, then a RTC is not even necessary.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Or if the device has Ethernet use Network Time Prtocol (NTP)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I'll discuss it with my seniors to use the date and time from GSM network.

clawson wrote:
Or if the device has Ethernet use Network Time Prtocol (NTP)

Sorry , its not on ethernet.

Thanks for replying.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

JohanEkdahl wrote:

2. You don't need a "32 KHz clock crystal" to make an accurate firmware RTC. You do need an accurate clock source.

Sir , if I use 32 KHz clock crystal then is it possible for me to use 16 MHz Oscillator also?

Moreover , I am using STK500 and this crystal should be used between pins 28 and 29 in AT mega16. Then if you please let me know how to place this crystal (in STK500) or I have to make some external connections.

Thanks,

Anmol Kumar

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Sir , if I use 32 KHz clock crystal then is it possible for me to use 16 MHz Oscillator also?

Yes. (But my point above is that if the 16 MHz oscillator is as accurate as the 32 KHz crystal then you can do with the 16 MHz alone. The word "oscillator" is a bit vague so we can't tell. Only you can.

As for using a crystal on the STK500, have you even bothered to read the documentation? Have you looked at the STK500 and spotted something that looks like a socket where a crystal would fit?

Yes, there is a socket for using a crystal. You will need to move a jumper on the STK500 also. I am not close to any STK500 documentation right now. You read it. It's in the AVR Studio help file.

As of January 15, 2018, Site fix-up work has begun! Now do your part and report any bugs or deficiencies here

No guarantees, but if we don't report problems they won't get much of  a chance to be fixed! Details/discussions at link given just above.

 

"Some questions have no answers."[C Baird] "There comes a point where the spoon-feeding has to stop and the independent thinking has to start." [C Lawson] "There are always ways to disagree, without being disagreeable."[E Weddington] "Words represent concepts. Use the wrong words, communicate the wrong concept." [J Morin] "Persistence only goes so far if you set yourself up for failure." [Kartman]