Итак, я просматриваю эту прекрасную книгу Patterns for Time-Triggered Embedded Systems и задаюсь вопросом, касающимся точного расчета значений для аппаратных таймеров. См. шаблон «Аппаратная задержка» в приведенной выше книге.
Насколько я понимаю, «источник часов» (также известный как «Системные часы») генерирует устойчивую серию тиков (скажем, f1 кГц), которые затем подаются через блок «Предделитель», который делит их (с коэффициентом n, который может быть 1 ), задавая другую частоту (скажем, f2=f1/n кГц), которая затем подается на процессор. Таким образом, «Часы процессора» имеют частоту f2 и период времени t2=1/f2 мс. Чтобы рассчитать точный временной интервал (например, таймер 100 мс), мы просто вычисляем количество тактов в 100 мс, например 100/t2 = f3 «такты процессора». Поэтому нам нужно настроить соответствующие регистры таймера на значения, соответствующие f3, чтобы генерировать тик 100 мс.
Однако это не кажется таким простым (по крайней мере, для 8051) из-за количества тактов, необходимых для «цикла команд процессора». Процессор проходит свой цикл инструкций, т.е. «Выборка->Декодирование->Выполнение->Прерывание» (прерывания проверяются в конце текущей инструкции), который занимает серию тактов. В идеале весь цикл инструкций должен занимать всего 1 тик (например, конвейерный процессор), поэтому я могу использовать приведенный выше расчет для настройки таймеров. Однако, по-видимому, в оригинальном 8051 системные часы работали на частоте 12 МГц, и каждый цикл команд занимал 12 тактов. Так как прерывания проверяются только в конце командного цикла, теперь нам нужно дальнейшее деление на 12, чтобы получить правильный такт часов «таймера», то есть «такты процессора»/12, т.е. f2/12.
Верно ли мое понимание выше? Если это правда, как я могу рассчитать точное время, когда инструкции могут иметь разные такты цикла (например, смешанные 32- и 16-битные инструкции). Также нужно ли увеличивать таймеры с помощью цикла команд процессора или есть ли в HW способ увеличить регистр таймера строго синхронно с выходом блока «Предделитель»?
Короткий ответ тогда: «Это зависит». Различные семейства процессоров будут использовать разные подходы. Не существует одной идеи, подходящей для всех микро-ответов. Кроме того, синхронные прерывания (генерируемые внутренним оборудованием, синхронизированным с некоторыми внутренними часами) могут быть подтверждены более предсказуемо и иначе, чем асинхронные события (внешние по отношению к микропроцессору).
Расчет точного времени также будет зависеть от процессора. Даже если происходит событие (соответствие счетчика таймера, внешнее и т. д.), если ваш процессор занят выполнением инструкции в течение нескольких циклов, то обычно он не прерывает выполнение инструкции для запуска процедуры прерывания. (Но некоторые процессоры БУДУТ прерывать НЕКОТОРЫЕ инструкции, хотя я только что сказал, что они обычно этого не делают. Так что даже это не истина, и вам нужно прочитать техническое описание и руководства по семейству, чтобы быть уверенным.) Хуже, даже если процессор выполняет инструкции одного цикла, может быть некоторая изменчивость в ответе на прерывание. Таким образом, вы можете найти документы, говорящие, например, «на 5–6 циклов позже». Так что даже тогда вы не совсем уверены.
С другой стороны, некоторые процессоры предсказуемы, как атомные часы. Процессор Analog Devices ADSP-21xx (один цикл для КАЖДОГО командного слова, некоторые из которых могут выполнять три инструкции параллельно) ВСЕГДА имеет точно такое же время реакции прерывания каждый раз на событие таймера. По нему можно почти настроить атомные часы. Никакой вариации, вообще. Только чистые, идеальные, предсказуемые ответы. Каждый раз.
Но это редкость.
И если у вашего процессора хороший, длинный конвейер, вам, возможно, придется подождать, пока он «иссякнет». Это сделано для того, чтобы не приходилось восстанавливать много внутреннего состояния, перезапуская несколько инструкций на разных этапах выполнения.
Но даже тогда бывают исключения. DEC Alpha может потребоваться несколько тактов только для того, чтобы добраться до вашей процедуры прерывания. Но когда это произойдет, у него, вероятно, будет несколько инструкций в разных состояниях в разных конвейерах — все они просто сидят там, ожидая продолжения. Ваш код прерывания должен будет сохранить все это состояние, сделать свое дело, восстановить это состояние, а затем перезапустить... со всеми конвейерами, вернувшимися туда, где они были при прерывании. Код прерывания, если ему нужно отследить и найти инструкцию с ошибкой, БОЛЕЗНЕН писать. Но эта штука закричала. Они даже не будут менять дорожку для выбора байта, потому что это добавит комбинаторную задержку, которая снизит тактовую частоту.
Итак, это редкость. Но да, даже это может случиться.
ТАК...... ПРОЧИТАЙТЕ ТЕХНИЧЕСКОЕ ОПИСАНИЕ И РУКОВОДСТВО ПО СЕМЕЙСТВУ. И быть готовым ко всему вообще. Иногда дизайнеры могут быть ОЧЕНЬ ТВОРЧЕСКИМИ.
пользователь110971
РаманатанР
пользователь110971