-
- Таймер считает без остановки, от нуля до 2^24, при совпадении с
регистром сравнения вырабатывается запрос на прерывание. Приоритет
таймера ниже, чем прерываний сетевого интерфейса. В обработчике
сети есть "взять время" - получаем точное набортное время,
вычисляется с использованием регистров таймера. Но возникает
ситуация, когда регистр счёта перешагнул значение регистра
сравнения, но само значение регистра сравнения ещё не обновилось
(запрос на прерывание есть, но мы в Dingo(46 знак., 25.01.2023 13:26)
- Ну это да, такая ситуация возможна. Я повсеместно применяю аппаратный таймер для меток времени, и он переполняется довольно часто. Только прерывание не использую, гораздо проще делать так: SciFi(430 знак., 25.01.2023 13:36)
- Если запрос на прерывание таймера висит необработанным, значит текущее время нужно скорректировать на единичку, обычно так. - =AlexD=(25.01.2023 13:33)
- А автоматического сброса таймера по совпадению с регистром
сравнения нет? Если в битах порыться. По логике должно быть, иначе
оно всё время будет глючить. - =AlexD=(25.01.2023 13:31)
- Весь Timer Control and Status Register (TMR_CSR) Но может выйти ещё
хуже: событие произошло, а мы его пропустили. Dingo(1 знак., 25.01.2023 13:44, картинка)
- Вы Periodic mode, надеюсь, используете? - LightElf(25.01.2023 19:19)
- Конечно, нет. Все режимы кроме continous сбрасывают счёт таймера при записи
регистра сравнения. ETMR не смотрел в этом отношении. Dingo(439 знак., 26.01.2023 05:52)
- Чёт я не пойму изыска. Зачем обновлять регистр сравнения? Делаете
переменные задержки на том же таймер или что? - LightElf(26.01.2023 10:07)
- Период счёта не кратен секунде, да и нет двух одинаковых кварцев.
Например, у меня по результату вместо 12`000`000Гц оказался
12`000`126Гц. И это не точно: может в референсном устройстве тоже
не ровно, а подстраиваться к нему надо. Ну и опять же - ошибка всё
равно накопится, даже если разница будет в единицы Гц или даже
доли. Поэтому - постоянно подводить локальные часы. - Dingo(26.01.2023 10:13)
- Ну если вам нужна такая точность, что начинает существенную роль играть разброс кварцев, то вам прямая дорога в IEEE1588. Там и 64-битный таймер на 150МГц, и поправки дробные и синхронизация с мастером. - LightElf(26.01.2023 13:09)
- Я бы их в другом месте подводил. Зафиксировал бы таймер с периодом 12000000, чтобы в этом месте геморроя не было, а поправки вносил бы потом при помощи нехитрой арифметики. - SciFi(26.01.2023 10:17)
- Период счёта не кратен секунде, да и нет двух одинаковых кварцев.
Например, у меня по результату вместо 12`000`000Гц оказался
12`000`126Гц. И это не точно: может в референсном устройстве тоже
не ровно, а подстраиваться к нему надо. Ну и опять же - ошибка всё
равно накопится, даже если разница будет в единицы Гц или даже
доли. Поэтому - постоянно подводить локальные часы. - Dingo(26.01.2023 10:13)
- Чёт я не пойму изыска. Зачем обновлять регистр сравнения? Делаете
переменные задержки на том же таймер или что? - LightElf(26.01.2023 10:07)
- Конечно, нет. Все режимы кроме continous сбрасывают счёт таймера при записи
регистра сравнения. ETMR не смотрел в этом отношении. Dingo(439 знак., 26.01.2023 05:52)
- Вы Periodic mode, надеюсь, используете? - LightElf(25.01.2023 19:19)
- Весь Timer Control and Status Register (TMR_CSR) Но может выйти ещё
хуже: событие произошло, а мы его пропустили. Dingo(1 знак., 25.01.2023 13:44, картинка)
- Таймер считает без остановки, от нуля до 2^24, при совпадении с
регистром сравнения вырабатывается запрос на прерывание. Приоритет
таймера ниже, чем прерываний сетевого интерфейса. В обработчике
сети есть "взять время" - получаем точное набортное время,
вычисляется с использованием регистров таймера. Но возникает
ситуация, когда регистр счёта перешагнул значение регистра
сравнения, но само значение регистра сравнения ещё не обновилось
(запрос на прерывание есть, но мы в Dingo(46 знак., 25.01.2023 13:26)