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

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

Всем привет!

Набросал датчик влажности почвы. См. картинки.

Одна батарея "АА". Соответственно она определяет размер платы.
Разводка не творческая, оптимизация разводки - потом. Если вообще будет, долго это - вручную оптимизировать.

В железе еще не собирал, прошивки еще нет. Поэтому - не надо его пока паять)

Выкладываю - что бы обсудить форм фактор, батарею, доступность компонент (возможны замены)
Жду предложений.

В серийной версии, "в поля" светодиоды и разъемы для программирования и внешнего питания можно не ставить.

Коммуникация датчика - универсальная, то есть просыпается раз в несколько секунд, измеряет и отправляет данные в serial (а вдруг подключен по проводу) а потом, то же самое отправляет в RF (QFM-TRX1-24G).

RF с функцией ‘Wake on Radio’". То есть теоретически должен все время спать и жрать 8.7 микроампера. Attiny в спящем жрет 24 мкА, плюс преобразователь напряжения съест 20-30 мкА.

В общем - я бы ожидал до полугода работы на одной батарейке.

 

Вопрос: а таблетка не лучше? По остальному - всё вроде продумано, и Serial, и радио. Только вот подумалось: Serial это хорошо, конечно, но в него датчик ничего не должен пихать самостоятельно, кмк. Иначе - получим конфликт на шине. Да и с длиной проводов в этом случае засада получится - не очень они и длинные выйдут - не RS485 таки.

Может, как вариант - OneWire предусмотреть для проводного соединения? Т. е. датчик тупо держит в себе последнее измеренное значение, при его изменении - пуляет по радио, а если запросят по OneWire - то пуляет туда. Адресацию можно сделать прямо в прошивке датчика задавая, например.

Что думаете? Просто если делать универсально - значит, нас не должна ограничивать длина провода, как в случае с DS18B20 А на стороне меги я смогу сконвертить радиосигнал принимаемый в Serial - я уже приводил ссылку на контроллер такой - так что с радио проблем вроде не ожидается: будет шлюз радио-UART.

В общем, надо продумать по поводу проводного соединения, кмк.

 

С реле вообще надо продумывать жёстко. Я вот намедни чего подумал: влезет ограниченное кол-во реле: сейчас на 4 форточки уже 8 реле, плюс два реле на каналы полива, плюс - реле на насос. Пинов свободных остаётся - да почти не остаётся, учитывая тот факт, что ещё надо несколько пинов под радио оставить. И получаем - затык.

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

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

 

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

А и даже вообще: не лучше ли будет блок реле вообще отдельно, только сигнальные линии на плате развести, чтобы к ним подпаяться можно было? Чтобы заменять блоки можно было, не трогая основную плату

В правильном хоть направлении мыслю?

 

Я рассматривал serial почти исключительно как отладочную фичу. Погляжу сейчас на OneWire, конечно. Лап должно хватить, в крайнем случае - третья ного attiny может работать на ввод/вывод, когда нет измерения. Ожидаю проблемы с памятью, все же код OneWire клиента несравнимо больше чем просто выплевывание в сериал, будут чудеса оптимизации). Но идея хорошая, плюс получаем дуплекс, вдруг понадобиться, ну хоть для калибровки.

 

Это не так делается. Ставим регистр сдвига, выделяем 2 пина (CLK, DATA) и двигаем цепочку бит по регистру. Каждый разряд регистра - на реле. Соостветственно - количество управляемых реле равно разрядности регистра. Новые регистры добавляем каскадно, при неоходимости увеличения количества реле.

 

Про сдвиговые регистры думал, но в случае с их использованием - придётся логику управления реле переписывать. Сейчас как: одно реле - один пин. Что, конечно, не очень хорошо. Поэтому надо определиться, как именно будет сделано масштабирование каналов реле окончательно, и придерживаться выбранного подхода. Я готов переписать логику управления реле, по идее - там не сильно сложно должно быть - вместо управления пинами по отдельности формируем столько байт, сколько нужно - и пихаем их в сдвиговый регистр, всё.

Но! Тогда нужно чётко определиться с аппаратной частью. Чтобы я мог заказать эти регистры, и прикрутить их.

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

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

 

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

 

Как вариант замены реле форточек http://www.bristolwatch.com/ele/h_bridge.htm

 

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

Но вот с ограничением по каналам реле для форточек - ситуация напрягает.

 

Тоже вариант, но с реле - поуниверсальней: всегда есть пара сигналов, по которым на выходе можно сказать: открывается форточка или закрывается. Что будет прикручено к этим сигналам - вопрос десятый, в нашем случае - это пара реле. Вопрос сейчас, как вы понимаете, в другом: вот будет у меня 10 форточек, и чего делать? Пинов-то надо 20 под это дело будет - я их не нарою столько, при всём желании.

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

Кто не уместится в 16 форточек - ССЗБ, у нас не промышленный контроллер

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

 

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

 

Давайте сделаем шилд на 16. Кому нужно 32 - поставят два шилда, они же каскадно включаются. Причем на шилд и регистры и реле. 16 поместится.

Если определитесь с типом реле и регистров - разведу плату. Она совсем простая.

Регистр предлагаю 74HC595. SO16 корпус конечно, не люблю сверлить)

 

Конечно лучше. Технологичней и компактней. Но емкость в 7-10 раз меньше. Не пугает?

 

Давайте. С выбором реле - на первое время обычные, не твердотельные. Дальше - будет видно, кмк.

Про регистр - полностью полагаюсь на ваш выбор, пусть будет 74HC595. Меня интересует другое: мои действия в части прошивки? Предлагаю так: чтобы не корёжить то, что сейчас уже работает (т.е. один пин - одно реле) ввести возможность настраивать прошивку на использование сдвиговых регистров.

В этом случае, как я понимаю, будет задействовано два пина: один с тактирующим сигналом, другой - с данными?

Пошёл кину в корзину регистры, как будет бабло - закажу.