Обсуждаем контроллеры компании Atmel.
Ср дек 25, 2019 20:27:06
я там обнаружил ошибки при составлении кода для форума.
исправил ошибки и изменил предыдущий пост.
Чт дек 26, 2019 11:52:32
Формировать временные интервалы с точностью до такта таймера можно ещё и так.
Чт дек 26, 2019 13:14:44
твой пример работает, но совершенно оторван от реальной жизни.
во-первых, обычно в прерывании таймера требуется сделать определенную работу (что в моем алгоритме показано), а не просто анализировать ход выполнения задержки.
во-вторых, реальная программа никогда не спит, ожидая окончания задержки, а основной цикл выполняет достаточно немалый объем работы и не может тупо спать, ожидая окончания задержки.
вот только я не понял, почему ты обрезал таймер половиной его диапазона - числом 128.
режим СТС прекрасно справляется с полным объемом счета - загружаем 255 и получаем 256 тактов таймера.
Чт дек 26, 2019 14:17:35
Какой интервал будет сгенерирован, если твоему коду подсунуть
- Код:
.equ Td=73987 ;mks
Чт дек 26, 2019 18:51:33
ты невнимательно читал мой пост. я говорил о расширении до 16 бит.
но если моему коду сделать два дополнительных байта, то он справится до 16777215 микросекунд.
а твой код с принудительным обрезанием счета до 128 сможет сделать только 8388607 мкс.
Сб дек 28, 2019 11:25:37
твой код порочен. Формировать интервал, допустим, 259=256*1+3 мкс или 73987=256*289+3мкс он не в состоянии.
Поэтому всегда держу регистр сравнения в середине, т.е 128.
Формирование длинных интервалов с дискретностью 1 такт таймера? Пожалуйста. Почти неделя
Внутри архива есть пара картинок.
- Вложения
-
- TEST_M8.zip
- (41.58 KiB) Скачиваний: 231
Сб дек 28, 2019 19:43:46
а вот тут ты прав, я об этом не подумал.
теперь понятен смысл деления на 128.
3 микросекунды у меня может получиться, так как МК работает на частоте 8 МГц, а таймер тактируется 1 микросекундой.
но 1-2 микросекунды уже не получится, так как само прерывание потратит больше времени, загружая эти 3 микросекунды.
а что не год или на 100 лет? еще полно у тебя свободных регистров...
количество дополнительных регистров тут значения не имеет. достаточно было показать с одним дополнительным регистром для расширения таймера2 до 16 бит.
а кому сильно надо очень большие задержки, тот сам выберет нужное число регистров.
в моем, конкретном, случае само прерывание вычисляет очередное значение задержки. и у меня поэтому не получится подставить компилятору формулу с величиной задержки.
тогда придется делать дополнительные вычисления к новым значениям старшего и младшего байтов. тут надо подумать, как это сделать минимальным набором действий.
например, я получил некоторое числов регистрах R24 и R25. нужно его пересчитать и загрузить в регистры с именами delayL и delayH.
Добавлено after 1 hour 14 minutes 28 seconds:
akl, похоже, в твоем алгоритме тоже есть дефект.
а что получится у тебя, если потребуется задержка меньше 128, меньше одного "оборота"?
лично мне в моем проекте вполне может понадобиться меньше 128.
Вс дек 29, 2019 02:24:28
Картинка с интервалом 130мкс приведена в надежде показать, что программа имеет ограничение снизу. Не считаю это дефектом.
Понятно, что код показушный.
https://radiokot.ru/forum/viewtopic.php ... 5#p3711135 Здесь, например, один интервал фиксирован, другой вычисляется. Правда, задействованы аппаратные возможности периферии. Кстати, неплохой вариант для формирования коротких интервалов.
Вс дек 29, 2019 11:27:11
ну да, при ограничении интервала снизу это не является явным дефектом.
но пока внедрение твоей "технологии" я не стал делать.
чтобы остаться в пределах двух байтов (регистров) у меня тогда появится ограничение сверху.
если сейчас у меня максимум 65535, то при переходе на "обороты" по 128 у меня максимум снизится до 32767, то есть, в 2 раза. а добавлять еще один регистр у меня нет желания.
я посмотрел у себя в Протеусе - проход через загрузку младшего байта занимает 3 мкс. плюс вход и выход из прерывания даст еще 1 мкс. итого 4 мкс. то есть, 5 мкс отработаются без ошибки. я могу закрыть глаза, если интервал с младшим байтом, равным 1, отработается с ошибкой и будет больше примерно на 3 мкс. например, вместо 257 мкс получится примерно 260 мкс, это для меня в моем проекте не критично.
Вс дек 29, 2019 11:44:10
Давайте исходить из того, что способы получения временных интервалов зависят от ТЗ. Генераторы, точные интервалы, интерфейсы, где важна точность, интересны. Чей код порочен, не порочен - не суть. Мы не дети, чтобы письками меряться. Интересны способы. Нам самим, тем кто будет читать этот топик.
Все остальные случаи, когда требуются интервалы от нескольких единиц миллисекунд, как покалывает практика, очень редко требуют точности. В этом случае в ход идут программные таймеры. Опрос кнопок, обновление экрана, датчиков и так далее.
Вс дек 29, 2019 15:46:11
На счет обновления экрана (дин. индикация) я бы поспорил — тут хоть точность выдержки и не нужна, но нарушение стабильности (разная длительность периодов) сильно портит картинку.
Вс дек 29, 2019 18:31:34
На счет обновления экрана (дин. индикация) я бы поспорил — тут хоть точность выдержки и не нужна, но нарушение стабильности (разная длительность периодов) сильно портит картинку.
Пример. Динамическая индикация. Если взять проекты и проанализировать. То практически 100 процентов динамическая индикация обрабатывается в прервании. Конечно от проекта зависит, точнее, состав устройства. Но я как то раз из любопытства сделал динамическую индикацию в основном цикле. Эта задача была решена комплексным подходом. Во первых, я активно использую конечные автоматы. Во вторых, итерация основного цикла у меня с запасом выполняется за системный тик. 1 мс. Этот подход я применяю давно. Все процессы у меня раздроблены. За каждый проход каждая задача выполняет кусочек кода. В третьих, знание архитектуры МК, обвязки, всего проекта.
Возвращаемся к нашей теме, опрос кнопок, даже если будет разброс на 5-10 процентов, разницы не увидит никто. Обновление отображаемой информации на ЖКИ, пусть у нас обновление каждые 100-200 мс. Опять же, никто не увидит разброс дае ена 5-10 процентов.
Потому что это человеко интерфейсы. Я говорю о допустимом разбросе в человеко интерфейсах.
Пт янв 03, 2020 19:06:13
Что то совсем заклинило на простом вопросе.
Ссылка->по динамической индикации. Если мне необходимо инициализировать два таймера. Допустимо ли в настройках указать разные значения делителей частоты, как для одного, так и для другого? Или же у всех таймеров делитель один? Скажем так; для подсчета импульсов один таймер, для вывода значений с динамической индикацией другой? А то я тут по ссылке разместил код с динамической индикацией на таймере, а мне ещё кое что посчитать надо. Как то бы всё это объединить.
OK!
Последний раз редактировалось
Эйлер Леонард Пт янв 03, 2020 19:34:45, всего редактировалось 1 раз.
Пт янв 03, 2020 19:22:07
Эйлер Леонард писал(а):Допустимо ли в настройках указать разные значения делителей частоты, как для одного, так и для другого?
все таймеры в AVR
абсолютно независимы друг от друга (не считая последних новинок с системой "событий")
Пт янв 03, 2020 22:46:19
Эйлер Леонард писал(а):Допустимо ли в настройках указать разные значения делителей частоты, как для одного, так и для другого?
все таймеры в AVR
абсолютно независимы друг от друга (не считая последних новинок с системой "событий")
Так то оно так, но флажок предделителя у таймеров объединены. Парно. 8-битный и 16-битный, тини новые нужно смотреть конкретно. Я про сброс предделителя таймеров, чтобы начали считать с изначального состояния.
Сб янв 04, 2020 12:58:04
Прошу прощенья. Речь пока идет об одном конкретном МК - грызу
Attiny85. Конечно каждый МК имеет свои особенности. Заглянув в
iotn85.h Там;
Timer/Counter1 Compare Match 1A
Timer/Counter1 Compare Match B
Timer/Counter0 Compare Match A
Timer/Counter0 Compare Match B
А вот и делитель(prescaler)
#define TCCR0B _SFR_IO8(0x33)
Т.е. два восьмибитных таймера с общим прескалером. Разве так?
Сб янв 04, 2020 14:31:40
Т.е. два восьмибитных таймера с общим прескалером. Разве так?
Это для timer0, для timer1 смотрите TCCR1 (без B)
Сб янв 04, 2020 14:39:33
Смотреть вообще-то надо на структурную или функциональную схему, а не на дефайны. И читать даташит, а не комменты в исходниках
Сб янв 04, 2020 18:03:03
Вкурил! Да вот только с английским у меня не очень то. (только немецкий со словарем
). Однако встречал умную фразу "Есть намерение программировать контроллеры - забудь русский язык навсегда".
----
OK
Последний раз редактировалось
Эйлер Леонард Сб янв 04, 2020 23:13:07, всего редактировалось 1 раз.
Сб янв 04, 2020 21:39:26
Читайте даташите через переводчик, купите словари, пробуйте. Зашли на эту стезю, значит по другому никак. Не знаю, лень, инерция. Преодолевайте.
Добавлено after 59 seconds:
Предделители ищите в функциональных, структурных схемах даташитов.
Powered by phpBB © phpBB Group.
phpBB Mobile / SEO by Artodia.