Так, по-вашему, будет лучше сразу перейти на Ардуино и отладить на ней, а затем придумывать обмен командами по моно-проводу с ESP-12 (ESP-32?), вроде CAN-BUS. Или имеет смысл всё-таки заморочиться и внедрить таки сразу всё на ESP?
-
Уважаемые посетители сайта esp8266.ru!
Мы отказались от размещения рекламы на страницах форума для большего комфорта пользователей.
Вы можете оказать посильную поддержку администрации форума. Данные средства пойдут на оплату услуг облачных провайдеров для сайта esp8266.ru -
Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram
Использование ESP-12 в связке с DRV8833 и электромоторчиком, и ITR9606
- Автор темы MeMagic
- Дата начала
Пробуйте на есп, код перенести на простую ардуино плату не составит труда.
Нафига козе баян ?
Если есп рядом, простой обмен через UART, удобно использовать JSON.
Понимаете, ту не про баян речь. А про то, что это должно быть системой управления жалюзи на веранде балкона, и в ряд будут стоять штук 6-8 жалюзи, и каждым надо управлять. А если управлять всеми одновременно, то и в этом случае нужно отсылать отчётливые комманды на открытие на определённый угол, а не просто открыто/закрыто.
В моём видении, центрально стоит одна коза, которая отсылает команды кучке других коз. Если козы на местах - Ардуины, то к каждой надо тянуть свой проводочек и общую массу, плюс ещё и питание. А это значит пучок проводов - не фэншуй. Если ESP, то реализуется буспроводная передача комманд и только 2 провода питания на все локальные контроллеры, ну, может ещё один для всех для ввода/вывода в/из сна (GPIO16).
Ещё у меня была идея на каждый контроллер прицепить по 2 18650 аккума с 2-мя солнечными ячейками и контрроллером заряда - стоимость всего этого невысока. Тем более, что есть открываемые под углом створки.
В общем, - так.
Для управления жалюзи хватит и есп.
надо программно убрать дребезг
алгоритм может быть примерно такой
1) измеряем время прошедшее с момента прихода фронта
2) если интервал больше порога то считаем, что дребезг закончился и фиксируем время прихода сигнала и выходим
3) если до истечения заданного интервала пришел новый импульс то переходим к п.1
--------------------
проще всего это сделать в цикле читая сигнал с пина
но лучше делать с использованием прерываний от пина и таймера.
-----------------------
И не надо читать советы по навешиванию чего-то непонятно зачем-то.
В этой конструкции дребезг не мешает, другое дело, если есть ложные срабатывания от старта двигателя.
если я правильно понял, то у автора темы(Вы же не автор) дребезг.
но если у Вас ложные срабатывания при старте , то это тоже решается программно, но противоположным по логике алгоритмом
надо, подобно блокированию приемника в РЛС на момент включения передатчика, заблокировать обработку сигнала оптрона
на время старта двигателя.
------------------------------
полагаю, что решения в программируемых устройствах, в отличии от жесткой логики, должно быть максимально программно.
1. Я бы сказал, что это дребезг. Но, как всегда, основная проблема в диагностике. Ещё, что касаемо старта двигателя - проблема не в старте двигателя как такового, а в том, что, в некоторых случаях, дребезг проявляется максимально в момент передачи сигнала для двигателя на выход ESP. При этом выход может вообще не быть подключен к чему-либо. Это был частный случай, когда я прекрасно отслеживал сигнал с оптопары, пока не отсылал сигнал управления к двигателю.
(что радует - если я сказал, что это дребезг, и меня поняли, то феномен знаком и другим и имеет место быть)
2. Именно жёсткую логику электроники было бы желательно иметь, но если это невозможно, - так хоть как-то!
Придётся изобретать алгоритмы фильтрации.
На данном этапе упирается в реализацию механической модели. Ждём выходных и вдохновение.