ВходНаше всё Теги codebook 无线电组件 Поиск Опросы Закон Вторник
3 декабря
1371482
Eddy_Em (13.11.2023 21:47, просмотров: 10845)
Синхронизация времени МК. 

Что-то поисковики как на русском, так и на английском выдают какую-то чушь. Я же думаю сделать нечто вроде NTP по CAN'у. Т.к. никакие мои железки в 22 веке работать не будут, можно не париться и хранить UNIX time в 32-битном счетчике.

Соответственно, как я себе представляю процесс синхронизации: МК обрабатывает приходящие по CAN пакеты в прерывании, помещая их в очередь, но реагируя на особые команды сразу же. Особые команды - это запрос текущего времени (отправляем в шину значение счетчика секунд и регистра CNT - как раз в 8 байт стандартной посылки влезаем) и установка нового времени (сразу меняем значение счетчика и CNT на новые + сменяем на эти значения переменнуы "время последней синхронизации" + CNT последней синхронизации). Команды, которые "могут подождать" - отправка последнего времени синхронизации, отправка текущих значений PSC и ARR, а также прием их новых значений (которые по некоему алгоритму вычислит компьютер). Вот с алгоритмом-то и загвоздка.

Я вижу алгоритм так: сначала запрашиваем у МК текущие значения PSC/ARR, а также время и CNT последней синхронизации. Затем отправляем на МК последовательно раз 20-50 команду запроса текущего времени. Каждый раз запоминаем время отправки запроса и приема ответа, отнимаем от времени получения ответа половину длины промежутка - получаем условное время на МК, приведенное к задержке в отправке - что нам в принципе и надо. На каждом шаге вычисляем дельту. Затем считаем медиану - она и будет искомой поправкой. По времени последней синхронизации и полученной поправке вычисляем наиболее близкие PSC и ARR. А затем отправляем на МК команду установки нового времени и настройки "часового" таймера.

Как думаете, сработает такой алгоритм?

eddy-em.livejournal.com github.com/eddyem