Синхронизация времени МК

Соответственно, как я себе представляю процесс синхронизации: МК обрабатывает приходящие по CAN пакеты в прерывании, помещая их в очередь, но реагируя на особые команды сразу же. Особые команды - это запрос текущего времени (отправляем в шину значение счетчика секунд и регистра CNT - как раз в 8 байт стандартной посылки влезаем) и установка нового времени (сразу меняем значение счетчика и CNT на новые + сменяем на эти значения переменнуы "время последней синхронизации" + CNT последней синхронизации). Команды, которые "могут подождать" - отправка последнего времени синхронизации, отправка текущих значений PSC и ARR, а также прием их новых значений (которые по некоему алгоритму вычислит компьютер). Вот с алгоритмом-то и загвоздка.
Я вижу алгоритм так: сначала запрашиваем у МК текущие значения PSC/ARR, а также время и CNT последней синхронизации. Затем отправляем на МК последовательно раз 20-50 команду запроса текущего времени. Каждый раз запоминаем время отправки запроса и приема ответа, отнимаем от времени получения ответа половину длины промежутка - получаем условное время на МК, приведенное к задержке в отправке - что нам в принципе и надо. На каждом шаге вычисляем дельту. Затем считаем медиану - она и будет искомой поправкой. По времени последней синхронизации и полученной поправке вычисляем наиболее близкие PSC и ARR. А затем отправляем на МК команду установки нового времени и настройки "часового" таймера.
Как думаете, сработает такой алгоритм?
P.S. Желаемая точность передачи временных меток — ±0.5мс. И, соответственно, уход часов после ряда синхронизаций хотелось бы иметь в пределах 1мс в сутки (11.6 миллиардных). Хотя, в принципе, синхронизацию можно хоть 1 раз в час делать… Все-таки, кварц без термостабилизации на 10℃ изменения температуры выдает нестабильность аж в 10ppm!
|
</> |