Arduino Mega. Контроллер теплицы. Хроники - 3.0

РЕКЛАМА НА ФОРУМХАУС

Оно самое

 

В настройках прошивки, в частности Configuration_MEGA.h - расписаны все пины. Но я вам больше скажу - прошивка настраивается как вам надо, за исключением I2C, SPI и UART - практически все остальные пины могут быть любыми, как вам удобно разводить. Вы можете просто посмотреть указанный файл, вникнуть в настройки, что называется. Там можно по всякому настраивать - и работу с портами МК напрямую, и использование расширителей портов MCP* и т. д. и т. п. Короче, настроить можно как вздумается, практически.

 

По фотографии тестировать не умею ещё

 

Все равно за адекватные деньги ни чего в альтернативе нет, поэтому лара

 

Дима, тебе отправлю в догонку к плате, но после Нового года
Заодно потренируешься с АРМами SAMD. Александр.

 

Договорились

 

Обновил на гитхабе, сделал настройку на TFT-экране - выставление интервала для открытия/закрытия фрамуг. Ну и кой-чего по оптимизации мал-мала.

Надо начинать тестировать GSM, всё никак с духом не соберусь

 

Действует ли это замечательное правило на входы от счетчиков воды, или требуется их заводить на INT-ы, как об этом говориться в Configuration_MEGA.h ("модуль занимает пины 2 и 3 меги, т. к. работает по прерываниям")?

 

Да, для Меги пины 2 и 3 - прибиты к счётчикам воды, там только эти два пина на внешних прерываниях. Но если вы не используете счётчики воды - следовательно, эти пины свободны. Я же говорю, что прошивка очень гибко настраивается, на примере модуля расхода воды: достаточно закомментировать USE_WATERFLOW_MODULE - и всё, никто пины 2 и 3 занимать не будет Ну и далее по списку, что называется - всё зависит от того, что лично вы хотите видеть в качестве функционала своей платы

Про настройки: зайдите в Globals. h - и вы там увидите, что можно держать параллельные настройки для трёх плат сразу: для Due, и два файла настроек для Mega2560. Т. е. вы можете определить в Globals. h тип платы, которую используете, и будет подключён тот или иной конфигурационный файл - или Configuration_DUE.h, или Configuration_MEGA.h, или Congiguration_MEGA_MiniBoard.h. Т. е. всё сделано так, чтобы и тут было где поиграться

Настройки отладочных режимов - в Configuration_DEBUG.h, плюётся в первый UART всякой отладочной инфой, если надо. Короче, там много всякого. Если что-то вот прям конкретное интересует - спрашивайте, а так, как я и сказал - очень многое настраивается/переназначается довольно легко.

Если пинов не хватает - всегда можно посадить функционал на MCP23S17 или на MCP23017 - много чего из модулей умеет работать через эти микрухи, что есть хорошо, я уже оценил удобство и красотищу MCP23S17. Все эти настройки есть в настройках прошивки, сорри за тавтологию. Если что-то непонятно по конкретным настройкам - спрашивайте.

 

Итак, что предлагаю в разрезе модуля обратной связи положения фрамуг: есть такая чудесная микросхема - CD74HC4067, аналоговый мультиплексор, и как раз на 16 входов (напомню - 16 у нас максимальное кол-во фрамуг, которая держит прошивка на одном контроллере). Следовательно, к нему можно подключить те же самые 16 потенциометров, и по изменению сопротивления вычислять, в каком положении то или иное окошко.

Уже заказал платку на али: https://ru.aliexpress.com/item/Smart-Electronics-CD74HC4067-16-Channel-Analog-Digital-Multiplexer-Breakout-Board-Module-for-Arduino/32643886767.html?spm=a2g0s.9042311.0.0.EiGWiL

Это, что называется - самая простая схема реализации, а уж что там у вас будет крутить потенциометр - дело десятое. Зато без плясок с бубном получаем необходимый функционал, вне зависимости от того, в какой плоскости работает фрамуга - главное, чтобы в зависимости от её положения менялось сопротивление на входе.

Думаю, это будет первый шаг из поддерживаемых планируемым модулем возможностей получать обратную связь - как обычно, в прошивке будут всякие настройки, чтобы можно было её адаптировать так и эдак.

Если без мультиплексора - то аналоговых входов не хватит, чтобы на одном модуле получать информацию обо всех 16 каналах. Но и тут не беда, возможно, даже плюс: дело в том, что не всегда может быть удобно к одному модулю тащить провода, проще подключить их несколько на шину RS-485 (ну или по беспроводу в будущем). В таком разрезе настраиваемость видится следующим образом: каждый модуль - на 4 канала, всего таких модулей может быть максимум 4. Контроллер опрашивает все 4 модуля на шине, какие из них есть - отвечают. Номер модуля - можно сделать выбираемым DIP-переключателями на плате, надо двухпозиционный, вроде - тогда адреса получаются 00, 01, 10, 11 - как раз четыре

Программно же каждый модуль будет в пакете данных отправлять свой номер, кол-во обслуживаемых каналов, и их состояние, т. е. - в случае с модулем на 16 каналов полезной информации будет 1 байт под номер модуля и кол-во каналов + 16 - 17 байт, в случае с модулями на 4 канала - 5 байт, и в том и в другом случае вмещаемся в стандартный размер пакета, который сейчас гоняется по шине (30 байт) - с запасом. Так что вводные вроде годные, считаю - осталось только продумать по градациям положений - хватит ли нам 5 бит (32 градации), или нет. Я думаю, что за глаза 32-х градаций, на примере открытия фрамуги на 180 градусов один шаг будет меньше 6 градусов, куда нафик такая точность, не в космос же отправляем

С форматом пакета, конечно, ещё думать, т. к. неясно - надо ли вообще биты крайних состояний (открыто или закрыто), т. к. если у нас есть данные с потенциометра - значит, есть данные о положении, значит - биты о крайних состояниях - не нужны, навскидку нужен только бит наличии информации о положении фрамуги - мало ли, вдруг проводок с потенциометра канала мыши перегрызут

Как закончу адаптацию прошивки под Due - возьмусь за написание прошивки для такого модуля, а уже потом - буду в прошивке контроллера вводить это дело.

З. Ы. Кто мне набросает принципиальную схемку с переключателями выбора номера модуля и потенциометрами на 4 канала - цены тому не будет Я, конечно, могу и сам попытаться - но тогда будет совсем неинтересно

 

Вот, по теме: http://greentalk.ru/gallery/image/5300-электропривод-фрамуг-своими-руками_1/

Потенциометр на 10 оборотов: https://ru.aliexpress.com/item/3590S-precision-multi-turn-potentiometer-10K-quality-adjustable-resistor/32617817799.html?src=google&albslr=119593620&isdl=y&aff_short_key=UneMJZVf&source={ifdyn:dyn}{ifpla:pla}{ifdbmBM&albch=DID}&src=google&albch=shopping&acnt=494-037-6276&isdl=y&albcp=657872107&albag=38867178172&slnk=&trgt=61865531738&plac=&crea=ru32617817799&netw=g&device=c&mtctp=&gclid=CjwKCAiA693RBRAwEiwALCc3u6YDp8SOO2oi8HTOcSGrqqz8Dl5VfQJs80O8liH6QLO5CC2mzpRD-BoCKhkQAvD_BwE

Ещё одна из плюшек введения обратной связи: можно будет уже не зависеть от передачи времени в команду STATE|WINDOW|0|OPEN|123 (где 123 - время работы приводов), а просто добавить в команду признак % положения, т. е. STATE|WINDOW|0|OPEN|20% - откроется на 20% от закрытого состояния, STATE|WINDOW|0|CLOSE|80% - закроется до достижения 80% состояния открытия. А дальше - простая арифметика: у нас есть время работы приводов до полного открытия, и всё просчитывается на раз. Конечно, существующий функционал будет работать как и прежде.

По-моему, дело годное. И кстати - введение признака открытия в % для команд - можно припилить уже сейчас, дело-то удобное - не надо секунды просчитывать, чтобы команду составить

 

Я молодец - сбил себе нафик график, и вторую ночь в мыле В общем, так - сначала с простого: в конфигуратор добавил поле ввода для команд к контроллеру, под логом располагается. Кому надо - можно так общаться, ручками, если вдруг чего.

Теперь про обновы в прошивке: переделал логику работы с окнами - если раньше было, что пока окно меняет позицию и запрошена новая - то ничего не произойдёт, то теперь - нормально отработает смена позиции сразу, т. е. ими можно дёргать, как ручкой передач КПП В конфигураторе и вебморде, ессно, ничего не менял по этой части - там по прежнему считается, что если окно открывается - нефик его беспокоить. На TFT-экране тоже пока так сделано - пока окно в движении, кнопка управления им - неактивна. Это всё можно и доточить в процессе

Далее: старые команды все поддерживаются, естественно. Но теперь, по сути, необходимость в команде CLOSE почти пропала - она нужна только если интервал никакой не передан, т. е. пары команд STATE|WINDOW|ALL|CLOSE и STATE|WINDOW|ALL|OPEN - по прежнему закрывают и открывают окна до полного времени работы моторов. Но теперь, помимо указания интервала в миллисекундах, например, STATE|WINDOW|ALL|OPEN|1000 (открыть окно, держать мотор включённым 1 секунду), можно задавать интервал в процентах - STATE|WINDOW|ALL|OPEN|10% - откроет все окна на 10%.

И вот тут - самое интересное: неважно, какую команду и в какой процентовке подавать, следующие команды обе откроют окна наполовину:

STATE|WINDOW|ALL|OPEN|50%
STATE|WINDOW|ALL|CLOSE|50%

Допустим, что у нас окно уже открыто наполовину, тогда любая из этих команд прикроет его до позиции 1/4:

STATE|WINDOW|ALL|OPEN|25%
STATE|WINDOW|ALL|CLOSE|25%

Как видите, ошибиться в рулении окнами - стало намного сложнее, но: подобный подход сразу подразумевает под собой унификацию в части приводов: все окна за 100% открытия берут настройку интервала работы приводов, необходимого для достижения крайней позиции. Ну и, про удобства - теперь можно будет слайдеры открытия каждого окна приделывать, чтобы открывать частично: думаю, в конфигураторе это неактуально (он всё-таки конфигуратор), а вот в вебморде со временем - надо допилить.

В таком разрезе мы, во-первых, УЖЕ имеем информацию о положении фрамуг, но - только во время работы, когда контроллер при старте принудительно загнал их в закрытое положение, дав поработать приводам максимальное время на закрытие. И вот тут мы в будущем легко сможем использовать модули обратной связи, чтобы в процессе работы, во-первых, корректировать крайние позиции (биты крайних положений как результат срабатывания концевиков - это оно), и, во-вторых - получать при старте информацию об истинном положении окон. И если она не получена в течение какого-то времени - только тогда гнать окна в крайнее закрытое положение, чтобы быть уверенным в правильности точки отсчёта.

Короче, мне кажется, что я молодец и всё сделал правильно @Shelllonn - если не затруднит, погоняйте это дело под MQTT - теперь можно не париться с циферками, и обходиться одной командой OPEN И отпишитесь, плз - напорол я где-то косяков или всё работает как надо?

Уфф, вроде выдохнул

З. Ы. И кстати - попутно удалось уменьшить расход памяти и кол-во кода, приятный побочный эффект.

 

Можно обойтись и без мультиплексора: поставить АЦП по i2c, например ADS1115.
Многооборотный резистор - не самая хорошая идея. Если вал 10-ти оборотного резистора будет соединен с осью фрамуги, то сигнал будет в 10 раз меньше, чем мог бы быть (соответственно все помехи - в 10 раз больше по отношению к сигналу выше.).
Я могу нарисовать схему, если до меня дойдет, что нужно. Пока не понял. Для окружающих схема будет в формате pdf.

 

Естественно, решений много Но, поскольку выбирал я - выбрал на 16 каналов, пока дойдёт, пока туда/сюда - уже обрастём дополнительной инфой и хотелками Как правило, я делаю прошивки настраиваемыми, чтобы под использование нескольких железок можно быть приспособить. Так что, возможно, будут и АЦП на I2C

Не улавливаю, почему? Напрямую необязательно ведь с осью, можно по всякому прикрепить - через передаточное число, через ремень - открываясь, фрамуга тащит за собой ремень, в обратное положение ремень тянет пружина, сам ремень крутит потенциометр. Что-то типа такого.

 

Понятно, что хозяин - барин. Просто при таком подходе требуется переработка железа, а старое может устареть. Если же сделать возможность расширения по каналу i2c, например, то для расширения достаточно предусмотреть разъём на 4 контакта и довыпустить модуль при необходимости.

10 бит на оборот =1024. 1024\10=102. Работа происходит в диапазоне 90 градусов максимум, наверное. 25 единиц. Длинные связи = шумы. Работа на уровне помех.
Напрямую, например каким-нибудь силиконовым шлангом на вал -проще=надежнее. Шланг получается просто на раме закрепить надо близко к оси поворота, а с другой стороны - на вал потенциометра. Редуктор конечно интереснее, но зачем?