Eksperymentowałem ostatnio z synchronizacją czasu w układzie z Atmegą i
ENC28J60. Użyłem gotowych funkcji zaimplementowanych w stosie
tuxgraphics.org, z niewielkimi modyfikacjami (głównie przeliczanie
odebranej wartości na Unix epoch.
Generalnie rozwiązanie jest bardzo proste. Programowy licznik odlicza w
dół liczbę sekund pomiędzy kolejnymi synchronizacjami (w tej chwili
3600). Gdy dojdzie do zera wysyłany jest pakiet z requestem.
Jednocześnie w momencie przyjścia pakietu UDP funkcja sprawdza, czy mamy
do czynienia z odpowiedzią - jeśli tak, to do zmiennej volatile int32_t
rtc ładowany jest odebrany czas.
Obliczanie wartości wygląda następująco:

*time = ( ( ((uint32_t)buf[0x52]<<24) | ((uint32_t)buf[0x53]<<16) |
((uint32_t)buf[0x54]<<8) | ((uint32_t)buf[0x55]) ) - 2208988800UL )

Pomiędzy synchronizacjami zegar jest inkrementowany w przerwaniu timera.
Przerwanie jest wywoływane co 1ms - normalnie zwiększana jest zmienna
pomocnicza, jednak w przypadku przekroczenia przez nią wartości 1000
uruchamia się obsługa zegara i kilku programowych liczników.

Program zdaje się działać prawidłowo, jednak byłem ciekaw na ile jest
dokładny. Napisałem prosty skrypt na Raspberry Pi, który odczytuje czas
z omawianego urządzenia i odejmuje go od czasu systemowego w RasPi.
Wyniki są dziwne. Nieraz mam kilka sekund różnicy, czasem jednak pojawia
się wynik w granicach 60 sekund. Niekiedy większą różnicę obserwuję tuż
po synchronizacji.

Nie wydaje mi się, żeby mogło to wynikać z niedokładności timera Atmegi
- niewielki dryf ie objawiłby się tak szybko. No chyba, że jeszcze zegar
w RasPi ma tak tragiczną stabilność.

Gdzie mogę szukać przyczyn takiego zachowania?

do góry

On Wed, 12 Nov 2014 01:35:22 +0100, Atlantis <m...@w...pl>
wrote:
> Nie wydaje mi się, żeby mogło to wynikać z niedokładności timera
Atmegi
> - niewielki dryf ie objawiłby się tak szybko. No chyba, że jeszcze
zegar
> w RasPi ma tak tragiczną stabilność.

Czy raspi ma synchroniziwany zegar? Bo nie rozumiem co mierzysz
teraz. Dokładność zegara w tym Twoim urządzeniu czy niedokładnośc
raspi?

--
Marek

do góry

W dniu 2014-11-12 o 01:35, Atlantis pisze:
> Eksperymentowałem ostatnio z synchronizacją czasu w układzie z Atmegą i
> ENC28J60.

A obsługujesz poprawnie zapis i odczyt wartości większych niż 8 bitów?
Wyłączenie/włączenie przerwań na czas zapisu i odczytu?
Tu bym zaczął, sprawdził bym też czy na pewno w obliczeniach używasz
zmiennych o odpowiedniej wielkości, czy są ze znakiem itd.

--
AWa.

do góry

W dniu 2014-11-12 09:12, Marek pisze:

> Czy raspi ma synchroniziwany zegar? Bo nie rozumiem co mierzysz teraz.
> Dokładność zegara w tym Twoim urządzeniu czy niedokładnośc raspi?

Musi mieć. RasPi w fabrycznej konfiguracji nie ma nawet RTC - czas brany
jest z NTP przy starcie systemu.

do góry

On Wed, 12 Nov 2014 09:45:37 +0100, Atlantis <m...@w...pl>
wrote:
> Musi mieć. RasPi w fabrycznej konfiguracji nie ma nawet RTC - czas
brany
> jest z NTP przy starcie systemu.

Ale co ile ta synch. później po starcie jest? Bo to normalne, że jak
będzie rzadko to się szybko rozjedzie (czas jest liczony bo zwykłym
przerwaniu timera), linux w raspi nie jest rt, przynajmniej w
najpupolarniejszych dtstrybucjach dla raspi. Badasz względem siebie
dwa niepewne urządzenia. Najpierw sprawdź to z encj wzgl. zaufanego
wzorca czasu, później raspi wzgl. tego wzorca, dopiero wtedy wyciągaj
wnioski.

--
Marek

do góry

W dniu 2014-11-12 10:36, Marek pisze:

> Ale co ile ta synch. później po starcie jest? Bo to normalne, że jak
> będzie rzadko to się szybko rozjedzie (czas jest liczony bo zwykłym
> przerwaniu timera), linux w raspi nie jest rt, przynajmniej w
> najpupolarniejszych dtstrybucjach dla raspi.

Zdaje sobie z tego sprawę. Jednak minuta dryfu na godzinę!?

do góry

W dniu 2014-11-12 09:45, Andrzej W. pisze:

> A obsługujesz poprawnie zapis i odczyt wartości większych niż 8 bitów?

Jak mam to rozumieć?


> Wyłączenie/włączenie przerwań na czas zapisu i odczytu?

Dodałem cli() i sei() w każdej partii kodu, gdzie pojawia się odwołanie
do zmiennej rtc. Nie wydaje mi się, żeby pomogło.


> Tu bym zaczął, sprawdził bym też czy na pewno w obliczeniach używasz
> zmiennych o odpowiedniej wielkości, czy są ze znakiem itd.

Zmienna rtc to volatile uint32_t.
Obliczanie jej wartości na podstawie informacji z pakietu (jak już
wspominałem) wygląda następująco:

*time = ( ( ((uint32_t)buf[0x52]<<24) | ((uint32_t)buf[0x53]<<16) |
((uint32_t)buf[0x54]<<8) | ((uint32_t)buf[0x55]) ) - 2208988800UL );

"time" to po prostu wskaźnik przekazujący wynik obliczeń wykonywanych
wewnątrz funkcji.

do góry

Hmm.... Wygląda na to, że Raspberry Pi pokazuje dokładnie ten sam czas,
który widać np. na epochconverter.com albo currenttimestamp.com.
To na układzie z Atmegą pojawia się jakaś dziwna różnica, wynosząca od
kilku do kilkudziesięciu sekund. Mam wrażenie, że nie narasta ona w
wyniku dryfu wprowadzanego przez timer - zwykle jest ona widoczna już po
aktualizacji czasu, którą mogę też inicjować ręcznie.

Kod funkcji analizującej pakiet NTP w tej chwili wygląda następująco:

uint8_t client_ntp_process_answer(uint8_t *buf, volatile uint32_t
*time,uint8_t dstport_l){

uint32_t tm_temp=0;

if (dstport_l){
if (buf[UDP_DST_PORT_L_P]!=dstport_l){
return(0);
}
}
if (buf[UDP_LEN_H_P]!=0 || buf[UDP_LEN_L_P]!=56 ||
buf[UDP_SRC_PORT_L_P]!=0x7b){
// not ntp
return(0);
}
// copy time from the transmit time stamp field:
tm_temp = ( ((uint32_t)buf[0x52]<<24) | ((uint32_t)buf[0x53]<<16) |
((uint32_t)buf[0x54]<<8) | ((uint32_t)buf[0x55]) );
tm_temp -= 2208988800UL;
cli();
*time = tm_temp;
//*time = ( ( ((uint32_t)buf[0x52]<<24) |
((uint32_t)buf[0x53]<<16) | ((uint32_t)buf[0x54]<<8) |
((uint32_t)buf[0x55]) ) - 2208988800UL ); //0x83AA7E80
sei();
return(1);
}

do góry

Użytkownik "Atlantis" napisał w wiadomości
W dniu 2014-11-12 10:36, Marek pisze:
>> Ale co ile ta synch. później po starcie jest? Bo to normalne, że
>> jak
>> będzie rzadko to się szybko rozjedzie (czas jest liczony bo zwykłym
>> przerwaniu timera), linux w raspi nie jest rt, przynajmniej w
>> najpupolarniejszych dtstrybucjach dla raspi.
>Zdaje sobie z tego sprawę. Jednak minuta dryfu na godzinę!?

Rozumiem ze czas tam jest mierzony przerwaniem programowym na
podstawie czestotliwosci zegarowej uP.
Jest jakis mechanizm ze to przerwanie jest rowno generowane, i nie
wplywa np na niego opoznienie jego obsluzenia ?

Czestotliwosc zegarowa - jesli kwarcem, to powinna byc w miare
dokladna. Tak powiedzmy do 100ppm, jesli dales byle jakie elementy.
Czyli sekunda na trzy godziny.
Ale jesli to nie kwarc, tylko jakis gorszy oscylator, to kto wie czy
nie 1% dokladnosci. Ale to powinienes widziec ze dryfuje a nie skacze.

Porownujesz z jakims innym urzadzeniem ... ale jakim ?
Moze tam jest numer ze np odczytujesz koncowke 59 sekund, a minuty juz
po zmianie ...

J.

do góry

W dniu 2014-11-12 o 12:10, Atlantis pisze:
> Hmm.... Wygląda na to, że Raspberry Pi pokazuje dokładnie ten sam czas,
> który widać np. na epochconverter.com albo currenttimestamp.com.
> To na układzie z Atmegą pojawia się jakaś dziwna różnica, wynosząca od
> kilku do kilkudziesięciu sekund. Mam wrażenie, że nie narasta ona w
> wyniku dryfu wprowadzanego przez timer - zwykle jest ona widoczna już po
> aktualizacji czasu, którą mogę też inicjować ręcznie.
>
> Kod funkcji analizującej pakiet NTP w tej chwili wygląda następująco:
>
> uint8_t client_ntp_process_answer(uint8_t *buf, volatile uint32_t
> *time,uint8_t dstport_l){
>
> uint32_t tm_temp=0;
>
> if (dstport_l){
> if (buf[UDP_DST_PORT_L_P]!=dstport_l){
> return(0);
> }
> }
> if (buf[UDP_LEN_H_P]!=0 || buf[UDP_LEN_L_P]!=56 ||
> buf[UDP_SRC_PORT_L_P]!=0x7b){
> // not ntp
> return(0);
> }
> // copy time from the transmit time stamp field:
> tm_temp = ( ((uint32_t)buf[0x52]<<24) | ((uint32_t)buf[0x53]<<16) |
> ((uint32_t)buf[0x54]<<8) | ((uint32_t)buf[0x55]) );
> tm_temp -= 2208988800UL;
> cli();
> *time = tm_temp;
> //*time = ( ( ((uint32_t)buf[0x52]<<24) |
> ((uint32_t)buf[0x53]<<16) | ((uint32_t)buf[0x54]<<8) |
> ((uint32_t)buf[0x55]) ) - 2208988800UL ); //0x83AA7E80
> sei();
> return(1);
> }
>


Ten kod to interpretuje każdy pakiet UDP co ma 56 bajtów, tak?
Żeby czytać właściwy pakiet warto sprawdzić czy odpowiedź zawiera
znacznik czasu wysłany przez Ciebie w zapytaniu. (RFC4330 Originate
Timestamp).
Ja u siebie czytam czas z pozycji [40:43], widzę, że Ty czytasz [82:85].
Ten bufor to "czyste" dane z pakietu UDP, czy jest tam też jakiś
nagłówek? Bo czytasz znacznie dalej niż długość pakietu UDP.


--
AWa.

do góry