W dniu 2014-11-12 20:07, Marek pisze:

> Ale poczekaj, sprawdż najpierw czy lokalnie czas (bez ntp) w miarę
> precyzyjnie odliczasz (max rozjazd kilkanascie sek. na dobę).

To już wiem. Domyślnie synchronizacje zegara są wykonywane co godzinę. W
tej chwili mam 26 sekund opóźnienia po 18 minutach od uruchomienia układu...


> Twoje przerwanie wygląda ok, nie powinno wprowadzać błędu o ile nie
> ma innych przerwań blokujące to od timera.

W tym programie nie występują żadne inne przerwania. Drugi,
szesnastobitowy timer pracuje w trybie licznika, nie wywołując żadnych
przerwań.


> No i oczywiście timer musi biegać podczas obsługi przerwania, aby
> czas jego obsługi nie dodawał się do biegu timera. Przerwanie jest
> krótkie, a 10ms interwał spokojnie powinien dać czas na jego
> obsługę.

W tej chwili dałem 20ms i wyrzuciłem mniej krytyczne instrukcje do pętli
głównej. Problem ciągle występuje.


> Atmega odkłada flagę przerwania gdy ono nastąpi po cli() aby je
> wywoływać zaraz po sei()?

Tego nie jestem pewien, ale z ciekawości zrezygnowałem ze stosowania
cli() i sei() przy odczycie/zapisie zmiennej rtc. Chciałem zobaczyć czy
dryf będzie nadal występował. Występuje...


> Jeśli czas lokalny będzie liczony ok to wtedy weryfikuj kod
> synchronizujący czas ntp.

Nie jest liczony ok, jednak tej synchronizacji też nie jestem pewien.
Kilka razy zauważyłem, że skrypt pokazywał nawet kilkanaście sekund
opóźnienia (albo i więcej) tuż po starcie urządzenia albo wymuszonej
synchronizacji.