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

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

Покопался немного по энергосбережению, нашёл класс LowPower, который загоняет МК в сон (самому корячиться незачем, раз уже писано и отлажено ).

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

Буду признателен за отзывы, если вдруг кто захочет протестировать разницу в энергопотреблении и вообще - работает оно или что-то сломалось со включенным режимом энергосбережения: сами понимаете - прошивка не очень простая, там и 1-Wire и пр. - тонкие моменты есть всегда, поэтому... Пока не имею возможности протестировать в боевом режиме, ибо, во-первых - на отладочной плате nRF вместе с ESP не очень хорошо дружат и, во-вторых - хотелось бы протестировать на LoRa, но под это дело надо собирать отдельный стенд. Короче, засады Впрочем, настройка по умолчанию выключена, так что на общую работоспособность данное нововведение не повлияет, и пока его можно считать заделом на будущее в плане энергосбережения.

 

Дима!
Раскоментировал #define USE_SCENE_MODULE и получил вот это...

 

А все файлы обновил? В Configuration_Shared.h лежит этот дефайн, сейчас проверил на гитхабе:

К тому же - меня USE_SCENE_MODULE раскомментирована по умолчанию, если бы не собиралось - я бы заметил. Сейчас попробовал собрать проект - собирается.

З. Ы. И да - компилирую я теперь под 1.8.5, советую переползать туда.

 

Есть 1.8.1.
В 1.8.5. тоже менять SERIAL_RX_BUFFER_SIZE на 128 ?

 

Господа и дамы @Svetlana-nik, @Tehnik53, @HANTER333, @dvs888, @vworld, @olegmak3, @evgeny1241, и другие с проблемами полива. Прошу прощения, что о Ваших трудностях прочитал только сейчас, в конце огородного сезона. Предлагаю Вам на будущий год обратить внимание на капельную ленту для полива. Сам таким поливом пользуюсь не один год. У нас эту "ленту" можно купить практически в любом хозмаге. Цена раза в 2 минимум ниже любой ПНД, расстояние между КОМПЕНСИРОВАННЫМИ капельницами можете выбрать по своему желанию (количество литров в час - тоже). Я воду подаю на полив и из бочки, и из водопровода без проблем (высота дна бочки от поливочного поля сантиметров 40). Из моего опыта - 20 литров воды самотеком через 4-метровую ленту с отверстиями через 25 см пропитывает землю полосой 30 см шириной. 200 литровой бочки за глаза хватает на 32 погонных метра ленты (оставляю полив на ночь). Даже при поливе из водопровода капельки до падения на землю успевают прогреться до окружающей температуры воздуха. Фурнитуры для подключения ленты тоже любой навалом. Также готов ответить на другие вопросы по поводу капельной ленты

 

Можно и не менять, но лучше поменять

 

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

 

Сережа!
Просто товарисч живет на своей волне.

 

Взгрустнулось наверно

 

Собрал новый вариант контроллера. Практически не зависает. Может зависнуть дисплей, если долго и упорно нажимать кнопку сброса. В этом случае сторожевой таймер сам перезагрузит контроллер.

Кстати в контроллере я применил отдельную специальную микросхему сброса.
Я тут подумал, может нужно было применить буфер шины на дисплей, что бы микроконтроллеру вообще было наплевать, что там чудит дисплей. Контроллер работает с DS3231, а не с внутренними часами, но есть перемычка для их включения.

 

Что за буфер шины? Интересно.

 

Существует много разных микросхем буферов. У меня в наличии 50-60 штук 74hc573d. Получается по 3 штуки на дисплей. Посмотрю еще варианты.

 

Понял, ты про tri-state buffer, да? Дык тема годная, на самом деле: на плате Сергея через такой буфер развели устройства на SPI, чтобы не было загаживания MISO.

Считаю, стоит подумать о введении такого буфера и для TFT: если это поможет минимизировать проблемы аппаратного уровня - то это большой плюс

 

Ключевая фраза

 

Тут поступило предложение: много датчиков DS18B20 на одном пине. Сейчас в прошивке дело обстоит так: один датчик - один пин. Это сделано для того, чтобы не морочиться с адесацией на шине, т. к. в случае использования грозди датчиков на шине и смены всего одного датчика на другой в процессе эксплуатации - все внутренние индексы датчиков просто поплывут, из-за особенности адресации устройств на шине 1-Wire (особенность выбора адресов на шине). Как понимаете, такой вариант событий - не алё, т. к. на датчик у нас могут быть завязаны правила и т. п.

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

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

Насколько актуально введение такого расширения функционала, как считаете? Естественно, если это нужно - всё будет сделано настраиваемо, т. е. не коснётся того, что уже работает.

Хотелось бы послушать начальника транспортного цеха И если ответ в целом будет "да" - допишу, но: тестирование работоспособности - на начальниках транспортного цеха