Контроллер теплицы на Arduino Mega

Пока на Pro Mini планируется, но в будущем надо будет портировать функционал модуля с датчиками под STM8L: реализовать там 1-Wire и один из шлюзов для общения (RS-485 или nRF) - в общем, если влезет всё - значит всё портировать, если влезет что-то одно - значит будут две прошивки. Но я пока с STM8 - от слова "никак", надо изучать.

Значит, вы считаете, что в прошивке под Pro Mini не стоит заморачиваться с энергосбережением?

 

Нет, был не в курсе, теперь буду знать. Тестирования ещё предстоит - мама не горюй, по понятным причинам я тестирую в минимальных конфигурациях - два модуля RS-485, две nRF и т.п.. Надо дорасти до отладочной платы, пусть и разведённой вручную, чтобы уже более плотно прошерстить весь функционал: вот тогда точно придётся отпаивать указанные резисторы, спасибо вам за информацию!

 

Может быть я что то делал не так, но когда проводил опыты для устройства, которое должно было имитировать работу приемника, соответственно работало на автономном питании, то сделал вывод, что труды не стоят свеч. Сначала пробовал ронять в сон с пробуждением по таймеру, потом по прерываниям, потом "легкий сон", в конце концов просто завалил его в глубокий сон для замера потребления. Разница есть, но она оказалась в пределах 10-15%, что вряд ли стоит того. Для энергосбережения нужен более глубокий подход, с отключением периферии в первую очередь, как мне кажется.

Убил вечер чтобы понять это. Начиная с 4х модулей между проводами А и В тестер показывал КЗ. Я честно искал где это КЗ, пока не осенило. Когда делал на голых микросхемах, все было прозрачнее и понятнее. Но модули эти все же удобнее, хоть и не безупречны. А еще расстояние между рядами ножек у них дурацкое, заметили? )

 

Это точно, идиотское

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

 

Подглядел у nooLite.
Датчик измеряет температуру раз в... отправляет - если отличается больше чем на полградуса. У меня на ESP8266 работает от 2 АА не менее пяти недель.
RFM69 надо бы ещё посмотреть.

 

Это хорошо, что не менее пяти недель Но у меня там ещё одна проблема: помимо собственно nRF, постоянно маслается код проверки данных по RS-485, плюс - 1-Wire. Если 1-Wire ещё можно усыпить, там всё равно прерывание на 2-м пине юзается, то задача, скорее, не в том, чтобы даже усыпить, а в том, чтобы усыпить грамотно: чтобы ничего друг другу не мешало, и просыпалось тогда, когда надо измерить, или пришли данные по RS-485, или уровень на 2-м пине поменялся. Короче, пока я в этом плаваю.

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

 

По прежнему приглашаю желающих присоединиться к проекту: сейчас, например, стоит задача оптимизировать прошивку универсального модуля с датчиками (в части энергосбережения) и сделать принципиальную схему платы модуля с датчиками, чтобы не пришлось юзать Pro Mini с прочими бутербродами на борту.

Бенефиты? Сделать готовое устройство, а не набор "сделай сам на соплях и клее". Применение? Да везде, не только как контроллер теплицы. Профит? Вырасти из работы с конструкторами, получить мировое признание, заслужить респекты и уважуху Развитие? Довести устройство до уровня "на продажу", вполне возможно.

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

При этом, хочу заметить, у меня строгое отношение к доступности: при любом раскладе все схемы, код и т.п. - останутся в свободном доступе. Кроме исходников конфигуратора, там просто стыдно показывать

 

Потихоньку допиливаю прошивку под модуль с датчиками - сегодня силами общественности в лице одного хорошего человека на свет начала появляться свой платка под Atmega328, а я в это время борюсь с энергосбережением, чтобы плату эту можно было поставить в автономку. Поэтому - никаких светодиодов на плате, питание линий с датчиками отрубается по ключу с пина камня, в прошивке пока принудительно останавливается подсистема I2C между опросами датчиков. Осталось прикрутить посылание камня в сон периодически, да пробуждение по приходу байта по UART или по смене уровня на пине номер 2.

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

 

Новое видео про работу с nRF24L01+:

 

Добавил поддержку китаёзных датчиков влажности почвы (не жалко пары строчек кода) и датчиков DHT* (т.е. DHT11 и DHT2x-семейства) в прошивку универсального модуля с датчиками.

Для универсального модуля с датчиками уже сделана своя плата под Atmega328, осталось только сами камни дождаться и начать тестирование. Камень будет работать на 8МГц, и, судя по всему, уже есть проблемы с реализацией 1-Wire протокола для регистрации модуля: надо будет рыть тайминги. Под это дело заказал у китайцев клон Saleae - по отзывам отличная вещь, хоть смогу посмотреть, чего там по таймингам творится: на 16 МГц всё работает прекрасно, а вот на 8 - чего-то как-то не очень хочет, судя по отзывам пользователя.

Приступили к разработке "материнской платы" под всё это дело, планируется, что туда будет впаиваться сами Arduino Mega и всякие разные модули. От первоначальной идеи сделать полностью свою плату - отказался, т.к. неясны дальнейшие перспективы пока, это раз. Два - как показала практика, у китайцев готовый модуль часов на основе DS3231 стоит чуть ли не дешевле, чем отдельная микруха DS3231, да и по выводам все разномастные модули совместимы. То же самое касается и всяких модулей под карточку microSD - овчинка выделки не стоит, чтобы её ещё на плате деталями паять: проще взять готовый.

Какие-то потроха - будут отдельными платами, типа LCD-экрана вместе с информационными светодиодами, энкодером и кнопкой: так сильно проще и технологичней.

В общем, проект потихоньку развивается, ттт, чтоб не сглазить: кол-во пользователей, юзающих прошивку в режиме "я собрал всё на макетках и клеЮ" - растёт, по факту регулярных багрепортов вылавливаются блохи, функционал уже в основном нарастил мясо. Осталось всего ничего - ещё полгодика разработки

Сейчас на очереди - внедрение контроля pH в систему, затем надо будет всё, чего не хватает в вебморде - вынести туда, например, регистрацию универсальных модулей в системе. Затем - маленький роутер, типа TP-LINK TL-MR3020, на него - openWRT с вебмордой, и - какао какао ко-ко-ко-ко

 

Как можно даже думать о DHT любых мастей, а не то что делать их поддержку. Проект то серьезный!
http://forum.amperka.ru/threads/dht-11-22.7298/

 

Да я в курсах про это гадость, но упросили. Чего не сделаешь для пользователей

 

Коллега, а что есть такое "конечный автомат" в вашем проекте? Прочитал статью на Вики и теперь пытаюсь понять, как вы используете этот математический аппарат в своем проекте.
Если есть время, расшифруйте пожалуйста.

 

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

Абстрактный пример: вам надо выполнить какую-то команду, затем дождаться её выполнения, затем, по результатам - выполнить тот или иной кусок кода. Обычный подход таков (псевдокод):

Код (C++):

var event = createEvent(eventName);
void loop()
{
var result = execCommand(event);
while(!event.completed); // ждём выполнения команды (тут может быть delay или ещё чего - не суть);
if(result)
  execCommand3();
else
execCommand2();
}
 

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

Код (C++):

enum {IDLE,WANT_TO_EXEC_COMMAND, WAIT_COMMAND_COMPLETED};
var machineState = IDLE;
var event = createEvent(eventName);
void loop()
{
    switch(machineState)
    {
        case IDLE:
        {
            if(timeSinceLastCall > 3000)
            {
                machineState = WANT_TO_EXEC_COMMAND;
                timeSinceLastCall = now();
            }
        }
        break;
     
        case WANT_TO_EXEC_COMMAND:
        {
            execCommand(event);
            machineState = WAIT_COMMAND_COMPLETED;
            commandStartedAt = now();
        }
        break;
     
        case WAIT_COMMAND_COMPLETED:
        {
            if(event.completed)
            {
                machineState = IDLE;
                commandExecutionTime = now() - commandStartedAt;
            }
        }
        break;
    }
 
    // тут делаем что угодно, например, второй автомат со своими состояниями.
    // все состояния автоматов будут обрабатываться параллельно.

}
 

Т.е. мы имеем довольно мощный инструмент управления ветвлениями кода. На практике я использую это дело для работы со сторонними железками, например, с GSM-модемами или ESP, когда в зависимости от текущего состояния автомата надо сделать то или иное. Или - когда надо выполнить команды в определённой последовательности, например - для этого достаточно завести очередь состояний автомата, в которую записывать команды на выполнение.

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

Код (Javascript):

$.ajax( { method: "POST", url: "/x_handler.php", dataType: "json" , data: { posted: 1, product_id: product_id, product_user_id: product_user_id} }  ).done(function(data) {
   
     alert('Done!');
             
      });

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

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

 

Начал добавлять поддержку контроля pH в прошивку, юзается вот такой модуль: http://www.dfrobot.com/wiki/index.php?title=PH_meter_V1.1_SKU:SEN0161

Собственно, значения pH уже получаются, датчик можно прицепить как к самому главному контроллеру, так и вынести на универсальный модуль с датчиками и получать с него данные, как водится, тремя путями: 1-Wire, RS-485, nRF.

Собственно управление дозаторами, мотором перемешивания и прочими плюшками будет реализовано на PCF8574, которую можно будет подключить как прямо к контроллеру (стандартный I2C), так и вынести по удлинителю I2C (P82B715) подальше - на разрабатываемой плате место под микруху удлинителя уже предусмотрено.

После того, как полностью будет дописан блок контроля pH, останется совсем чуть-чуть, как обычно - добавить в веб-интерфейс недостающий функционал, которого пока там нет, но который уже присутствует в конфигураторе, добавить и отладить поддержку SIM800L, разобраться с таймингами на шине 1-Wire - сейчас на 8 Мгц Pro Mini чего-то не очень стабильно работает клиентский модуль, спроектировать, развести, оттестировать шилд для LCD-дисплея с кнопкой и энкодером (чтобы можно было это дело выносить на лицевую панель), добить вопросы с платой универсального модуля с датчиками, разработать плату универсального исполнительного модуля, разработать корпуса всех ништяков и - тестировать, тестировать, тестировать: тот же RS-485 надо будет гонять на реально длинных проводах, т.к. я сейчас выставил скорость работы с ним в 57600 бод (ненавижу маленькие скорости ), и неизвестно, как оно будет в боевом окружении, так сказать.

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

З.Ы. Серьёзно задумался о покупке 3D-принтера, для распечатывания корпусов и всякой мелочи.
З.З.Ы. Младший сын на день рождения получил в подарок аквариум, теперь вот думаю, что как закончу с этим проектом - есть мысли сделать контроллер для аквариума, с Nextion на борту и блэкджекомвсякими плюшками. Конечно, если к тому времени интерес отрока к аквариуму не угаснет в ноль.

 

Наконец-то доделал первую версию контроля pH - там куча всяких калибровок с эталонных растворов и вообще - настроек кучу Работает модуль через микросхему PCF8574, по шине I2C - такое решение было принято, во-первых, из-за удобства - быстренько вынести нужные каналы вовне (а их, ни много ни мало - 5 штук занято: контроль уровня воды в баке с pH, управление насосом подачи воды, управление насосом перемешивания раствора, управление подачей реагента для увеличения pH, управление подачей реагента для уменьшения pH - набежал вагончик, как видите).

Во-вторых - из-за удобства, опять же: на разрабатываемой плате для Меги есть микросхемка - удлинитель I2С, со всеми вытекающими: на том конце заюзали такую же микросхемку, и вытащили любое I2C-шное устройство на 100 метров, скажем

Теперь осталось таки добить SIM800L, да подпилить тайминги для 1-Wire - по слухам, на Pro Mini 8MHz нормально не работает самописная реализация протокола, надо рыть - как раз жду из Китая про миньки восьмимегагерцовые. После того, как утрясу с этим - надо кончать (с) "Ширли-Мырли" В том смысле, что вчерне прошивка будет готова, останется дело за железом - собрать всё аккуратненько, протестировать платы универсальных модулей и саму плату для Меги, попутно подправить тонну косяков, окончательно облысеть от усердного чесания затылка, и вообще - мандражировать в процессе не по-детски Ну а потом - вообще всё.

З.Ы. Заказал таки себе 3D-принтер, чтобы, значить, новая игрушка, как водится, ну и - прототипы всяких корпусов и прочей шняги делать.

 

Тут есть решение, но есть и некоторые "НО".
1. Про Мини надо перепрошить BOOTLOADER на OptiBOOT. Когда искал инфу по этому вопросу, пишут что некоторые ПРО МИНИ уже нормально работают при переводе в повердаун режим, наверно были прошиты нужной прошивкой bootloadera
2. Питаем Про Мини от батарей(аккумуляторов) напрямую минуя или отпаиваем встроенный в плату стабилизатор. На плате есть пара пинов для внешнего питания GND и RAW. Вообщем можно по разному запитать, все зависит от ваших предпочтений.
Еще не забываем отпаивать всякие светодиоды на плате, после отладки.
3. Переводим контроллер в режим пониженного энергопотребления например, в режим POWER DOWN.
4. Про Мини управляет питанием остальной электроники(отключает все перед переходом в POWER DOWN ) и датчиками через полевой транзистор(с низким внутренним сопротивлением например IRF4905) .
5. После пробуждения Включает всю переферию.
В результате получаем потребление всей схемы с датчиками и т.п , режим пониженного энергопотребления на уровне контроллера, микроамперы (100-500мкА приблизительно, у меня нечем было замерить). И батарей(аккумов) хватает на долго.

ps\ у меня на ПРО МИНИ, по такой схеме, собран RFID замок на кабинку в раздевалке.

Еще есть вариант за перевод в режим низкого потребления будет отвечать ATtiny85(ATtiny13) - это наверно будет перебор и одной меги(про мини) хватит.

 

В копилку для DIYMan
На даче, датчик температуры и влажности собрал из Atmega328P, Si7021, nRF24l01+.
Запитал все это дело от Ионистора на 4Ф + солнечная панелька на 5В 40мА (60мм х 38мм) + 2 светодиода, включенных последовательно.
Разместил датчик на улице, под крышей дома. Работает исправно уже все лето.
Так что устройство получилось абсолютно автономным.
Естественно, что использую powerdown как для Atmega, так и для nRF.

 

Позвольте пару вопросов, может они возникли т.к, я не вник в проект(код) в целом, но все же:
1. Зачем вы в структурах разделяете показания датчика (температура или влажность, например) на целую и дробную часть? А у температуры и знак отдельно?
2. Почему при описании сходных по смыслу структур вы не используете одинаковые имена для членов? Ведь так было бы проще ориентироваться в них.

Код (C++):

typedef struct
{
  bool Negative;
  int Whole;
  int Fract;
 
} DS18B20Temperature;

typedef struct
{
  bool IsOK; // данные получены?
  uint8_t Humidity; // целое значение влажности
  uint8_t HumidityDecimal; // значение влажности после запятой
  int8_t Temperature; // целое значение температуры
  uint8_t TemperatureDecimal; // значение температуры после запятой
 
} HumidityAnswer; // ответ от датчика