Email: Password: Remember Me | Create Account (Free)

Back to Subject List

Old thread has been locked -- no new posts accepted in this thread
???
12/20/05 21:58
Modified:
  12/20/05 22:24

Read: times


 
#105622 - Yes, it will work, but check timing.
Responding to: ???'s previous message
Sarika R Shewale said:
In my project i am using rtc ds12887 & p89c51rd2.
if anybody who has used this rtc ds12887 can tell me whether this is a good option for interfacing with p89c51rd2 if not please suggest any other rtc with parallel communication.

thanks in anticipation.

Yes, it can work, although the determining factors here lie largely in the fundamental concepts and the data sheets for these two devices.

I will note that the DS12887's Intel mode interfaces nicely with 8051-based devices, so long as you don't mind its parallel interface (which it seems you don't). There is even an internal address latch, meaning that if you don't have other external memory-mapped devices on your bus without internal address latches, and aren't executing from external program store, you will be able to avoid the use of an external address latch (typically a 74xx373 or 74xx573).

Before going any further, be sure to perform a complete timing analysis prior to selecting your oscillator frequency and machine cycle time (6-clock vs. 12-clock). For example, according to the P89C51RD2 data sheet, the 'RD2, running at 20 MHz in 6-clock mode can produce a /RD pulse as short as 50 ns (tRLRH, page 58). According to the DS12887 data sheet, the '12887 requires a DS pulse of at least 150 ns (PWEL, page 3). Thus, the 'RD2, configured like this, will not operate your '12887 reliably. Note that the use of a highly standardized interface bus, like I2C, is an advantage here in that ensuring timing compatibility is simply a matter of determining whether the slave can accept the master's chosen clock frequency.

It just so happens to be holiday code clearance time here. So, you may wish to look at my minimal driver for the DS12887, written in C, (rtc.c, rtc.h) and intended for compilation under Keil C51. My implementation is a pretty simple interpretation of the data sheet, and its proper use assumes and requires that you are familiar with the device's data sheet (and what you need to do to initialize the device, etc.) This was used on a DS89C420, where it was necessary to manipulate the "stretch cycles" to generate '12887-compatible timing. The driver is "minimal" in that it only provides an interface to the bit-packed configuration registers. My intention was that simple tasks, like reading the time, be accomplished through ordinary external memory accesses in the calling code. That said, you must see the data sheet for important caveats, like avoiding reading the time while it is being updated.

To use my code, you will need to do a few things. You can either delete all my stretch-related preprocessor directives and macros, or you can readily render them ineffective as follows:
#define RTC_STRETCH 0
#define BASE_STRETCH 0
#define SET_STRETCH(NEW_STRETCH)
#define GET_STRETCH()
Then, somewhere, you need to define the base address for the RTC and offsets for the relevant registers. Remember, your DS12887 might not be located at x:0x0400:
#define RTCBASE 0x400
unsigned char  volatile xdata  SEC         _at_ RTCBASE;
unsigned char  volatile xdata  SEC_ALRM    _at_ RTCBASE +  1;
unsigned char  volatile xdata  MIN         _at_ RTCBASE +  2;
unsigned char  volatile xdata  MIN_ALRM    _at_ RTCBASE +  3;
unsigned char  volatile xdata  HR          _at_ RTCBASE +  4;
unsigned char  volatile xdata  HR_ALRM     _at_ RTCBASE +  5;
unsigned char  volatile xdata  WK_DAY      _at_ RTCBASE +  6;
unsigned char  volatile xdata  DAY         _at_ RTCBASE +  7;
unsigned char  volatile xdata  MON         _at_ RTCBASE +  8;
unsigned char  volatile xdata  YR          _at_ RTCBASE +  9;
unsigned char  volatile xdata  RTC_REG_A   _at_ RTCBASE + 10;
unsigned char  volatile xdata  RTC_REG_B   _at_ RTCBASE + 11;
unsigned char  volatile xdata  RTC_REG_C   _at_ RTCBASE + 12;
unsigned char  volatile xdata  RTC_REG_D   _at_ RTCBASE + 13;
You also need a little bit-twiddling macro, as it is used by the driver. It's largely just syntactic sugar:
#define BIT_RECONF(SRC, POS_MASK, NEW_VAL) SRC = \
  (SRC & ~POS_MASK) | (POS_MASK & NEW_VAL)
When all is said and done, and you have used the driver to initialize the '12887 to your liking, doing things like reading/writing the date and time become relatively intuitive.

For your own sanity, unless you can think of a great reason for doing so, I suggest you use binary format for the time rather than BCD. I really never understood why someone would want to keep time in an RTC stored in BCD format, unless their sole goal was to dump it out to a 7-segment display. I'm a firm believer in maintaining the cleanest and simplest data representation internally, and then applying conversions as necessary when required for a particular output device.

This should go without saying, but the code here worked for me, I provided it for your convenience without any guarantee of correctness or warranty/liability of any kind. Of course, you can also write an interface to your '12887 in 8051 assembly, or other language you choose and have tools for; the RTC will not be prejudiced against you because of your choice!

--Sasha Jevtic

List of 15 messages in thread
TopicAuthorDate
Real Time Clock            01/01/70 00:00      
   Programming            01/01/70 00:00      
   hardware            01/01/70 00:00      
      Requirements first, select device later            01/01/70 00:00      
   dont let see Erik see that            01/01/70 00:00      
      formal, perfect and so who cares, but            01/01/70 00:00      
   Philips, ST            01/01/70 00:00      
   I2C            01/01/70 00:00      
      Dallas DS12887A.            01/01/70 00:00      
   Interfacing RTC            01/01/70 00:00      
      Not I2C.            01/01/70 00:00      
   interfacing of ds12887rtc with p89c51rd            01/01/70 00:00      
      Yes, it will work, but check timing.            01/01/70 00:00      
   No problem, no objection, just curious            01/01/70 00:00      
      thanks            01/01/70 00:00      

Back to Subject List