DIY 6-Канальный контроллер LED c тач-панелью "3.2"

[aquanavt 1]

Всем добрый вечер.

Читал, что vahegan хочет связать несколько ARDUINO или уже связал через модули Bluetooth.

В принципе идея отличная.

На ARDUINO есть шина I2C, очень интересная в плане того, что по ней можно связывать много устройств.

Такой вопрос, может кто пробовал это сделать? по шине I2C.

А зачем связывать Arduino через Блютус? (если речь об аквариумном контроллере).

По использованию i2с много примеров, например вот это

, или вот этот текст.

[vahegan 101]

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

 

Я предлагал организовать связь не через Bluetooth, а через модули nRF24L+. Они крайне дешевы, подключаются к контроллеру по SPI, и позволяют организовать сеть из 6 устройств - для акваконтроллера, думаю, этого вполне достаточно.

[ruslan.kuchma 1]

А зачем связывать Arduino через Блютус? (если речь об аквариумном контроллере).

По использованию i2с много примеров, например вот это видео, или вот этот текст.

Ну через радио модули не моя идея, но тоже смотрю в её сторону...

А связывать нужно в связи с тем, что одна mega не справиться со всеми возложенными на неё задачами, а если и справится то будет очень не стабильна, а это не очень хорошо...

Я придерживаюсь того, что пусть конструкция получится более дорогой, но более стабильной!!!

И если один из модулей заглючит зависнет, то всё остальное будет работать...

Я не рассматриваю arduino как только 6-ти канальный светильник, очень удобная и гибкая система, можно много чего наворотить...

Я солидарен с vahegan и тоже хочу чтоб мозг был один, а модулей можно много подкинуть, и управлять скажем ни одним аквариумом, а всеми...

Как то так....

Изменено 23 Октября 2013 пользователем ruslan.kuchma (см. историю изменений)

[ruslan.kuchma 1]

Я предлагал организовать связь не через Bluetooth, а через модули nRF24L+. Они крайне дешевы, подключаются к контроллеру по SPI, и позволяют организовать сеть из 6 устройств - для акваконтроллера, думаю, этого вполне достаточно.

Уважаемый vahegan, я в ближайшее время планирую это реализовывать, но ещё не совсем во всём разобрался, а именно идёт выбор протокола обмена данными, есть какие соображения по этому плану???

Изменено 23 Октября 2013 пользователем ruslan.kuchma (см. историю изменений)

[aquanavt 1]

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

 

Я предлагал организовать связь не через Bluetooth, а через модули nRF24L+. Они крайне дешевы, подключаются к контроллеру по SPI, и позволяют организовать сеть из 6 устройств - для акваконтроллера, думаю, этого вполне достаточно.

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

[ruslan.kuchma 1]

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

Вот, и я про то, для этого очень даже подходит I2C, но придётся писать свой протокол обмена и соответствующую библиотеку, или может уже есть готовая библиотека???

[aquanavt 1]

Ну через радио модули не моя идея, но тоже смотрю в её сторону...

А связывать нужно в связи с тем, что одна mega не справиться со всеми возложенными на неё задачами, а если и справится то будет очень не стабильна, а это не очень хорошо...

Я придерживаюсь того, что пусть конструкция получится более дорогой, но более стабильной!!!

И если один из модулей заглючит зависнет, то всё остальное будет работать...

Я не рассматриваю arduino как только 6-ти канальный светильник, очень удобная и гибкая система, можно много чего наворотить...

Я солидарен с vahegan и тоже хочу чтоб мозг был один, а модулей можно много подкинуть, и управлять скажем ни одним аквариумом, а всеми...

Как то так....

При правильном написании кода зависание модулей не проблема. У Arduino есть watchdog и возможность перезагрузки в случае зависания.

[aquanavt 1]

Вот, и я про то, для этого очень даже подходит I2C, но придётся писать свой протокол обмена и соответствующую библиотеку, или может уже есть готовая библиотека???

Вы что имеете в виду? Для работы с i2c есть готовые библиотеки, например для avr-gcc она называется Wire. Протокола там как такового нет, есть несколько методов, которые могут записать или прочитать несколько символов, да и все.

[ruslan.kuchma 1]

При правильном написании кода зависание модулей не проблема. У Arduino есть watchdog и возможность перезагрузки в случае зависания.

Да есть...

Но в любом случае одно главное устройство и несколько исполняемых стабильней...

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

 

Вы что имеете в виду? Для работы с i2c есть готовые библиотеки, например для avr-gcc она называется Wire. Протокола там как такового нет, есть несколько методов, которые могут записать или прочитать несколько символов, да и все.

Это я знаю, я и спрашиваю, может кто встречал где либо решение???...

[ruslan.kuchma 1]

Ладно, проехали, я планирую по I2C прицепить холодильник и авто-долив...

Сами по себе устройства будут автономные, но при необходимости их можно контролировать с главного блока.

Многие скажут нет в этом смысла... Но с таким же успехом можно сказать и про 6-ти канальный светильник, тогда можно и вообще без контролера обойтись, купить 6-ть таймеров за 3 "копейки" и будет вам счастье.....

Изменено 23 Октября 2013 пользователем ruslan.kuchma (см. историю изменений)

[svyaz 19]

ИМХО, как таковая "новизна" железа мало критична. Если Малина (модель Б) с 700Мгц процессором (можно разогнать до 1000), 512Мб памяти - это прошлый век, то Ардуино Мега c его 20Мгц процессором и менее 1Мб памяти - вообще каменный. Если Ардуино Мега может включать/выключать свет, то Малина с этим и подавно справится!

 

Я думаю, более важен размер сообщества (не пользователей, а разработчиков) . У Малины и Ардуино это сообщество немаленькое, а у Аллвинеровцев?

 

Также и вариабельность платформы играет роль. Малина - это грубо говоря две модификации, Ардуино с десяток (+ клоны, для которых заявлена 100% совместимость).

А у Аллвинеровцев с этим как?

Вот этот девайс, о котором вы пишете - это второе поколение в линейке, есть уже более свежие четырехядерные, с разгоном до 1800Мгц. А всего этой линейке чуть больше года - за это время они сменили 3 чипсета. Молодцы! А производители ПО за ними успевают портировать? На Малину портировано c десяток Линуксов, FreeBSD, NetBSD и еще с пяток систем, в том числе несколько реал-тайм. На Mk802 кроме Андроида и Убунту что-то есть?

 

Вы путаете, Allwinner это - Raspberry, у меня Rockchip (rk3066)

 

 

Я выше писал (купил жене 4-х ядерный RK3188) так что, я в курсе что там вышло.

И дело не в количестве портированных линуксов, на вскидку могу назвать те, которые я пробовал Picuntu (ubuntu), Debian, Gentoo.

Я остановился на последнем и эти строки пишу с устройства mk808, подключенного по встроенному wi-fi к моей домашней сети.

Идея в том, что само устройство (MK808) с установленным веб сервером будет находиться на контроллере ардуино и будет общаться с ним по uart.

 

Изменено 23 Октября 2013 пользователем svyaz (см. историю изменений)

[azh122 4]

rf433 как бы не ругали (мол старая, прошлый век и пр) работает весьма стабильно.

http://adatum.ru/delaem-sistemu-umny-j-dom-na-arduino-chast-1.html

http://adatum.ru/delaem-sistemu-umny-j-dom-na-arduino-chast-2.html

Плюс можно выключатели-розетки вешать. Датчики протечки.

А можно по тому же принципу просто по проводам (дабы модуль работает тупо - подал 5вольт на передатчик - теже 5 вольт получил на приемнике)

[vahegan 101]

Уважаемый vahegan, я в ближайшее время планирую это реализовывать, но ещё не совсем во всём разобрался, а именно идёт выбор протокола обмена данными, есть какие соображения по этому плану???

Разработка протокола, думаю, самый ответственный момент. Я думал на эту тему, но окончательное решение пока не нашел.

 

Думаю, каждое устройство в сети должно иметь свой ID, и они должны быть 2 типов: мастер и слейв. Мастер-устройство одно: то, которое отвечает за настройки, с тач-скрином. В протоколе должен быть некий набор комманд. Каждая команда начинается с ID устройства, которому оно адресовано. Также должны быть команды, которые относятся ко всем слейв-устройствам в сети (например, команда передать ID - чтобы мастер мог знать, сколько устройств доступны в сети на данный момент).

 

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

 

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

 

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

 

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

 

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

 

Да, но поскольку устройства, которыми управляют эти контроллеры, имеют свое питание, то это обычно не проблема. На худой конец, есть китайские блоки питания на пару ватт, я покупал где-то за 1-1.5 доллара штука. А по поводу измерения pH, редокс, температуры, солености и т.п. - у меня все это планируется как одно устройство. Я уже писал несколько раз, что есть довольно качественные датчики от Atlas Scientific, с маленькими интерфейсными платками к ним, которые передают измеренные данные через COM-порт (и калибруются через него же). То есть, под измерители/контроллеры у меня планируется отдельная платка Mega2560 (на ней 4 COM-порта), к которой подключаются эти датчики (pH, Redox, Salinity), плюс отдельно термодатчик на DS18B20 по one-wire, и автодолив. Для каждого датчика также предусматривается большой семисегментный индикатор, но органов ручного управления контроллер иметь не будет (все настройки только через тач-скрин на мастер-устройстве).

[aquanavt 1]

Вы путаете, Allwinner это - Raspberry, у меня Rockchip (rk3066)

Я выше писал (купил жене 4-х ядерный RK3188) так что, я в курсе что там вышло.

И дело не в колличестве портированных линуксов, на вскидку могу назвать те, которые я пробовал Picuntu (ubuntu), Debian, Gentoo.

Я остановился на последнем и эти строки пишу с устройства mk808, подключенным по встроенному wi-fi к моей домашней сети.

Идея в том, что само устройство с установленным веб сервером будет находиться на с контроллере ардуино и будет общаться с ним будет по uart.

 

Да, спутал, Аллвинер использовался в первой версии Mk808. На частоте 1200Мгц. Смысл не меняется - 1 год: 3 разных платформы. В Малине стоит АРМ11.

Дело конечно не в портированных линуксах, а в количестве разработчиков именно под эту платформу. Сдается мне, у Малины оно будет побольше, следовательно и найти документацию/ответы можно проще.

[kapelan 3]

ардуина достаточно мощная штука.

Разбивать ее на части из соображения производительности смысла нету.

[vahegan 101]

Плюс можно выключатели-розетки вешать. Датчики протечки.

О! Точно, про блок с 8 каналами управляемых розеток забыл. Тоже планируется с отдельным контроллером. Я, собственно, прикупил для этих целей силовой блок с 8шт. твердотельных реле. Достаточно прикрутить к нему какой-нибудь arduino nano и радиомодуль.

 

Датчики протечки лучше в общий блок к pH, ORP, и т.д.

[vahegan 101]

ардуина достаточно мощная штука.

Разбивать ее на части из соображения производительности смысла нету.

Проект Jarduino уже занимает существенную часть ресурсов Arduino Mega 2560, и попытки добавить новый код приводят к разнообразным глюкам (по видимому, из-за недостатка памяти). Наблюдал это лично. Кроме того, код очень запутанный и нерациональный. Начал было структурировать код, пока не надоело.

 

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

Изменено 23 Октября 2013 пользователем vahegan (см. историю изменений)

[kapelan 3]

Проект Jarduino уже занимает существенную часть ресурсов Arduino Mega 2560, и попытки добавить новый код приводят к разнообразным глюкам ...

может быть в Jarduino софте проблема а не в hardware?

[vahegan 101]

может быть в Jarduino софте проблема а не в hardware?

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

[aquanavt 1]

Разработка протокола, думаю, самый ответственный момент. Я думал на эту тему, но окончательное решение пока не нашел.

 

Думаю, каждое устройство в сети должно иметь свой ID, и они должны быть 2 типов: мастер и слейв. Мастер-устройство одно: то, которое отвечает за настройки, с тач-скрином. В протоколе должен быть некий набор комманд. Каждая команда начинается с ID устройства, которому оно адресовано. Также должны быть команды, которые относятся ко всем слейв-устройствам в сети (например, команда передать ID - чтобы мастер мог знать, сколько устройств доступны в сети на данный момент).

 

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

 

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

 

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

 

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

Платы от Atlas не самые дешевые. Sparky's Widgets предлагает дешевле.

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

[kapelan 3]

ну это старая идея: вместо оптимиизации софта - увеличить количество процессоров/памяти.

Счас мы имеем 8 ядерные Интелы с16 гиг памяти

[kapelan 3]

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

у меня на уровне имплементации :

www.youtube.com/watch?v=zFKk92H_HR8

сейчас расширяю функциональность : PH/ORP и управляемые розетки

проблем с производительностью нету.

Изменено 23 Октября 2013 пользователем kapelan (см. историю изменений)

[svyaz 19]

может быть в Jarduino софте проблема а не в hardware?

Даже если просто оптимизировать многократно повторяющиеся функции, можно выиграть около 8 кб флеш памяти.

Например в каждом мню присутствуют кнопки "Save" "Back" "Cancel" вместо того, чтобы каждый раз вызывать их полностью, я поместил их в void

 

void presCancel () { waitForIt ( canC[0], canC[1], canC[2], canC[3]); }

 

и теперь вызываю так presCancel (); каждая такая "кнопка" дает почти по 1кб экономии

 

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

Изменено 23 Октября 2013 пользователем svyaz (см. историю изменений)

[aquanavt 1]

ну это старая идея: вместо оптимиизации софта - увеличить количество процессоров/памяти.

Счас мы имеем 8 ядерные Интелы с16 гиг памяти

Эта идея инспирирована тем, что стоимость техники снижается, стоимость труда растет. В коммерческой разработке такой идеи придерживаются. Потому что время выхода на рынок важно, и время, за которое будет оказана поддержка, тоже. В домашней разработке, just for lulz, можно на чем угодно писать (например как этот демо ролик, конечно круто - в 64к все запихнуть, но это месяцы труда)

[svyaz 19]

проблем с производительностью нету.

Не в обиду, но у вас там практически ни чего и нету, там нечему тормозить.