Какой именно таймер — 16 бит или 8 бит зависит от камня. У меги 328 8-ми битный таймер 2. Большие меги на часы использовать конечно можно, но это дело личных пристрастий, я бы не стал.
А вот самое главное что обработчики прерывания часового таймера отрабатываются на тактовой частоте задающего генератора, а не на основной частоте, т.е. на часовом кварце. И при его низкой частоте он загнётся при срабатывании 100 раз в секунду.
N сотых долей секунды… Этож каким кварцем вы предлагаете тактировать таймер? В AVR он 8-ми битный, тут подходит только стандартный 32768 Гц-овый часовой кварц, не сможет он отрабатывать прерывания так часто.
Класс! Расскажте пожалуйста подробней техпроцесс изготовления цифр. Чем режете оргстекло? Как потом шлифуете края? Как полируете? Как выфрезеровывали цифры?
Обработка часового прерывания будет не в момент отсчёта времени, а позже. Статистически скажем за час будет одинаковое число обработок, только сам момент срабатывания будет гулять.
Это если предположить что нет обработчика какого-то любого прерывания, отрабатывающего медленнее, чем частота часового таймера. В этом случае будут пропуски.
Не согласен. Вы можете пропустить событие прерывания если у вас их несколько (от разных источников). Флажок-то будет выставлен, только он может быть несколько раз выставлен.
Да вот нет, чтобы точно работало нужно засыпать постоянно камнем. Часовые прерывания там тактуются отдельно по частоте часового кварца и пока на них переключится камень тоже проходит время. Всеми тонкостями я ещё не владею.
При входе в прерывание флаг Global Interrupt Enable автоматически сбрасывается, запрещая дальнейшие прерывания. Если он будет явно установлен в программе обработки прерывания, то новый запрос с наивысшим приоритетом прервет текущий обработчик. Приоритет прерывания уже запущенного обработчика при этом не имеет значения: если одновременно выставлены запросы INT0 и INT1 и оба они разрешены, начнет обрабатываться INT0; если далее в обработчике INT0 будет установлен флаг Global Interrupt Enable, то текущий обработчик будет вытеснен обработчиком INT1, а по его завершении будет продолжен (если кто-то еще снова не вытеснит).
Точно так же уже запущенный обработчик INT1 будет прерван более приоритетным INT0 лишь в том случае, если сам установит Global Interrupt Enable. Приоритет важен лишь в момент выбора одного прерывания из нескольких одновременных запросов.
Есть еще одна тонкость: если в данный момент обрабатывается прерывание, а другой запрос уже ожидает своей очереди, то после завершения текущего обработчика производится возврат в прерванную программу, выполняется одна инструкция, и лишь затем запускается новый обработчик. Эту задержку следует учитывать, если время реакции на прерывание очень критично.
Если прерываний много и МК находится в другом прерывании (а там обычно ставят запрет прерываний) то прерывания от таймера не будет. Я вот это имел ввиду. То есть будут пропуски отсчёта времени.
Если же прерывание одно, то и тут будут сдвиги — из-за многотактовых команд. Т.е. сначала довыполняется текущая команда, потом уже прерывание, а не сразу.
А насчёт RTC — внутрениий таймер по моему опыту (небольшому) использовать получается очень криво. Из-за обилия других прерываний он очень сильно уходит. Поэтому думаю что внешние RTC очень даж верное решение.
А вот самое главное что обработчики прерывания часового таймера отрабатываются на тактовой частоте задающего генератора, а не на основной частоте, т.е. на часовом кварце. И при его низкой частоте он загнётся при срабатывании 100 раз в секунду.
Счётчик милисекунд как будет инкрементироваться? Не по прерываниям от таймера?
Это если предположить что нет обработчика какого-то любого прерывания, отрабатывающего медленнее, чем частота часового таймера. В этом случае будут пропуски.
ОК.
При входе в прерывание флаг Global Interrupt Enable автоматически сбрасывается, запрещая дальнейшие прерывания. Если он будет явно установлен в программе обработки прерывания, то новый запрос с наивысшим приоритетом прервет текущий обработчик. Приоритет прерывания уже запущенного обработчика при этом не имеет значения: если одновременно выставлены запросы INT0 и INT1 и оба они разрешены, начнет обрабатываться INT0; если далее в обработчике INT0 будет установлен флаг Global Interrupt Enable, то текущий обработчик будет вытеснен обработчиком INT1, а по его завершении будет продолжен (если кто-то еще снова не вытеснит).
Точно так же уже запущенный обработчик INT1 будет прерван более приоритетным INT0 лишь в том случае, если сам установит Global Interrupt Enable. Приоритет важен лишь в момент выбора одного прерывания из нескольких одновременных запросов.
Есть еще одна тонкость: если в данный момент обрабатывается прерывание, а другой запрос уже ожидает своей очереди, то после завершения текущего обработчика производится возврат в прерванную программу, выполняется одна инструкция, и лишь затем запускается новый обработчик. Эту задержку следует учитывать, если время реакции на прерывание очень критично.
Если же прерывание одно, то и тут будут сдвиги — из-за многотактовых команд. Т.е. сначала довыполняется текущая команда, потом уже прерывание, а не сразу.