Умный Дом по Ethernet
Умный Дом по Ethernet
Так как форум просматривают самые заядлые, прежде чем публиковать статью поделюсь здесь первыми фотками.
В качестве МК - Atmega168
TCP/IP стэк реализован для Atmega автором Guido Socher.
Ядро Linux знает программаторы типа USBasp без каких-либо драйверов.
Компиляция через gcc-avr под Linux
Прошивка через avrdude, который также умеет работать с таким типом программаторов.
Управление входами/выходами через HTTP. Себестоимость устройства крайне низкая. Фактически она складывается из 2-х микросхем и разъема MAG-Jack, который, к слову, самый дорогой (300 руб). Можно обойтись без него - обычным разъемом, но тогда нужно размещать некоторые дополнительные компоненты, что усложнит схемотехнику.
В качестве Ethernet-интерфейса используется микросхема ENC28J60В качестве МК - Atmega168
TCP/IP стэк реализован для Atmega автором Guido Socher.
Ядро Linux знает программаторы типа USBasp без каких-либо драйверов.
Компиляция через gcc-avr под Linux
Прошивка через avrdude, который также умеет работать с таким типом программаторов.
Управление входами/выходами через HTTP. Себестоимость устройства крайне низкая. Фактически она складывается из 2-х микросхем и разъема MAG-Jack, который, к слову, самый дорогой (300 руб). Можно обойтись без него - обычным разъемом, но тогда нужно размещать некоторые дополнительные компоненты, что усложнит схемотехнику.
Re: Умный Дом по Ethernet
Пять баллов!!!
Емкость на колодке питания - недоработка чернового варианта?
Для более обстоятельной беседы хочется увидеть схему устройства. Почему только 8 цифровых входов/выходов? Или 8 входов и 8 выходов?
Какими посылками (командами) управляется сей чУдный девайс?
Протокол SMNP реализован?
PS Мне наверное надо забрать свои слова о беготне с программатором...
Емкость на колодке питания - недоработка чернового варианта?
Для более обстоятельной беседы хочется увидеть схему устройства. Почему только 8 цифровых входов/выходов? Или 8 входов и 8 выходов?
Какими посылками (командами) управляется сей чУдный девайс?
Протокол SMNP реализован?
PS Мне наверное надо забрать свои слова о беготне с программатором...
Re: Умный Дом по Ethernet
Вот принципиальная схема, из которой многое понятно.
По входам/выходам могут быть незначительные комбинации, но в целом конфигурация такая. В чем смысл.
1) дешево
2) работает
2) 28 ног (что в МК, что в интерфейсе) реально запаять вручную. Это не 128-ногие пауки с микронными расстояниями между ногами.
Это не мое изобретение. Схема эта бродит по интернету довольно давно. Есть несколько сайтов, посвященных этой теме. Например, tuxgraphics, откуда я взял реализацию TCP/IP.
Управлять железкой легко! Либо через HTTP вот так (тестовая программа)
Ну и, разумеется, с любого компьютера любой программой на Perl, PHP, curl, wget и т.д.
Либо через UDP.
Поддержка SNMP есть! На том же tuxgraphics лежит прошивка на эту тему, а также множество других: программируемые таймеры, watchdog, автополив цветов, Modbus/TCPIP, сигнализация, мониторинг объектов, и т.д. Причем, есть даже прошивка для работы по Wi-Fi. Главное не то, что есть прошивки, а то, что есть исходники!
Сейчас пробую работать со входами/выходами и вообще тренируюсь писать на С, так как никогда раньше на нем не писал Заодно хочу в голове сформировать общие требования к такого рода девайсам в моем доме. А завтра заеду прикуплю 24-портовый гигабитных свитч. А то тут выяснилось неожиданно, что Ethernet-портов свободных нет...
По входам/выходам могут быть незначительные комбинации, но в целом конфигурация такая. В чем смысл.
1) дешево
2) работает
2) 28 ног (что в МК, что в интерфейсе) реально запаять вручную. Это не 128-ногие пауки с микронными расстояниями между ногами.
Это не мое изобретение. Схема эта бродит по интернету довольно давно. Есть несколько сайтов, посвященных этой теме. Например, tuxgraphics, откуда я взял реализацию TCP/IP.
Управлять железкой легко! Либо через HTTP вот так (тестовая программа)
Ну и, разумеется, с любого компьютера любой программой на Perl, PHP, curl, wget и т.д.
Либо через UDP.
Поддержка SNMP есть! На том же tuxgraphics лежит прошивка на эту тему, а также множество других: программируемые таймеры, watchdog, автополив цветов, Modbus/TCPIP, сигнализация, мониторинг объектов, и т.д. Причем, есть даже прошивка для работы по Wi-Fi. Главное не то, что есть прошивки, а то, что есть исходники!
Сейчас пробую работать со входами/выходами и вообще тренируюсь писать на С, так как никогда раньше на нем не писал Заодно хочу в голове сформировать общие требования к такого рода девайсам в моем доме. А завтра заеду прикуплю 24-портовый гигабитных свитч. А то тут выяснилось неожиданно, что Ethernet-портов свободных нет...
Re: Умный Дом по Ethernet
Если я правильно понял, в качестве базы Вы используете "HTTP/TCP with an atmega88 microcontroller" и еще только предстоит (или уже сделано? ) прикрутить SNMP, его реализацию я увидел только в "Ethernet host watchdog, 4.X".
Особенно интересует как, и возможно ли вообще, назначать пинам функции вход/выход из WEB-интерфейса устройства?
Пока не могу себе представить, как все это можно конфигурировать может поделитесь своими соображениями?Заодно хочу в голове сформировать общие требования к такого рода девайсам в моем доме.
Особенно интересует как, и возможно ли вообще, назначать пинам функции вход/выход из WEB-интерфейса устройства?
Re: Умный Дом по Ethernet
Не совсем понятно что вы имеете ввиду под назначением функций пинам. Аппаратно модуль будет подключаться к блоку с реле/симисторами или клеммами с защитой для сухого контакта. В этом смысле функции ввода/вывода будут закладываться на уровне прошивки. А как иначе? С другой стороны некоторое конфигурирование функциональности (триггеры, если... то...) можно будет осуществлять через HTTP записывая конфигурацию в EEPROM. Думаю, 512 байт в Atmega168 более чем достаточно для этих целей.
Насчет реализации протоколов, тут надо понять что нужно, а что нет. В принципе мне SNMP не нужен. Я хотел бы запрограммировать устройство так, чтобы оно:
1) управлялось короткими HTTP-запросами
2) отчитывалось о состоянии своих входов/выходов через HTTP по запросу сервера
3) при срабатывании сухого контакта или запрограммированных триггеров посылала серверу короткие HTTP-сообщения с обязательной дополнительной проверкой на уровне HTTP протокола о получении сообщения
То есть устройство должно уметь отвечать как полноценный Web-сервер для управления как посредством браузера, так и посредством простых скриптов или программ.
TCP, поверх которого работает HTTP гарантирует (в известных пределах, конечно) получение сообщений вместо SNMP (который чаще всего реализован поверх UDP), а дополнительная проверка на уровне HTTP сделает такую коммуникацию еще более надежной. Нет смысла в таком небольшой объеме памяти, каким обладает Atmega168, расширять набор поддерживаемых протоколов. Разве что по необходимости. Я так думаю.
Кстати, насчет распространения аудио-контента по дому. На таких штуках делают MP3 плееры и даже клиенты для Интернет-радио используя дополнительно, например, VLSI vs1053b (MP3, AAC++, WMA, FLAC decoder). Причем также конфигурируются через Web-интерфейс. Можно подключать к своему медиасерверу или использовать сервера в Интернете.
Насчет реализации протоколов, тут надо понять что нужно, а что нет. В принципе мне SNMP не нужен. Я хотел бы запрограммировать устройство так, чтобы оно:
1) управлялось короткими HTTP-запросами
2) отчитывалось о состоянии своих входов/выходов через HTTP по запросу сервера
3) при срабатывании сухого контакта или запрограммированных триггеров посылала серверу короткие HTTP-сообщения с обязательной дополнительной проверкой на уровне HTTP протокола о получении сообщения
То есть устройство должно уметь отвечать как полноценный Web-сервер для управления как посредством браузера, так и посредством простых скриптов или программ.
TCP, поверх которого работает HTTP гарантирует (в известных пределах, конечно) получение сообщений вместо SNMP (который чаще всего реализован поверх UDP), а дополнительная проверка на уровне HTTP сделает такую коммуникацию еще более надежной. Нет смысла в таком небольшой объеме памяти, каким обладает Atmega168, расширять набор поддерживаемых протоколов. Разве что по необходимости. Я так думаю.
Кстати, насчет распространения аудио-контента по дому. На таких штуках делают MP3 плееры и даже клиенты для Интернет-радио используя дополнительно, например, VLSI vs1053b (MP3, AAC++, WMA, FLAC decoder). Причем также конфигурируются через Web-интерфейс. Можно подключать к своему медиасерверу или использовать сервера в Интернете.
Re: Умный Дом по Ethernet
Я имел ввиду, что каждый пин может быть настроен как на вход, так и на выход без перепрошивки модуля. Допустим сегодня Вам нужно 5 выходов и 3 входа, а завтра 7 выходов и 1 вход и что, переписывать исходники и перешивать модуль? Мне кажется, что можно предусмотреть 1 байт в EEPROM, в котором 1 будет означать вход, а 0 выход.Не совсем понятно что вы имеете ввиду под назначением функций пинам. Аппаратно модуль будет подключаться к блоку с реле/симисторами или клеммами с защитой для сухого контакта. В этом смысле функции ввода/вывода будут закладываться на уровне прошивки. А как иначе?
Ну это так, мысли в слух. Естественно такой подход потребует соответствующей структуры всей программы и перед его реализацией надо ответить на вопрос - а зачем это нужно.
Вопрос о SNMP отпал.3) при срабатывании сухого контакта или запрограммированных триггеров посылала серверу короткие HTTP-сообщения с обязательной дополнительной проверкой на уровне HTTP протокола о получении сообщения
Re: Умный Дом по Ethernet
Продолжаю осваивать программирование МК.
TCP/IP стэк от tuxgraphics имеет определенные ограничения, прежде всего, на размер передаваемых данных. Все страницы должны помещаться в один TCP пакет. Размер HTML-страницы не должен превышать 550 байт. С одной стороны это мало, с другой, если вдуматься, для такого устройства более чем достаточно. Не порталы же на нем запускать.
Существует другие реализации TCP/IP для AVR. В частности есть порт uIP для AVR, который так и называется avr-uip и даже практически полноценный Web-сервер с поддержкой сетевой конфигурации, DHCP - проект uhttpd-avr. К сожалению, последний рассчитан на Atmega32 и выше. Объем скомпилированной программы составляет 24,5Кб и в Atmega168 не лезет. Особенно из uhttpd-avr ничего не выкинешь, поэтому я сконцентрировал свои усилия на прошивке от tuxgraphics, хотя по сравнению с avr-uip в коде чувствуется несколько пренебрежительное отношение к делу. А, может быть, показалось.
В общем, первым делом я все-таки сделал настройку IP адреса по сети и хранение настройки в EEPROM.
Дальше я планирую переделать работу функции, анализирующей URL и GET-запросы, так как в текущем виде с ней работать совершенно неудобно.
А далее вот как я представляю себе функционал прошивки этого устройства:
==
1. Возможность конфигурирования каждого входа и выхода, так как ENC28J60+ATMEGA168 ядро, к которому подключается плата с исполнителями, датчиками, конфигурация которой в зависимости от конечной задачи может быть разной.
2. Возможность отправлять в сеть информацию о (срабатывании датчиков, выхода за определенные пределы (если это аналоговые входы), другие события. Можно с помощью SNMP или любого иного стандартного протокола. Я предполагал вообще HTTP, чтобы центральный сервер получал информацию о всех событиях, происходящих с устройством.
3. Управление по HTTP всеми выходами
4. Конфигурирование входов и выходов таким образом что: Если это вход (скажем датчик сухого контакта) и он сработал, то необходимо п.2 отправить сообщение серверу и какое-то время ждать его ответа. Сервер может ответить какие выходы необходимо переключить или не ответить, тогда МК смотрит собственные настройки по умолчанию и переключает что-то сам.
==
Таким образом устройство получится, как мне кажется, наиболее универсальным.
В системах, где мозгом является ПК, такое устройство будет управляться им.
В распределенных системах, где нет единого мозга, устройство можно настраивать на собственную логику.
В системах с ПК при выходе из строя компьютера мы не останемся без света, так как устройство будет включать свет на основе алгоритма по умолчанию.
В любых системах у нас остается возможность вручную с помощью браузера (компьютера, мобильника, планшетника) управлять освещением при этом в системах с ПК последний будет регистрировать изменение выходов устройства.
==
Я связался с Александром, автором аналогичного девайса, но предназначенного для проигрывания Интернет-радио. Александр сам писал прошивку для Atmega и хорошо разбирается в C. Если у нас возникнут вопросы по программированию AVR, можно попробовать задавать вопросы. Он, кажется, даже зарегистрировался на форуме.
andrushka, Atmega168 имеет в своем распоряжении только 16Кб памяти для программного кода. С такими ресурсами не разбежишься. Опрашивать кнопочки и дергать релюшками - это пожалуйста, а интерпретатор PHP - это через чур.
TCP/IP стэк от tuxgraphics имеет определенные ограничения, прежде всего, на размер передаваемых данных. Все страницы должны помещаться в один TCP пакет. Размер HTML-страницы не должен превышать 550 байт. С одной стороны это мало, с другой, если вдуматься, для такого устройства более чем достаточно. Не порталы же на нем запускать.
Существует другие реализации TCP/IP для AVR. В частности есть порт uIP для AVR, который так и называется avr-uip и даже практически полноценный Web-сервер с поддержкой сетевой конфигурации, DHCP - проект uhttpd-avr. К сожалению, последний рассчитан на Atmega32 и выше. Объем скомпилированной программы составляет 24,5Кб и в Atmega168 не лезет. Особенно из uhttpd-avr ничего не выкинешь, поэтому я сконцентрировал свои усилия на прошивке от tuxgraphics, хотя по сравнению с avr-uip в коде чувствуется несколько пренебрежительное отношение к делу. А, может быть, показалось.
В общем, первым делом я все-таки сделал настройку IP адреса по сети и хранение настройки в EEPROM.
Дальше я планирую переделать работу функции, анализирующей URL и GET-запросы, так как в текущем виде с ней работать совершенно неудобно.
А далее вот как я представляю себе функционал прошивки этого устройства:
==
1. Возможность конфигурирования каждого входа и выхода, так как ENC28J60+ATMEGA168 ядро, к которому подключается плата с исполнителями, датчиками, конфигурация которой в зависимости от конечной задачи может быть разной.
2. Возможность отправлять в сеть информацию о (срабатывании датчиков, выхода за определенные пределы (если это аналоговые входы), другие события. Можно с помощью SNMP или любого иного стандартного протокола. Я предполагал вообще HTTP, чтобы центральный сервер получал информацию о всех событиях, происходящих с устройством.
3. Управление по HTTP всеми выходами
4. Конфигурирование входов и выходов таким образом что: Если это вход (скажем датчик сухого контакта) и он сработал, то необходимо п.2 отправить сообщение серверу и какое-то время ждать его ответа. Сервер может ответить какие выходы необходимо переключить или не ответить, тогда МК смотрит собственные настройки по умолчанию и переключает что-то сам.
==
Таким образом устройство получится, как мне кажется, наиболее универсальным.
В системах, где мозгом является ПК, такое устройство будет управляться им.
В распределенных системах, где нет единого мозга, устройство можно настраивать на собственную логику.
В системах с ПК при выходе из строя компьютера мы не останемся без света, так как устройство будет включать свет на основе алгоритма по умолчанию.
В любых системах у нас остается возможность вручную с помощью браузера (компьютера, мобильника, планшетника) управлять освещением при этом в системах с ПК последний будет регистрировать изменение выходов устройства.
==
Я связался с Александром, автором аналогичного девайса, но предназначенного для проигрывания Интернет-радио. Александр сам писал прошивку для Atmega и хорошо разбирается в C. Если у нас возникнут вопросы по программированию AVR, можно попробовать задавать вопросы. Он, кажется, даже зарегистрировался на форуме.
andrushka, Atmega168 имеет в своем распоряжении только 16Кб памяти для программного кода. С такими ресурсами не разбежишься. Опрашивать кнопочки и дергать релюшками - это пожалуйста, а интерпретатор PHP - это через чур.
Re: Умный Дом по Ethernet
Классная идея!
Возможно есть смысл в том, чтобы была возможность сконфигурировать аналоговые входы как цифровые.
PS Опечатка: "то необходимо п.3 отправить сообщению серверу" - наверное надо "то необходимо п. 2 отправить сообщениие серверу"
Время ожидания ответа сервера настраиваться будет?4. Конфигурирование входов и выходов таким образом что: Если это вход (скажем датчик сухого контакта) и он сработал, то необходимо п.3 отправить сообщению серверу и какое-то время ждать его ответа. Сервер может ответить какие выходы необходимо переключить или не ответить, тогда МК смотрит собственные настройки по умолчанию и переключает что-то сам.
Возможно есть смысл в том, чтобы была возможность сконфигурировать аналоговые входы как цифровые.
PS Опечатка: "то необходимо п.3 отправить сообщению серверу" - наверное надо "то необходимо п. 2 отправить сообщениие серверу"
Re: Умный Дом по Ethernet
Что сделано:
Теперь в прошивке что-то вроде меню и навигации по страницам
Управление всеми выходами, опрос всех входов
При срабатывании входа устройство теперь как Web-клиент обращается к серверу и по протоколу HTTP в GET-запросе передает параметры сработанного входа.
Какие есть проблемы:
TCP/IP стэк от tuxgraphics однопакетный, поэтому быстро работает и маленький. Под буфер пакета зарезервировано 550-600 байт. Никогда не задумывался сколько "весят" HTML-страницы. А тут такое. Ничего не лезет! Вместо того, чтобы сделать красиво, придется разбивать все управление устройством на много маленьких страниц. Например, можно было бы сделать настройку выходов на одной странице. Это наглядно и удобно. Но придется сначала выводить короткий перечень выходов, а потом настраивать каждый выход индивидуально. Попутно нашел в авторской прошивке ошибку. При переполнении буфера устройство виснет. Пришлось пофиксить. Можно было бы пытаться прикрутить uIP, но даже с маленьким стэком занято уже 80% Flash-памяти. Боюсь не умещу все задуманное в atmega168. Придется чем-то пожертвовать.
Насчет ответа сервера. Я пока планирую, что сервер должен дать ответ в этом же HTTP- сеансе. То есть устройство делает GET-запрос, а сервер выдает страничку с инструкциями. По локальной сети это работает мгновенно. Можно обращаться в Интернет по имени и резолвить ip-адрес через public DNS (например Google) или даже настраивать его в сетевой конфигурации, но я, наверное, выкину этот код из прошивки. Практической ценности в этом, пожалуй, нет, а сэкономить полтора килобайта можно. Если брать работу по локальной сети то задержку, наверное надо ставить минимальную. Думаю, не более секунды. Можно также ее хранить в EEPROM. Все это не проблема. Делается легко. Реальная проблема только одна - память И в наше то время...
Может быть, имеет смысл брать для таких задач Atmega32 или 64. Но и цена вырастет... тут вся суть, конечно, взять самые дешевые чипы.
Теперь в прошивке что-то вроде меню и навигации по страницам
Управление всеми выходами, опрос всех входов
При срабатывании входа устройство теперь как Web-клиент обращается к серверу и по протоколу HTTP в GET-запросе передает параметры сработанного входа.
Какие есть проблемы:
TCP/IP стэк от tuxgraphics однопакетный, поэтому быстро работает и маленький. Под буфер пакета зарезервировано 550-600 байт. Никогда не задумывался сколько "весят" HTML-страницы. А тут такое. Ничего не лезет! Вместо того, чтобы сделать красиво, придется разбивать все управление устройством на много маленьких страниц. Например, можно было бы сделать настройку выходов на одной странице. Это наглядно и удобно. Но придется сначала выводить короткий перечень выходов, а потом настраивать каждый выход индивидуально. Попутно нашел в авторской прошивке ошибку. При переполнении буфера устройство виснет. Пришлось пофиксить. Можно было бы пытаться прикрутить uIP, но даже с маленьким стэком занято уже 80% Flash-памяти. Боюсь не умещу все задуманное в atmega168. Придется чем-то пожертвовать.
Насчет ответа сервера. Я пока планирую, что сервер должен дать ответ в этом же HTTP- сеансе. То есть устройство делает GET-запрос, а сервер выдает страничку с инструкциями. По локальной сети это работает мгновенно. Можно обращаться в Интернет по имени и резолвить ip-адрес через public DNS (например Google) или даже настраивать его в сетевой конфигурации, но я, наверное, выкину этот код из прошивки. Практической ценности в этом, пожалуй, нет, а сэкономить полтора килобайта можно. Если брать работу по локальной сети то задержку, наверное надо ставить минимальную. Думаю, не более секунды. Можно также ее хранить в EEPROM. Все это не проблема. Делается легко. Реальная проблема только одна - память И в наше то время...
Может быть, имеет смысл брать для таких задач Atmega32 или 64. Но и цена вырастет... тут вся суть, конечно, взять самые дешевые чипы.
Re: Умный Дом по Ethernet
А можно посмотреть исходный код (HTML) какой нибудь странички, вдруг мысль появится.Никогда не задумывался сколько "весят" HTML-страницы. А тут такое. Ничего не лезет! Вместо того, чтобы сделать красиво, придется разбивать все управление устройством на много маленьких страниц.
Интересный подход! И на мой взгляд эффективный. Имя PHP-скрипта к которому будет обращаться устройство тоже лучше хранить в EEPROM (если возможно).Насчет ответа сервера. Я пока планирую, что сервер должен дать ответ в этом же HTTP- сеансе. То есть устройство делает GET-запрос, а сервер выдает страничку с инструкциями.
Думаю, этот кусок, можно смело выкидывать. Во внешний мир нужно выставлять сервер, а все обращения к устройству делать с его страничек.Можно обращаться в Интернет по имени и резолвить ip-адрес через public DNS (например Google) или даже настраивать его в сетевой конфигурации, но я, наверное, выкину этот код из прошивки.
Re: Умный Дом по Ethernet
Боюсь "техническими" методами размер страницы не уменьшить. Вот пример.THK писал(а):А можно посмотреть исходный код (HTML) какой нибудь странички, вдруг мысль появится.
<h1>IO Control</h1>
PD7: OFF <a href=/sec/?pg=ioc&act=d71>ON</a> <a href=/sec/?pg=ioc&act=d70>OFF</a><br>
Предположим у нас есть 8 выходов. 8 * 86 байт 688 байт. Уже не лезет, даже без заголовка и меню.
Можно управлять через переключение (toggle), что не очень удобно. Можно уменьшить длину параметров до 1-2 символов, но в целом ситуацию это не спасет.
Один выход. Перечень выходов со ссылкой. Переходя по ссылке у нас снова меню: управление/настройка. И уже переходя в настройку или управление мы получаем удобный механизм управления и видим состояние, но только по одному конкретному выходу. От кавычек отказались. Русские буквы не используем, чтобы не задавать encoding. Никаких <html><head><body> и пр. нет и быть не может. Конечно, не HTML5, но браузеры разберутся.
Интересный способ предложил автор в своей последней разработке. Фактически мы имеем дело со списком, таблицей. Он загоняет данные в массив, а HTML строит с помощью javascript. Но это очень экзотический способ, не очень удобный и не универсальный.
Re: Умный Дом по Ethernet
Да, Вы правы, можно только перевод строки убрать (-2байта).Боюсь "техническими" методами размер страницы не уменьшить.
И того 104 байта из 106 исходных, изуродовав Ваш пример сократил его до 78 байт (максимум до 73).
Всего на 8 выходов получается 624 или 584 байта, но во втором случае читаемость никакая.
Пощитал неправильно, заголовок не учел. Получилось 542 или 502 байта.
Вот вариант 542 б.
Код: Выделить всё
IO<br>O7:OFF <a href=/s/?p=i&a=71>ON</a> <a href=/s/?p=i&a=70>OFF</a><br>
PS Я что подумал, никто не заставляет писать код HTML по всем стандартам. Вот такой вариант странички выглядит вполне, весит 547 байт (Вы писали, что ограничение 550) и открывается корректно даже в IE.
Код: Выделить всё
<h1>Out</h1>O7:OFF <a href=/s/?p=i&a=71>ON</a> <a href=/s/?p=i&a=70>OFF</a><br>.....
Re: Умный Дом по Ethernet
Да-да. Для atmega мега-сокращенияА что касается мега-сокращений, можно с ними и смириться...
Я привел в пример 8 выходов. Но ведь еще есть аналоговые входы. При этом хочется оставить элементы навигации (в начало, назад). Поэтому, думаю, правильнее будет разбить управление на несколько "шагов". Мне важна универсальность и "масштабируемость" прошивки. Плохо, когда мы привязываемся к какой-то конкретной реализации. Ведь набор характеристик конкретного устройства может быть разным. Уменьшать размер сокращением имен параметров правильно. Я пока сделал длинные только по причине того, что в прошивке автора криво реализован разбор URL. Я случайно столкнулся с проблемой, когда ?p=conf&ip=192.168.0.15 у меня программа и в p и в ip записала 192.168.0.15. Автор решил не анализировать строку на предмет ? или & перед именем параметра. И так везде. Код, так сказать, очень оптимистичный. Мы в России так не привыкли
А вот сокращать пароль до одного символа /s/ я бы не стал... Даже в локальной сети. Ну хотя бы два.
Но все это детали. Я с оптимизмом смотрю на эту проблему. Думаю, если хватит времени за пару дней/недель вполне сделаю работающую прошивку.
Re: Умный Дом по Ethernet
Вы думаете для такого устройства масштабируемость важна? А как с памятью быть?Поэтому, думаю, правильнее будет разбить управление на несколько "шагов". Мне важна универсальность и "масштабируемость" прошивки.
Конечно с минимизацией я погорячился... Не подумал, что это был пароль.А вот сокращать пароль до одного символа /s/ я бы не стал...
Ну что же, будем ждать конечной реализации. Честно говоря, не знаю нужно-ли мне такое устройство, но все равно хочу! Очень идея интересная.
Re: Умный Дом по Ethernet
Насколько я понимаю, для работы АЦП нужно определенное время. Конечно, повесить на аналоговый вход кнопку можно, но опрашивать ее нужно иначе. Запускаем процесс конвертации и далее смотрим значения регистров ADCH/ADCL только после определенного количества циклов. То есть в отличие от цифрового входа, реакция МК на нажатие кнопки, подключенной к аналоговому входу будет не мгновенной. Нужно ли это в принципе? Или имеется ввиду, что если аналоговые входы не используются по назначению, то на них для экономии можно повесить те "кнопки/контакты/герконы", которые не требуют мгновенного ответа?THK писал(а):Возможно есть смысл в том, чтобы была возможность сконфигурировать аналоговые входы как цифровые.
Re: Умный Дом по Ethernet
Немного не так. Я имел в виду их использование как обычных линий порта PC (не как АЦП). Допустим нам надо 1 аналоговый вход, ставим галку напротив ADC1 - это аналог, а остальные 11 - цифра. Примерно так.Или имеется ввиду, что если аналоговые входы не используются по назначению, то на них для экономии можно повесить те "кнопки/контакты/герконы", которые не требуют мгновенного ответа?
Re: Умный Дом по Ethernet
Это, конечно, возможно.
Единственное, что смущает во всем этом. Конфигурирование ноги через Web - это здорово, Вход/Выход/АЦП... Но вот что будет с чипом, если мы по ошибке настроим вход на выход, подключим к нему кнопку, нажмем ее и включим выход? Можно придумать какие-нибудь другие комбинации. Если есть хоть малейшая вероятность за счет таких действий спалить ногу или чип - это обязательно произойдет.
Единственное, что смущает во всем этом. Конфигурирование ноги через Web - это здорово, Вход/Выход/АЦП... Но вот что будет с чипом, если мы по ошибке настроим вход на выход, подключим к нему кнопку, нажмем ее и включим выход? Можно придумать какие-нибудь другие комбинации. Если есть хоть малейшая вероятность за счет таких действий спалить ногу или чип - это обязательно произойдет.
Re: Умный Дом по Ethernet
Достаточно выходы МК подключить к разъёму через резисторы 33-51 Ома. Так реализован LPT-порт.Если есть хоть малейшая вероятность за счет таких действий спалить ногу или чип - это обязательно произойдет.
Пока все, что приходит в голову - сильно ограничивает функционал и/или гибкость устройства.Можно придумать какие-нибудь другие комбинации.
Re: Умный Дом по Ethernet
Пришла такая мысль:Можно придумать какие-нибудь другие комбинации.
Когда пин контроллера настроен на вход, можно включить или выключить "подтягивающие" резисторы. А как обстоят дела когда пин настроен на выход? Может есть режим типа "открытый коллектор"? В этом случае подтяжки 10к на +5В и отключение внутренних резисторов развеют все Ваши опасения.
Завтра буду смотреть документацию.
PS Пока мне удалось спалить пин ATmega8 случайно подав на него 12В...
Re: Умный Дом по Ethernet
ТНК, спасибо за рекомендации. Я, так сказать, начинающий в AVR. Насчет встроенных подтягивающих резисторов понял. Буду рад, если дадите еще какие-нибудь рекомендации именно в плане защиты устройства.
Сегодня изучил и протестировал работу с аналоговыми входами (весь вечер крутил потенциометр), разобрался с регистрами. В принципе все понятно, но и тут есть повод задуматься. Где-то достаточно 8-битной конвертации, а где-то желательно использовать 10-битную (предполагаю с высокоточными датчиками вполне может пригодится). Выносить это в настройки? Не перебор ли? Хотя с другой стороны иметь прошивку с возможностью настройки большого числа параметров работы чипа вместо традиционного программирования может быть удобно.
Сегодня изучил и протестировал работу с аналоговыми входами (весь вечер крутил потенциометр), разобрался с регистрами. В принципе все понятно, но и тут есть повод задуматься. Где-то достаточно 8-битной конвертации, а где-то желательно использовать 10-битную (предполагаю с высокоточными датчиками вполне может пригодится). Выносить это в настройки? Не перебор ли? Хотя с другой стороны иметь прошивку с возможностью настройки большого числа параметров работы чипа вместо традиционного программирования может быть удобно.