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);
}