AVR Freaks

Interesting.

In theory, reading a RTC should not affect the counter, but anything is possible....

eg If you say it was running faster, then maybe extra clock edges are being injected from the bus crosstalk.

Read should capture counters, but capture is not simple on ripple counters, as you need to be sure you do not capture while values overflow.

If you have access to a 1pps GPS system, you should be able to connect GSP-1pps and RTC 1pps, and report those two, and then vary a reading rate to see how that affects the two 1-second timings.

Capture of a time stamp would allow you to watch the exact phase of those 1pps, if the RTC does disturb, maybe it drops one or more 32khz edges to run slower as you report ?

It is true that rapidly reading an RTC should not cause timing errors.  Should not.  They should also latch all the time registers simultaneously at the very start of the read operation, so overflowing counters should be a non-problem.  While reading, the counters themselves continue to run, while the output data is held stable to read.

I'd like to add to 'Who-Me' in #21 who mentioned using a GPS time reference.  A Casio G-Shock is a perfectly good watch, but the atomic clocks of GPS are better.

Note that your cellphone probably uses GPS timekeeping, and if the phone doesn't, the phone network certainly does.  You won't be able to get sub-second precision, but averaged over a few hours should give useful results.

My other major suspicion would be a lousy 32kHz crystal.  If the chip has one built-in, like the DS3231, then it's a bum chip.  Note that even the best from the best vendors can still show up broken.  It's rare, but it happens.  They'll replace them if you can prove it.

S.

What's the old proverb? 'a watched kettle never boils'. Thus the solution is to stop reading the time from the device and it will work properly.

If you read it too fast, it might cause time dilation and a vortex to another dimension appears...... or i’ve been watching too much Regular Show.

sub-second checking would be possible with some timer-capture code in a small MCU - that would report the skew between GPS edges and RTC edges, and show the quanta of the errors.

( eg A missed Xtal edge, would change RTC dT by +30.517us )

Cool. Look forward to some independent tests. 

Ok,  I wrote a small sketch to run an an Arduino SMD clone.   Connect SQW pin to INT0 (digital #2).

I compared two Ebay DS1307 modules with my Ebay DS3231 module:

Compare DS3231 timing.   LED should toggle in ISR()
Thu 14 Dec 2017 01:39:11 PM
call I2C continuously for 300 secs
Elapsed time : 299985 ms,  288866 calls to read DS3231
Thu 14 Dec 2017 01:44:13 PM
do nothing for 300 secs
Elapsed time : 300002 ms
Thu 14 Dec 2017 01:49:15 PM.

Compare DS3231 timing.   LED should toggle in ISR()
Thu 14 Dec 2017 02:16:31 PM
call I2C continuously for 100 secs
Elapsed time : 99994 ms,  96287 calls to read DS3231
Thu 14 Dec 2017 02:18:13 PM
do nothing for 100 secs
Elapsed time : 100000 ms
Thu 14 Dec 2017 02:19:55 PM

Compare DS1307 timing.   LED should toggle in ISR()
Thu 14 Dec 2017 02:27:33 PM
call I2C continuously for 100 secs
Elapsed time : 99944 ms,  96265 calls to read DS1307
Thu 14 Dec 2017 02:29:15 PM
do nothing for 100 secs
Elapsed time : 99944 ms
Thu 14 Dec 2017 02:30:57 PM

Compare DS1307 timing.   LED should toggle in ISR()
Thu 14 Dec 2017 02:31:22 PM
call I2C continuously for 100 secs
Elapsed time : 99962 ms,  96282 calls to read DS1307
Thu 14 Dec 2017 02:33:04 PM
do nothing for 100 secs
Elapsed time : 99962 ms
Thu 14 Dec 2017 02:34:46 PM

You can see that the Arduino reports different times for each module.   The Arduino clone has an accurate 16mHz HF crystal.    Official UNOs have crap ceramic resonators.

In theory it should take 900us to read the RTC on a 100kHz bus.   The Arduino only manages 1038us with the Wire library.    The important point is that I have done 24 hours worth of RTC traffic with no noticeable difference.   

The SQW loop has a granularity of 1.04ms i.e. the read_DS3231() time.

The millis() has a granularity of 1-2ms.

So any difference of 5ms in 100000ms is acceptable.   The 300 second run shows a bigger difference i.e. 15ms

DS3231_busy.ino

#include <Wire.h>

const byte DS1307 = 0x68;
const byte DS3231 = 0x68;
const byte ledPin = 13;
const byte interruptPin = 2;
const int MAXSQW = 100;
volatile int16_t SQW_count;
volatile bool edge;
uint8_t hour, min, sec, wkday, day, mon, year;

char printbuf[80];
#define PRINTF(fmt ...)  { sprintf(printbuf, fmt); Serial.print(printbuf); }

// it is easy to use PCINTx instead of the Arduino's INT0
void init_pinchange(void)
{
    PORTC |= (1 << 3);       //pullup on PC3 (prevents floating)
    PCMSK1 = (1 << 3);       //monitor   PC3
    PCICR = (1 << PCIE1);    //enable IRQ
}

ISR(PCINT1_vect)                   //regular pin change on PC3
{
    if (PINC & (1 << PC3)) return; //ignore rising edge
    PORTB ^= (1 << 5);       //toggle LED
    SQW_count++;
    edge = true;
}

void sqw(void)                   //Arduino INT0 interrupt service call
{
    static uint8_t state;
    state = !state;
    digitalWrite(ledPin, state);
    SQW_count++;
    edge = true;
}

uint8_t write_reg_block(uint8_t slave, uint8_t reg, uint8_t *block, int8_t n)
{
    Wire.beginTransmission(slave);
    Wire.write(reg);
    Wire.write(block, n);
    return Wire.endTransmission();
}

uint8_t write_reg_val(uint8_t slave, uint8_t reg, uint8_t val)
{
    return write_reg_block(slave, reg, &val, 1);
}

void read_DS3231(uint8_t slave)
{
    Wire.beginTransmission(slave);
    Wire.write(0);
    Wire.endTransmission();
    Wire.requestFrom(slave, 7);  // request 7 bytes from slave device #2
    sec = Wire.read();
    min = Wire.read();
    hour = Wire.read();
    wkday = Wire.read();
    day = Wire.read();
    mon = Wire.read();
    year = Wire.read();
}

void show_time(void)
{
    char *daynm[] = {
        "Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat", "Sun"
    };
    char *month[] = {
        "bum", "Jan", "Feb", "Mar", "Apr", "May", "Jun",
        "Jul", "Aug", "Sep", "Oct", "Nov", "Dec"
    };
    read_DS3231(DS3231);
    uint8_t pmam = (hour & 0x60);   //weird 12 hour for Americans
    uint8_t hour12 = hour & ((pmam & 0x40) ? 0x1F : 0x3F);
    char *mode = (pmam & 0x40) ? (pmam & 0x20) ? "PM" : "AM" : "";
#if 1
    uint8_t idx = (mon >> 4) * 10 + (mon & 15);
    PRINTF("%s %02x %s 20%02x %02x:%02x:%02x %s\n",
           daynm[wkday - 1], day, month[idx], year, hour12, min, sec, mode);
#else
    PRINTF("%02x/%02x/20%02x %02x:%02x:%02x %s\n",
           day, mon, year, hour12, min, sec, mode);
#endif
}

void setup()
{
    //                       sec   min    hr wkday   day   mon  year
    uint8_t init_regs[] = { 0xD0, 0x47, 0x49, 0x05, 0x14, 0x12, 0x17, };
    int32_t read_count = 0;
    int32_t t;
    uint8_t status;
    Wire.begin();
    //    write_reg_block(DS3231, 0, init_regs, sizeof(init_regs));
    write_reg_val(DS1307, 0x07, 0x10);   //enable 1Hz SQW on DS1307
    status = write_reg_val(DS3231, 0x0E, 0x40);   //enable 1Hz SQW
    Serial.begin(9600);
    PRINTF("Compare DS3231 timing.   LED should toggle in ISR()\n");
    if (status != 0) {
        PRINTF("Failed to enable SQW:%d\n", status);
        while (1);
    }
    delay(1000);             //allow Serial to drain
    show_time();
    pinMode(ledPin, OUTPUT);       //LED
    pinMode(interruptPin, INPUT_PULLUP);
    attachInterrupt(digitalPinToInterrupt(interruptPin), sqw, FALLING);
    PRINTF("call I2C continuously for %d secs\n", MAXSQW);
    delay(1000);             //allow Serial to drain
    for (edge = false; edge == false; ) ; //wait till next SQW
    t = millis();

    for (SQW_count = 0; SQW_count < MAXSQW; read_count++) {
        //        if (PINC & (1<<PC3)) PORTB |= (1<<5); else PORTB &= ~(1<<5);
        read_DS3231(DS3231);     //continuous reads
    }
    t = millis() - t;  //elapsed time
    PRINTF("Elapsed time : %ld ms,  %ld calls to read DS3231\n", t, read_count);
    show_time();
    PRINTF("do nothing for %d secs\n", MAXSQW);
    delay(1000);             //allow Serial to drain
    for (edge = false; edge == false; ) ; //wait till next SQW
    t = millis();
    for (SQW_count = 0; SQW_count < MAXSQW; ) {
        //nuffink
    }
    t = millis() - t;  //elapsed time
    PRINTF("Elapsed time : %ld ms\n", t);
    show_time();
}

void loop()
{

}

I thought hard about whether an example should be written for Arduino or bare AVR.

I concluded that everyone has an Arduino.    It should build out of the box.

If I posted an AS7 project with separate UART, I2C, timing functions for any AVR,   punters would be unlikely to try it for themselves.

David.

p.s. Civilised people can change the 12/24 format bit in the hour register (reg=2).

Edit.   Changed read_count from int to int32_t.   This makes sense now

Edit.   Updated reads for DS1307 comparisons.   Changed my conclusion.

Good to see some numbers, but I did not see the reports for almost-no-readings ?

The 15ms in 300s is 50ppm, which is not great as drift, but with no A/B comparison, it may include absolute crystal ppm differences.

ie I'd expect a crystal to hold sub 10ppm in a short-term stable room, but out of the box, cheapest crystals sold are 50ppm, tho most give ±30ppm or ±20ppm, that does assume someone took the trouble to 'centre the caps' to remove circuit errors (few bother)

Yes, 30 minutes a day is very large, and seems due to 'some other effect', it may be cross talk, or voltage/power etc - that's why I suggest to the OP they connect a GPS 1 pps, and report/log the RTC-GPS time difference.

If they read in bursts then pause, such a log should show any difference effects due to the reading.

Just how much/how evenly the error jumps, should give good clues to just what is causing it.

The Arduino Xtal will also be temperature-sensitive.  Hammering the communication hardware will heat up the chip a bit more than doing nothing.  Real-Time Clock Chips are supposed to have compensation for temperature.  I don't think the Arduino does.  The difference will be small, but as Who-Me noted, we're talking tens of ppm here.  Not half an hour a day.  Something else is wrong with the OPs RTC.

Beats me!   And I don't have an Arduino either!  S.

No,   I can't see why any interrupts would ever get missed in the regular Arduino platform.

But when I was walking my dog,  I thought that I would produce a non-interrupt version for AS7.

############# AS7 100kHz #####################################

Compare DS3231 timing.   LED should toggle in ISR()
Thu 14 Dec 2017 09:07:01 PM
call I2C continuously for 100 secs
Elapsed time : 99994 ms,  104994 calls to read DS3231
Thu 14 Dec 2017 09:08:43 PM
do nothing for 100 secs
Elapsed time : 100001 ms
Thu 14 Dec 2017 09:10:25 PM

############# AS7 400kHz #####################################

Compare DS3231 timing.   LED should toggle in ISR()
Thu 14 Dec 2017 09:22:43 PM
call I2C continuously for 100 secs
Elapsed time : 99973 ms,  394010 calls to read DS3231
Thu 14 Dec 2017 09:24:25 PM
do nothing for 100 secs
Elapsed time : 100001 ms
Thu 14 Dec 2017 09:26:07 PM

I get a similar result.   Ok, the millis() work much the same as Arduino.  i.e. I don't sync them.   So there is still a 1-2ms granularity.

But I still get 6-7ms difference with DS3231.    The DS1307 gave identical times.

I get 28ms difference when I run the I2C bus at 400kHz achieving almost 4x activity.

The DS1307 will only go at 100kHz.   So there is no point in trying at 400kHz.

Yes,   I suppose that the CMOS in the DS3231 will heat up with the extra activity.   Which will warm up the integrated crystal.

The DS1307 silicon will equally warm up.   But the external crystal will not.   Likewise,  the UNO crystal is external.

If my heating theory is correct,   I should get different results if I do nothing before doing continuous.

David.

Hi Sergei,

I'd like to use your tool, but there is reference for RTCLib.h but this file (and cpp) are not inclued into zip. 

Or am I doing something wrong ?

THX

Dan

Thank Sergey for quick response !!

There is lots of RTC libraries for arduino, so you saved me some search time :-)

I have problem with my 3231 that it is off (slows) by 8 seconds on each hour.

Hope this fiz this problem.

Thank you again

Dan