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

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

Кстати, господа, давайте подведём промежуточные итоги касательно программной части:

1. Отправка данных на ThingSpeak - реализована через ESP и GSM (через W5100 будет позже, сейчас не могу - косяки разводки платы, сделаю, когда будет плата четвёртой версии);

2. Универсальные модули - введена новая библиотека, пока не оттестирована на 8Мгц (займусь на днях, достав Pro Mini);

3. SHT10 - в пути, как придёт - добавлю его поддержку.

То есть, если считать, что всё написанное в целом не сильно глючное (косяки выловим потихоньку), то остаётся:

1. Протестировать плату четвёртой версии, W5100 и nRF;
2. Дописать код отправки данных на ThingSpeak через W5100;

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

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

 

Мда... Не работает библиотека 1-Wire на 8 МГц - тайминги опять бьются, хоть тресни. Простой сменой делителя при расчёте кол-ва тиков для пропуска - не взлетает, на 8 Мгц очень крупный шаг тика при делителе таймера в 64 - 8 микросекунд, никуда не годится. Другой делитель подбирать - не влезает в разрядность таймера.

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

Пока оставляем только 16 МГц, а я пошёл смотреть, что там можно сделать по виртуальным пинам.

 

Обновил на гитхабе, добавил поддержку виртуальных пинов. По умолчанию пины, начиная с номера 80 и до номера 127 включительно - виртуальные. Следить из правил у нас можно за первыми 64 пинами (0-63), однако, устанавливать состояние можно для 128 пинов (0-127), из правил ли, или ещё откуда.

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

Правок немного, по сути - в нескольких местах. Но это не означает, что не упустил где-то, надо проверять не раз

Как использовать виртуальные пины: как вы понимаете, они предназначены для универсальных исполнительных модулей, чтобы, сделав привязку канала исполнительного модуля к такому виртуальному пину - состояние этого пина отражалось на универсальный модуль, при этом на мегу ничего не пишется, ни в какой пин. Соответственно, закачиваем в ардуинку скетч универсального исполнительного модуля, настраиваем там привязки слотов к пинам самой ардуинки, и регистрируем её в контроллере, привязав слоты к виртуальным пинам. После можно проверить, подав команду CTSET=PIN|100|ON (на примере включения виртуального пина номер 100, например) - и посмотреть, включится ли пин на исполнительном модуле. Соответственно, установка состояния такого пина работает и из правил

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

Что имеем в сухом остатке: на RS-485 можно посадить N исполнительных модулей, каждый из которых сможет как дублировать 8 пинов меги, так и быть привязанным к собственному набору виртуальных.

З. Ы. Ещё поправил команду запроса баланса для Privet.

З. З. Ы. В вебморде уже просится вкладка с управлением пинами, типа кнопок "Вкл/выкл пин", чтобы можно было добавлять/удалять/редактировать кнопки - тогда контроллер лёгким движением превращается...

 

И "рассвет-закат"- вообще унисекс получится

 

Если не хотите навешивать преобразователи уровней для 3-х вольтовой периферии, то нужно снижать напряжение питания контроллера в ардуинской плате, а его стабильная работа на 3.3 - вольтовом питании гарантируется для тактовой не выше 8 Мгц.

Для 3-х вольтовой периферии, да еще и в условиях нехватки производительности, по-моему, самое удачное решение использовать несколько более мощный контроллер STM32. На Али продаются несколько вариаций плат с STM32F103C8T6 на борту, по ценнику будет соизмеримо с Мегой, функционал значительно богаче.
Единственный минус этого контроллера - на него тяжело переходить после программирования Меги, не совсем очевидно конфигурируется PLL тактового генератора (там частота кварца всего 8 МГц, а ядро работает на умноженной частоте), плюс раздельно тактируются отдельные модули контроллера, что ощутимо отличается от Меги. Если есть желание абстрагироваться от указанных сложностей, есть вариант создания кода для контроллера в среде Ардуино с использованием ардуинских библиотек. Сам такой вариант не пробовал, т. к. интересно было прочувствовать весь функционал.
Еще одна особенность контроллера - он не терпит 5-вольтовый ввод-вывод.
Из плюсов - быстрое риск ядро, в 4 раза большая тактовая частота. Очень быстрый (в 100 раз быстрее Меги) АЦП. Несколько контроллеров аппаратного spi и i2c. Причем spi значительно быстрее, чем хардварный spi Меги
, это очень заметно при подключении TFT дисплея. Также есть полноценный usb контроллер, в отличие от прокинутого в usb uart-а Меги.

 

А Вы пишете для STM?

 

То, что вы процитировали, относилось к работе программного клиентского 1-Wire кода на тактовой частоте процессора 8 МГц, и проблема там только в программном коде, а не в производительности процесора. При чём тут STM - ума не приложу.

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

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

 

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

Надо уже потихоньку обсасывать это дело со всех сторон, прежде, чем взяться за реализацию в черновом варианте.

 

Ну, сказать, что пишу, это, наверное, слишком сильно.
По работе использовал Атмеловские контроллеры: сначала 51-е, потом 90s2313, дальше пошли Меги.
Недавно обострился вопрос импортозамещения, а из отечественных более-менее достойными оказались контроллеры от Миландра по архитектуре сходные с STM ом. Для знакомства с архитектурой проще и дешевле было взять упомянутый STM.
Под него было написано несколько программ / библиотек, чтобы посмотреть, как работают его основные узлы. Дальше, характер работы поменялся на административный, а контроллеры остались для души, только, вот времени теперь на них не хватает.

 

Есть и на два канала
http://www.ebay.com/itm/112228416071?_trksid=p2057872.m2749.l2649&var=412575355697&ssPageName=STRK%3AMEBIDX%3AIT

 

@Anatoly8853, @DIYMan, наверное проще заказать модули BH1750 сразу с конвертером. Гуглятся по названию GY-30. Дороже аж на 20 центов, но позволят обойтись без лишней платы.
Так и поступлю

 

Самый шикарный вариант- это ежели в конфигураторе на вкладке правила в выборе действий наряду с "открыть\закрыть окна","следить за состоянием пина" и прочими, появится еще и "отправить смс".
Ну это для барышни (графини)
А для крестьянки (дворника) достаточно будет просто анализировать состояние пина.
ИМХО.

 

Т. е. отдельной галочкой, действие при срабатывании правила? Помимо выбора основного действия, например "открыть окна" - ставишь галочку "отправить СМС" и при срабатывании правила окна открываются и однократно отправляется СМС, так?

Тут вопрос такой интересный ещё: как учитывать однократность? Правила могут срабатывать N раз с момента подачи питания. Выставив один раз флаг, что мы уже отослали СМС для этого правила - мы до пересброса питания уже ничего не отправим.

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

 

Можно и так, не вопрос. Тут уж кому что удобней, что называется. Я уже упоминал, что у меня пока просто макет - до разводки датчиков для боевых условий ещё дойдёт не скоро.

 

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