А можно просто использовать микроконтроллер, в который энкодер понимает аппаратно. Те-же STM32 Говоришь ему - энкодер подключен к такимто контактам. И после этого только ловишь прерывания "положение энкодера изменилось" и в переменной таймера заботливо написанно - насколько. Дребезг контактов естественно обрабатывается аппаратно.
Это не я говорю. Это экспериментировал тот крендель, ссылку на которого я приводил выше. Целой схемы он не привел, но показал нечто на видео:
Ключевой момент, когда он говорит "sometimes it gets a glitch" -- время от времени проходит помеха. Причем, все это видно на прыгающих значениях индикатора. Т.е. даже с развязкой через триггеры Шмитта оно все равно допускает ложные срабатывания.
Я не могу оспаривать ваши опыты, чему свидетелем не был, но не доверять данному видео тоже нет никаких оснований. Пока складывается впечатление, что надежность схемы может вызывать нарекания. Возможно, что эксперимент на реальном железе что-то бы прояснил, но это уж по вашему усмотрению.
balmer писал(а):
А можно просто использовать микроконтроллер, в который энкодер понимает аппаратно. Те-же STM32
Аппаратный пробинг, как средство борьбы с дребезгом контактов, есть не только у STM32. Зачатки оного можно даже у AVR наблюдать. На STM8 почи весь набор, что и на STM32.
Цитата:
Говоришь ему - энкодер подключен к такимто контактам.
Целый таймер под это дело придется отдавать, если я не путаю чего. Не всегда такая роскошь позволительна. Меня изыскания топикстартера и привлекли тем, что он пытается вешать энкодер на любые ноги МК, а не только на таймер.
только что дошло почему в моем девайсе все работало четко, такие помехи будут значительно короче чем полноценный импульс , тогда можно изменить программную обработку и уже программно убить возможные косяки причем вобще без шума и пыли , сейчас приступлю к проектированию в протеусе , мне-бы только модель энкодера которая выдает все с таким дребезгом как на приведенной выше осциллограмме добыть , есть мысли ?
Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.
не знаю где вы нашли дешевые оптические но 1500р/штука и 100р/штука по-моему разница существенная , я лучше проведу пару тестов и добью-таки схему до идеала ибо остальных деталей тут всего на полтинник , и я сомневаюсь что перевалит за 100 после моих изысканий
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
Вот, например, модели серий EM14A0D и C14D16P от Bourns и CUI, соответственно за 13$ и17$, с которыми я имел дело. Да, дороже механических, но зато чистый сигнал и процессор не отвлекается понапрасну. А может для Ваших приложений подойдет touch panel с внешним контроллером (справа, 10$). Она одна может заменить ощутимое число других органов настроек. В прошлом году делал проект с такой на лицевой панели и нарисованными под ней кнопками. Контроллер TSC2007 от ТИ подавляет весь дребезг и упрощает программу МК.
В STM32 не использую аппаратную обработку энкодера по следующим причинам:
- нет подавления дребезга - тратится таймер - жестко привязываются выводы - теряется возможность сделать программное переключение типа энкодера с другой разводкой F1, F2 и GND - все равно требуется программный поллинг таймера
Обработка энкодера в прерывании тоже не имеет смысла, так как событие энкодера должно быть обработано в задачах, которые выполняются в основном цикле. Поэтому обработка энкодера - только программный поллинг, оформленный в виде одной из задач основного цикла.
Спойлер
Код:
//----------
//Модуль поддержки энкодера
//Энкодер подключается к портам ENC_F1 (фаза 1) и ENC_F2 (фаза 2). //Функция Enc_Exe() вызывается в основном цикле. //Результат обработки энкодера может быть прочитан //с помощью функции Encoder_GetCode().
А если в основном цикле есть неделимые куски кода, выполняемые достаточно долго ? Например вывод на графический дисплей.
_________________ "Вся военная пропаганда, все крики, ложь и ненависть исходят от людей, которые на эту войну не пойдут !" / Джордж Оруэлл / "Война - это,когда за интересы других,гибнут совершенно безвинные люди." / Уинстон Черчилль /
Зачем в основном цикле сразу реагировать на события энкодера ? Когда сможет тогда и отреагирует, но в случае использования прерываний событие будет зафиксировано (поменяется какой нибудь счетчик), а если опрашивать в основном цикле - нет.
_________________ "Вся военная пропаганда, все крики, ложь и ненависть исходят от людей, которые на эту войну не пойдут !" / Джордж Оруэлл / "Война - это,когда за интересы других,гибнут совершенно безвинные люди." / Уинстон Черчилль /
вот уж мне эта любовь к немедленной реакции на события, генерируемые действиями человека! я еще могу понять, что нужно мгновенно реагировать на кнопку "аварийный останов реактора", да и то "мгновенно" все равно означает 20-50 миллисекунд в самом оптимистичном случае... а энкодер и подавно такая вещь, что даже если пару щелчков пропустить - никогда ничего не произойдет и удобство эксплуатации прибора не пострадает.
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Если переключать режимы в какому нибудь списке или громкость поменять - ничего страшного, можно крутить пока не станет как надо, а вот если частоту в трансивере менять и на один и тот же угол поворота реакция разная - неприятно.
_________________ "Вся военная пропаганда, все крики, ложь и ненависть исходят от людей, которые на эту войну не пойдут !" / Джордж Оруэлл / "Война - это,когда за интересы других,гибнут совершенно безвинные люди." / Уинстон Черчилль /
неприятно? да фигню вы говорите, уважаемый! ибо человек не в состоянии заметить 20 миллисекундную задержку в принципе, а большинство и 0,1 секундную не замечают! а для МК 20мс это много, а 100мс - почти вечность! и печалиться о том, что реакция на энкодер будет задержана на это время - просто приступ перфекционизма в шизоидной стадии!
про пропуск щелчка я сказал утрируя, ибо чтобы возник пропуск надо программу писать на MS Visual C и исполнять в ОС Windows, все прочее успеет энкодер обработать "мгновенно"
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Я не про задержку реакции системы относительно пользователя, а именно про пропуск шагов энкодера. Пример вполне типичный привел - графический индикатор (особенно цветой или подлюченный по i2c), в процессе вывода (допустим) частоты на который энкодер продолжает вращаться. Если использовать LCD 16*2 и простейший энкодер на 24 щелчка пропусков почти нет даже если просто опрашивать - это да, уже попробовал
_________________ "Вся военная пропаганда, все крики, ложь и ненависть исходят от людей, которые на эту войну не пойдут !" / Джордж Оруэлл / "Война - это,когда за интересы других,гибнут совершенно безвинные люди." / Уинстон Черчилль /
на дохленькой меге с низкоскоростным SPI я заполнял цветной дисплейчик от сименса примерно 12-15 раз в секунду, выводя различные геометрические фигуры. поэтому я с твердой уверенностью заявляю, что никакой вывод на ЖКИ не сможет привести к пропуску шагов энкодера даже при его опросе в главном цикле! ну, если вы хотя бы немного умеете писать программы, конечно
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
За 50 мс заполнения экрана разве не могут импульсы придти ? В приличном энкодере вроде 400 импульсов на оборот. Хотя ситуация когда это нужно может и нечастая, кроме как частоту менять я так сходу и придумать не могу где надо так быстро крутить. Оптический я не пробовал без прерываний, если не забуду гляну на выходных.
_________________ "Вся военная пропаганда, все крики, ложь и ненависть исходят от людей, которые на эту войну не пойдут !" / Джордж Оруэлл / "Война - это,когда за интересы других,гибнут совершенно безвинные люди." / Уинстон Черчилль /
Энкодер, довольно шустро, может вращать станок и пропуск изменения его состояния катастрофичен. По мне, все циклы могут подождать, а вот каждое изменение состояния энкодера обязательно должно быть обработано.
Когда сможет тогда и отреагирует, но в случае использования прерываний событие будет зафиксировано
От этого больше вреда, чем пользы. Допустим, регулируем напряжение БП. Программа чем-то занялась и перестала реагировать на события. Затем освободилась и отработала сохраненные события - напряжение прыгнуло неизвестно как, что может иметь катастрофические последствия. Если событие не можем обработать, его нужно пропускать, а не сохранять.
Morroc писал(а):
В приличном энкодере вроде 400 импульсов на оборот.
Это какая-то экзотика. Обычно не больше 24 импульсов на оборот. Именно о таких обычных энкодерах здесь речь.
akl писал(а):
Энкодер, довольно шустро, может вращать станок
Энкодеры на валах двигателей - это совсем другая история.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 21
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения