Как принять сигнал с приемника в AVR (PWM|Digital)
Тут такое дело, если Вы оценили вероятность некоторого необработанного события, учли все явные и косвенные последствия, которое оно может вызвать, и что оно не приведет к каким-то фатальным событиям системы (типа деления на ноль, неожиданного ветвления с возможностью переполнения стека итд итп), то конечно можно его игнорировать. Но чаще гораздо проще рядом с полным стаканом поставить пустой из анекдота и быть уверенным, что все предусмотрено на случай если пить не захочется… 😃 Эта мысль не к Вашему конкретному коду, а в принципе, о “культуре” программирования… Типа даже шутка была, что в “хорошей” программе должно быть не меньше 50% кода на обработку ситуаций, которые не случаются никогда. 😃
Вариант “битых” пакетов и полного пропадания сигнала в программе стоит предусмотреть, а сам девайс после изготовления как следует погонять.
В жизни бывает всякое. Например, увлечетесь полетами в сумерках, сядет передатчик, а следом “погаснет” самолет. Обидно…
Тут такое дело, если Вы оценили вероятность некоторого необработанного события, учли все явные и косвенные последствия, которое оно может вызвать, и что оно не приведет к каким-то фатальным событиям системы (типа деления на ноль, неожиданного ветвления с возможностью переполнения стека итд итп), то конечно можно его игнорировать. Но чаще гораздо проще рядом с полным стаканом поставить пустой из анекдота и быть уверенным, что все предусмотрено на случай если пить не захочется… 😃 Эта мысль не к Вашему конкретному коду, а в принципе, о “культуре” программирования… Типа даже шутка была, что в “хорошей” программе должно быть не меньше 50% кода на обработку ситуаций, которые не случаются никогда. 😃
Согласен полностью!
Вариант “битых” пакетов и полного пропадания сигнала в программе стоит предусмотреть, а сам девайс после изготовления как следует погонять.
В жизни бывает всякое. Например, увлечетесь полетами в сумерках, сядет передатчик, а следом “погаснет” самолет. Обидно…
О, а вот над этим действительно надо поработать… как то ушло из виду такое поедение!
Здравствуйте! Тожа заинтересован в считывания сигнала PWM с помощью ATmega. Прерывания по rise/fall, расчет числа тиков, но ведет себя странно. С приемника/серво-тестера сигнал ни в какую не считывает (подтягивающий резистор и включал, и выключал). А вот если завести PWM-сигнал с меги, то все прекрасно считывается, да и при обычной коммутации на +5В тоже все работает. Может, кто подкинет идею, в чем причина такой ерунды? Заранее спасибо!
Уровень сигнала с сервотестера может быть мал. Если в нем стоит стабилизатор на 3,3 В, а на внешнем проце 5 В, то система может глючить. Нужно согласовать уровни сигналов, например через транзисторный каскад.
Или попробуйте завести сигнал с сервотестера на вход аналогового компаратора Меги, а второй вход компаратора кинуть на внутренний опорник. В этом случае амплитуды входного сигнала должно хватить.
Для начала напишите маленькую проверочную прогу, которая считывает состояние ноги к которой подключен сигнал и это же состояние выставляет на другой ноге. Соотв. у вас должен получиться программный “повторитель”. На вход подаете сигнал с сервотестера, на выход вешаете серву. Если все работает, значит все соединено правильно, все уровни совпадают и все подтяжки выставлены тоже правильно. Дальше уже можно писать код. Вместо сервы можно подключить резистор со светодиодом. Различие 1 мс импульсов от 2 мс импульсов видно на глаз (по изменению яркости).
Добрый вечер! Спасибо за советы! Внезапно разобрался во всем сам. Не тот порт заткнул, когда все прояснилось - цифры на LCD стали показывать правильные длительности импульса. Правда, при попытке выдать принятый PWM на выход (через 16-битный таймер, т.к. основная программа занята), серва дергается. Дискретизация по времени приема PWM с сервотестера - порядка 52мкс, если ставить больше, как писали - 2000 тиков таймера на 2мс, то на основную программу просто не остается тактов процессора. Вообще, все это нужно чтобы в полете в какой-то момент отобрать управление у приемника и заставить серву исполнять сигнал по программе процессора. Может, лучше поставить транзистор, который будет закрывать путь для прохода PWM-сигнала с приемника по команде процессора?
Может, лучше поставить транзистор, который будет закрывать путь для прохода PWM-сигнала с приемника по команде процессора?
Не проще запретить внешнее прерывание?
Коллеги, позвольте задать дилетантский вопрос:
сейчас встала необходимость принять на мегу сигнал с приемника, на этом канале висит несколько серв. Идея такая:
- Принимаем сигнал на ICP, меряем длительность импульса счетчиком.
- Значение длины полученного импульса программно корректируется, т.е. от него либо отнимается время, либо сколько-то прибавляется.
- формируется новый импульс заданной длинны на соответствующем PWM пине проца.
Таким образом имея 1 вход можно на него через проц повесить 2-3-4 серво в режиме секвенсора.
Вопрос собсно такой: принять и обсчитать импульс это не проблема, новый тоже сформировать нет, но насколько я понимаю пока проц будет “думать” над текущим обрабатываемым импульсом в это время на ICP будет тикать новый и его мега не успеет уже принять и обработать. Т.е. если я правильно понимаю как минимум будет запаздывание в 1 цикл ШИМ от приёмника. Можно как-то решить эту проблему или дело настолько серьезно, что напрашивается RTOS?
Для справки, JR matchbox выполняет именно такую ф-ию, но в руках не держал, не разбирал… Если я прав, то это в принципе можно реализовать на 2-3-4 независимых камнях типа тиньки25 или 13, у которой есть входы ICP.
Частота 4 МГц, камень ATMega32…пока. На нем отрабатываются узлы, потом все переезжает в 128ю.
Буду признателен за любые подсказки.С Уважением.
Маскимальная длительность пришедшего с приемника импульса - 2 миллисекунды. Такт поступления импульсов - 20 миллисекунд. Итого остается 18 милисекунд.
На последовательную генерацию трех импульсов (максимум те-же 2 миллисекунды каждый) уйдет 6 миллисекунд. Итого, на все расчетные удовольствия остается 12 миллисекунд.
Вторичные импульсы есс-но будут отставать от исходного, но все будут сгенерированы до прихода следующего импульса с приемника.
Благодарю!
Т.е. генерация новых “обсчитанных” импульсов идет в процессоре в фоновом режиме, в то время как проц обрабатывает новые входящие, правильно?
Извините за нескромность, у Вас часом нет этого куска кода? Мне хоть посмотреть в какую сторону бежать…😊
Камень - тини 13А, частота внутреннего RC-генератора 9,6 МГц. Импульс снимается в прямом цикле без прерываний с 4 входа порта В. После метки main10 в регистрах Delay находится разность между 2,2 мс и фактической длиной импульса. Импульс меряется тактами по 6 тиков в каждом. Принцип последующей генерации выходных импульсов после обсчета - такой-же.
=============================================
;********** переопределям регистры ***********************
.def Delay_L = R19 ; задержка (младший байт)
.def Delay_H = R20 ; задержка (старший байт)
…
;********* задаем константы (9,6 МГц, 6 тактов) **********
.equ VRRST = 3520 ; верхний порог (2,200 мс)
…
;********** обработка импульса ********************************
ldi Delay_L,Low(VRRST) ; начинаем обработку импульса
ldi Delay_H,High(VRRST); загружаем 2,2 мс в регистры задержки
pul_3: sbis PinB, 4
rjmp main10 ; выходим, если импульс закончился
subi Delay_L, 1
sbci Delay_H, 0
brcc pul_3
main10: …
=======================================
Сразу предупреждаю, что в плане ассемблера я “начинающий” программист.
Возможно кто-то из гуру расщедрится на более грамотное решение.
Спасибо! 😃
Ну, я “сишник”, за ассемблером к отцу пойду, он у меня спец по нему. В принципе всё понятно, попробую это на си портировать, но чувствуется без прерывания не обойтись.
Код делался под примитивную задачу, хотелось обойтись без прерываний.
Александр, а не поясните пжлст: что значит
Импульс снимается в прямом цикле
? Т.е. как я понимаю программа в бесконечном цикле (jmp loop) проверяет изменение сигнала на входе (1 или 0) и уже потом обрабатывает его?
Не проще запретить внешнее прерывание?
Такой способ не подойдет, задумал вообще не считывать PWM-сигнал с приемника. Сразу с приемника на сервопривод, а в нужный момент отобрать линию у приемника. Разве что ставить дополнительную микросхему и передавать тщательно вычисленную длительность через UART или еще как.
Сразу с приемника на сервопривод
отобрать линию у приемника
дополнительную микросхему и передавать тщательно вычисленную длительность через UART
это как??😃 В любом случае придется процессор в разрыв тогда ставить.
… как я понимаю программа в бесконечном цикле (jmp loop) проверяет изменение сигнала на входе (1 или 0) и уже потом обрабатывает его?
Именно так. После инициализации запрыгиваем в бесконечный цикл. Если на входе 4 установилась единица, значит там сервоимпульс. Вот его и меряем. Замер заканчивается с окончанием импульса и наступлением синхропаузы (на входе 4 - ноль). Дальше делаем с импульсом все, что нам надо и, по аналогичной замеру методе, выводим его на любую другую лапку камня. Можно еще раз обработать и вывести на еще одну лапку.
Главное - уложиться в синхропаузу (18 мс). Обработали, вывели, расслабились. Ждем, пока на входе 4 не закончится ноль. Как закончился, перепрыгиваем к обработке входного импульса и все повторяется по-новой.
По хорошему перед первым замером пару импульсов лучше пропустить, чтобы не влезть в середину импульса. После замера можно проверить импульс на попадание в допустимые пределы.
Именно так.
Все гениальное простоB-)
Спасибо, попробую повторить оное на сях в меге.
На тиньке 13 по другому сделать и не получится у нее нет 16 битного таймера и входа ICP. А вот на меге желательно использовать встроенные аппаратные ресурсы.
Вначале вы правильно решили вводить импульс при помощи ICPи выводить ШИМ.
Ввод и вывод в фоновом режиме под прерываниями, между ними обработка импульса.
При этом джитер измерения и вывода импульса минимальный и на обработку остается вагон времени.
Есть несколько тонкостей чисто аппаратных.
Советую использовать ICPвход не напрямую, а через встроенный аналоговый компаратор, у меги есть функция их сцепки. В этом случае исчезнут проблемы с уровнями сигнала от приемника.
Выводить импульс удобнее при помощи прерывания Compare соответствующего выхода.
Кварц удобней использовать на 8 МГц тогда при установке делителя 16 битного таймера счетчика на 8. Мы получаем 1 тик таймера =1 микросекунда. Проще будет потом производить расчеты в программе.
Счетчик не перезагружаем, пусть молотит по кругу. Все измерения импульсов производим как разность показаний счетчика в начале и в конце импульса.
ага, спасибо огромное за науку! В принципе я так и думал что так правильно, просто терзали сомнения успеет ли камень обрабатывать новый входящий импульс, в то время как PWM генерит текущий обсчитанный. про компаратор - посмотрю осциллографом что там на выходе, м.б. и обойдусь малой кровью, компаратор может еще понадобиться, так что можно кинуть в принципе какой-нить простенький ОУ на входе.