твой пример работает, но совершенно оторван от реальной жизни.
во-первых, обычно в прерывании таймера требуется сделать определенную работу (что в моем алгоритме показано), а не просто анализировать ход выполнения задержки.
во-вторых, реальная программа никогда не спит, ожидая окончания задержки, а основной цикл выполняет достаточно немалый объем работы и не может тупо спать, ожидая окончания задержки.
вот только я не понял, почему ты обрезал таймер половиной его диапазона - числом 128.
режим СТС прекрасно справляется с полным объемом счета - загружаем 255 и получаем 256 тактов таймера.
Мудрость приходит вместе с импотенцией...
Когда на русском форуме переходят на Вы, в реальной жизни начинают бить морду.
ты невнимательно читал мой пост. я говорил о расширении до 16 бит.
но если моему коду сделать два дополнительных байта, то он справится до 16777215 микросекунд.
а твой код с принудительным обрезанием счета до 128 сможет сделать только 8388607 мкс.
Мудрость приходит вместе с импотенцией...
Когда на русском форуме переходят на Вы, в реальной жизни начинают бить морду.
твой код порочен. Формировать интервал, допустим, 259=256*1+3 мкс или 73987=256*289+3мкс он не в состоянии. Поэтому всегда держу регистр сравнения в середине, т.е 128.
Формирование длинных интервалов с дискретностью 1 такт таймера? Пожалуйста. Почти неделя Внутри архива есть пара картинок.
а вот тут ты прав, я об этом не подумал.
теперь понятен смысл деления на 128.
3 микросекунды у меня может получиться, так как МК работает на частоте 8 МГц, а таймер тактируется 1 микросекундой.
но 1-2 микросекунды уже не получится, так как само прерывание потратит больше времени, загружая эти 3 микросекунды.
а что не год или на 100 лет? еще полно у тебя свободных регистров...
количество дополнительных регистров тут значения не имеет. достаточно было показать с одним дополнительным регистром для расширения таймера2 до 16 бит.
а кому сильно надо очень большие задержки, тот сам выберет нужное число регистров.
в моем, конкретном, случае само прерывание вычисляет очередное значение задержки. и у меня поэтому не получится подставить компилятору формулу с величиной задержки.
тогда придется делать дополнительные вычисления к новым значениям старшего и младшего байтов. тут надо подумать, как это сделать минимальным набором действий.
например, я получил некоторое числов регистрах R24 и R25. нужно его пересчитать и загрузить в регистры с именами delayL и delayH.
Добавлено after 1 hour 14 minutes 28 seconds:
akl, похоже, в твоем алгоритме тоже есть дефект.
а что получится у тебя, если потребуется задержка меньше 128, меньше одного "оборота"?
лично мне в моем проекте вполне может понадобиться меньше 128.
Мудрость приходит вместе с импотенцией...
Когда на русском форуме переходят на Вы, в реальной жизни начинают бить морду.
Картинка с интервалом 130мкс приведена в надежде показать, что программа имеет ограничение снизу. Не считаю это дефектом.
Понятно, что код показушный. https://radiokot.ru/forum/viewtopic.php ... 5#p3711135 Здесь, например, один интервал фиксирован, другой вычисляется. Правда, задействованы аппаратные возможности периферии. Кстати, неплохой вариант для формирования коротких интервалов.
ну да, при ограничении интервала снизу это не является явным дефектом.
но пока внедрение твоей "технологии" я не стал делать.
чтобы остаться в пределах двух байтов (регистров) у меня тогда появится ограничение сверху.
если сейчас у меня максимум 65535, то при переходе на "обороты" по 128 у меня максимум снизится до 32767, то есть, в 2 раза. а добавлять еще один регистр у меня нет желания.
я посмотрел у себя в Протеусе - проход через загрузку младшего байта занимает 3 мкс. плюс вход и выход из прерывания даст еще 1 мкс. итого 4 мкс. то есть, 5 мкс отработаются без ошибки. я могу закрыть глаза, если интервал с младшим байтом, равным 1, отработается с ошибкой и будет больше примерно на 3 мкс. например, вместо 257 мкс получится примерно 260 мкс, это для меня в моем проекте не критично.
Мудрость приходит вместе с импотенцией...
Когда на русском форуме переходят на Вы, в реальной жизни начинают бить морду.
Давайте исходить из того, что способы получения временных интервалов зависят от ТЗ. Генераторы, точные интервалы, интерфейсы, где важна точность, интересны. Чей код порочен, не порочен - не суть. Мы не дети, чтобы письками меряться. Интересны способы. Нам самим, тем кто будет читать этот топик.
Все остальные случаи, когда требуются интервалы от нескольких единиц миллисекунд, как покалывает практика, очень редко требуют точности. В этом случае в ход идут программные таймеры. Опрос кнопок, обновление экрана, датчиков и так далее.
На счет обновления экрана (дин. индикация) я бы поспорил — тут хоть точность выдержки и не нужна, но нарушение стабильности (разная длительность периодов) сильно портит картинку.
Для тех, кто не учил магию мир полон физики
Безграмотно вопрошающим про силовую или высоковольтную электронику я не отвечаю, а то ещё посадят за участие в (само)убиении оболтуса...
[uquote="Ivanoff-iv",url="/forum/viewtopic.php?p=3765160#p3765160"]На счет обновления экрана (дин. индикация) я бы поспорил — тут хоть точность выдержки и не нужна, но нарушение стабильности (разная длительность периодов) сильно портит картинку.[/uquote]
Пример. Динамическая индикация. Если взять проекты и проанализировать. То практически 100 процентов динамическая индикация обрабатывается в прервании. Конечно от проекта зависит, точнее, состав устройства. Но я как то раз из любопытства сделал динамическую индикацию в основном цикле. Эта задача была решена комплексным подходом. Во первых, я активно использую конечные автоматы. Во вторых, итерация основного цикла у меня с запасом выполняется за системный тик. 1 мс. Этот подход я применяю давно. Все процессы у меня раздроблены. За каждый проход каждая задача выполняет кусочек кода. В третьих, знание архитектуры МК, обвязки, всего проекта.
Возвращаемся к нашей теме, опрос кнопок, даже если будет разброс на 5-10 процентов, разницы не увидит никто. Обновление отображаемой информации на ЖКИ, пусть у нас обновление каждые 100-200 мс. Опять же, никто не увидит разброс дае ена 5-10 процентов.
Потому что это человеко интерфейсы. Я говорю о допустимом разбросе в человеко интерфейсах.
Что то совсем заклинило на простом вопросе. Ссылка->по динамической индикации. Если мне необходимо инициализировать два таймера. Допустимо ли в настройках указать разные значения делителей частоты, как для одного, так и для другого? Или же у всех таймеров делитель один? Скажем так; для подсчета импульсов один таймер, для вывода значений с динамической индикацией другой? А то я тут по ссылке разместил код с динамической индикацией на таймере, а мне ещё кое что посчитать надо. Как то бы всё это объединить. OK!
Последний раз редактировалось Эйлер Леонард Пт янв 03, 2020 19:34:45, всего редактировалось 1 раз.
Эйлер Леонард писал(а):Допустимо ли в настройках указать разные значения делителей частоты, как для одного, так и для другого?
все таймеры в AVR абсолютно независимы друг от друга (не считая последних новинок с системой "событий")[/uquote]
Так то оно так, но флажок предделителя у таймеров объединены. Парно. 8-битный и 16-битный, тини новые нужно смотреть конкретно. Я про сброс предделителя таймеров, чтобы начали считать с изначального состояния.
Вкурил! Да вот только с английским у меня не очень то. (только немецкий со словарем ). Однако встречал умную фразу "Есть намерение программировать контроллеры - забудь русский язык навсегда".
----
OK
Последний раз редактировалось Эйлер Леонард Сб янв 04, 2020 23:13:07, всего редактировалось 1 раз.
Поэтому всегда держу регистр сравнения в середине, т.е 128.
Внутри архива есть пара картинок.
). Однако встречал умную фразу "Есть намерение программировать контроллеры - забудь русский язык навсегда".