??? 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 |
Topic | Author | Date |
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 |