[zheka 1]

Господа, проблемка возникла. Часы на DS1307, общаются с контроллером ATMega644p. Пока устройство работает или пока оно выключено - все ОК, часы вроде бы не отстают. Стоит подряд несколько раз перезагрузить контроллер - накапливается ощутимое отставание - на каждую перезагрузку около 0.5 сек.

 

Вот как у меня инициализируются часики:

 #asm
        .equ __i2c_port=0x08
        .equ __sda_bit=1
        .equ __scl_bit=0
    #endasm
   #include <i2c.h>
    #include <ds1307.h>

//////////////////

void main()
{
rtc_init(0,1,0);
DS_R=rtc_read(0); //прочесть нулевой байт
rtc_write(0,(DS_R&=0b01111111)); //обнулить старший бит(CH) запустить внутренний генератор 
//rtc_set_date(01,04,11);
//rtc_set_time(17,12,30);
rtc_get_date(pDate,pMonth,pYear);
rtc_get_time(pHour,pMinute,pSecond);

blablabla
}

 

ПОдчеркну - отставание происходит даже без обесточивания контроллера и перехода часов на батарейное питание, но и просто при перезагрузке. Насколько я догадываюсь, все эти перезагрузки и потрясения для контроллера должны быть по барабану часам, их можно сбить с пути истинного только командами от контроллера.

 

Вот я и думаю: DS_R=rtc_read(0); //прочесть нулевой байт rtc_write(0,(DS_R&=0b01111111)); //обнулить старший бит(CH) запустить внутренний генератор - не в этих ли командах причина, не они ли притормаживают часы? Как избежать отставания, ведь устройсто просто необходимо включать и выключать?

 

 

 

 

 

[TVF 0]

просто проверять состояние бита CH: если 0, часы идут и не трогаем, если 1 - пишем 0

[rezident 0]

Вот я и думаю: DS_R=rtc_read(0); //прочесть нулевой байт rtc_write(0,(DS_R&=0b01111111)); //обнулить старший бит(CH) запустить внутренний генератор - не в этих ли командах причина,

А зачем каждый раз сбрасывать этот бит? Его нужно сбрасывать только, если он установлен. Если же он устанавливается при каждом старте, то значит у вас часы останавливаются, что не есть нормальная работа их. ИМХО причину этого нужно искать в питании(ях) RTC.

[aaarrr 69]

не в этих ли командах причина, не они ли притормаживают часы?

В них, конечно: хоть секунды и переписываются тем же значением, но счетчик-то сбрасывается. В зависимости от везения, на каждой такой операции можно получить отставание до 1 сек, в среднем - 0.5.

[zheka 1]

rezident

ИМХО причину этого нужно искать в питании(ях) RTC.

 

Задержка происходит, как я писал выше, при ресете контроллера, в данном конкретном случае - по переполнении сторожевого таймера. С питанием RTC ничего не происходит, они продолжают питаться от основного источника, к слову - есть ведь еще и батарейка. Никаких просадок нет, никакая периферия, жрущая куда больше часов, не страдает, так что я сомневаюсь что дело в питании. Скорее всего действительно проблема с битом. Попробуем...

[zheka 1]

Сделал проверку бита. Часы перестали отставать. Всем большое спасибо!

[firstvald 24]

А посмотрите, как устроено ваше питание. Если у вас процессор с часами отвязан каким -нибудь импульсным преобразователем от остальной части устройства, то надо бы землю процессорной и часовой части соединить с остальным устройством резистором в килоом так 500 или конденсатором. У меня было что-то похожее с этими часами, случайно напал на вот такую причину.

[zheka 1]

firstvald, спасибо за совет, но сдается мне, что этот способ решения проблемы похож на подпиливание ножек у стула с целью их выровнять. В даташте ничего не сказано про резистор. Да не спорю, может быть какие-то помехи этот резистор и загасил, но часики были поставлены несколько, пардон, раком.

В любом случае, у меня все работатет. Пока что прошло 8 часов - полет нормальный, часы отстали от компьютера на какую-то долю секунды, доля это явно меньше 1/2 секунды. Да и то - я ведь не с эталоном сравниваю.

[zheka 1]

часики проработали полгода. А дальше появились странные симптомы.

Не идут. Время программируется, сохраняется. На выходе SQW настроен на импульсы 1 Гц. Но импульсов нет.

Обращает на себя внимание интересная вещь - на старте всегда, даже если вынуть батарейку и снова ее вставить нулевой байт равен 0b01111111, хотя, по идее при сбросе он должен быть весь в единицах.

Может ли кварц быть этому причиной? Или что-то с чипом?

[Сергей Борщ 140]

Может ли кварц быть этому причиной? Или что-то с чипом?

А попробуйте просто хорошенько промыть плату спиртом. Можно предположить, что остатки флюса в районе цепей кварца насосали влагу и начали проводить. Может и кварц виноват, а может конденсаторы в его обвязке уплыли (хотя маловероятно).

 

[zheka 1]

В общем, проблема решилась неожиданно.

Как оказалось, я слишком "лениво" читал нулевой бит:

if (DS_R ==1) rtc_write(0,(DS_R&=0b01111111)); //обнулить старший бит(CH) запустить внутренний генератор

 

то есть DS_R==1 было истинно если все семь битов кроме старшего равнялись единице. Не знаю, что эти биты означают, код взял откуда-то и почему-то он работал. Сейчас эти семь бит по другому почему-то читаются и DS_R никогда не равно единице.

 

Сделал так:

if (DS_R&0x80 !=0) rtc_write(0,(DS_R&=0b01111111)); //обнулить старший бит(CH) запустить внутренний генератор

 

И сейчас у меня на кварце свежие капли даже не высохшего флюса - полет нормальный, за 4 часа никаких видимых сдвигов.

Пойду смывать флюс.