![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Синхронизация времени МК
Что-то поисковики как на русском, так и на английском выдают какую-то чушь. Я же думаю сделать нечто вроде NTP по CAN'у. Т.к. никакие мои железки в 22 веке работать не будут, можно не париться и хранить UNIX time в 32-битном счетчике.
Соответственно, как я себе представляю процесс синхронизации: МК обрабатывает приходящие по CAN пакеты в прерывании, помещая их в очередь, но реагируя на особые команды сразу же. Особые команды - это запрос текущего времени (отправляем в шину значение счетчика секунд и регистра CNT - как раз в 8 байт стандартной посылки влезаем) и установка нового времени (сразу меняем значение счетчика и CNT на новые + сменяем на эти значения переменнуы "время последней синхронизации" + CNT последней синхронизации). Команды, которые "могут подождать" - отправка последнего времени синхронизации, отправка текущих значений PSC и ARR, а также прием их новых значений (которые по некоему алгоритму вычислит компьютер). Вот с алгоритмом-то и загвоздка.
Я вижу алгоритм так: сначала запрашиваем у МК текущие значения PSC/ARR, а также время и CNT последней синхронизации. Затем отправляем на МК последовательно раз 20-50 команду запроса текущего времени. Каждый раз запоминаем время отправки запроса и приема ответа, отнимаем от времени получения ответа половину длины промежутка - получаем условное время на МК, приведенное к задержке в отправке - что нам в принципе и надо. На каждом шаге вычисляем дельту. Затем считаем медиану - она и будет искомой поправкой. По времени последней синхронизации и полученной поправке вычисляем наиболее близкие PSC и ARR. А затем отправляем на МК команду установки нового времени и настройки "часового" таймера.
Как думаете, сработает такой алгоритм?
Соответственно, как я себе представляю процесс синхронизации: МК обрабатывает приходящие по CAN пакеты в прерывании, помещая их в очередь, но реагируя на особые команды сразу же. Особые команды - это запрос текущего времени (отправляем в шину значение счетчика секунд и регистра CNT - как раз в 8 байт стандартной посылки влезаем) и установка нового времени (сразу меняем значение счетчика и CNT на новые + сменяем на эти значения переменнуы "время последней синхронизации" + CNT последней синхронизации). Команды, которые "могут подождать" - отправка последнего времени синхронизации, отправка текущих значений PSC и ARR, а также прием их новых значений (которые по некоему алгоритму вычислит компьютер). Вот с алгоритмом-то и загвоздка.
Я вижу алгоритм так: сначала запрашиваем у МК текущие значения PSC/ARR, а также время и CNT последней синхронизации. Затем отправляем на МК последовательно раз 20-50 команду запроса текущего времени. Каждый раз запоминаем время отправки запроса и приема ответа, отнимаем от времени получения ответа половину длины промежутка - получаем условное время на МК, приведенное к задержке в отправке - что нам в принципе и надо. На каждом шаге вычисляем дельту. Затем считаем медиану - она и будет искомой поправкой. По времени последней синхронизации и полученной поправке вычисляем наиболее близкие PSC и ARR. А затем отправляем на МК команду установки нового времени и настройки "часового" таймера.
Как думаете, сработает такой алгоритм?