Кстати, а что у DeviceHive с поддержкой спящих режимов в девайсах? Как я понимаю, в активном режиме потребление ESP8266 — порядка десятков или даже сотен миллиампер, что делает сомнительным создание сколько-нибудь автономных устройств на нем.
Вот здесь на хабре описаны эксперименты с введением модуля в спящий режим — для многих применений его поддержка — единственный ключ к автономности
Эх, еще бы устранить слово 'переходник' и железо, которое за ним стоит — иначе получается, что если WiFi-роутер поменял SSID или пароль, нужно доставать из шкафа USB <-> RS232 девайс плюс RS232 <-> UART-3.3 конвертер, все это соединять, вынимать все ESP8266 из всех углов дома, и перепрошивать. Неудобно.
Вернее, так: начальную конфигурацию конечно делать неудобно, а вот реконфигурацию можно наверное сделать и средствами самого DeviceHive, предусмотрев соответствующую команду
Отличное решение — когда-то разработчик, желающий вывести в Интернет свое устройство (если на борту был не *nix, конечно) был вынужден применять WiFi <-> UART или WiFi <-> SPI конвертеры по $30 за штуку (или как вариант — Zigbee за столько же и RaspPi как мост Zigbee — WiFi), плюс реализовывать кастомную логику обмена на серверной и клиентских (а на клиенте с ресурсами всегда напряг) сторонах.
С DeviceHive же для простых применений (типа открыть-закрыть жалюзи в комнате, включить-выключить кран, измерить температуру/освещенность), как я понимаю, даже не нужен отдельный МК — так как код выполняется в самом ESP8266, и если хватает выводов на простые функции, то за пару долларов реализуется полноценный IoT-enabled DIY-контроллер — что-то наподобие electricimp, только не требующий SD-сокета и технологической платы.
BTW, а как решается вопрос конфигурации ESP8266 'с нуля' для подсоединения к WiFi-сети?
Интересно, а каков оптимальный radix скажем для диапазона int32? 2, 16, 256? Если он мал, то велико количество итераций с генерацией промежуточных результатов, и длина списка в каждой ячейке велика. Если он большой — то сканирование самого radix-массива занимает время…
Интересно, что там не коммутационная матрица R-2R, которая требует log2(N) ключей, а линейный резистор с отводами, который требует полного дешифратора и N ключей — видимо именно для того, чтобы сохранить константным добавленное сопротивление канала. Но не в этом суть — интересен именно порядок величины шума, скажем цифрового резистора 100 кОм относительно обычного графитового того же номинала.
Насчет цифровых шумов с шины — тут дело даже не в трассировке — так как потенциометрическая часть у них by design висит в воздухе, схемотехнически аналоговая и цифровая части могут (и скорее всего не будут) вообще не иметь общих цепей. Дело в другом — крутые фронты цифры через паразитные емкости на кристалле скорее всего будут проникать в аналоговую часть — интересно, насколько сильно. Если у вас уже есть готовая конструкция регулятора громкости из второй части — это ведь можно легко проверить даже на слух
Интересно, а каков порядок значения теплового шума сабжей, как функции от количества скоммутированных МОП-ключей? В даташите навскидку не написано, а ведь каждый замкнутый МОП-канал — это шумовой ток. Соответственно, чем больше ключей замкнуто — тем выше его значение.
Можно попробовать провести такой эксперимент — взять малошумящий ОУ, охватить его ООС, например с коэффициентом 1:1000, посадить вход на землю, и оценить величину шума в варианте а) обычного резистора в плече ОС; b) digiPot'а c таким же сопротивлением.
Полосу частот для определенности можно волюнтаристски ограничить сверху, скажем, звуковым диапазоном, поставив на выходе ОУ обычный RC-фильтр со срезом 20-30 кГц.
Еще интересен порядок коммутационного шума в процессе обмена по i2c и/или изменения сопротивления — эти устройства полностью статические (то есть в отсуствие внешних изменений никаких тактовых сигналов внутри не тикает, которые, имея широкий спектр, неминуемо пролезли бы в выход) — а вот обмен на шине (даже с чужим устройством), и особенно, собственная перестройка должны обязательно отразиться на выходе
Да, динамикой можно красиво решить задачу — однако суть моей идеи в том, что в месте установки кнопки не нужно никаких дополнительных элементов вообще — так как гасящий резистор уже есть внутри кнопки. Массовый провод подкладывается под гайку крепления, и в МК систему идет всего один провод, а все остальное делается чисто программно. Долгого шунтирования же цепи не будет, т.к. алгоритм обработки нажатия, увидев первое, переведет выходной порт в 0, с короткими 1 только на время очередного опроса. Я вижу существенное преимущество вашего решения только в следующем (помимо того, что оно, конечно, красивое) — в возможности выполнять индикацию от МК системы в то время, пока кнопка нажата — если это в силу каких-то причин необходимо, то стоит выбрать его
И чтобы не писать несколько ответов — кнопки такие продаются на aliexpress.com, а вариант схемы с одним входом, развязанном диодами, конечно, работать не будет — это я загнул. Нужно будет использовать первый или второй вариант
BTW, некоторые кнопки имеют НЗ контакты (но они вроде как дороже, чем НР) — их можно включить последовательно со светодиодом/резистором, и проверять порт в режиме чтения на 1
Это прекрасно, а сам светодиод питать тоже паразиткой с шины? Чип-то получит команду на его включение, а кто даст энергию ему гореть? Или 1-wire переживет шунтирование светодиодом с резистором? ;)
на АЦП конечно да, только использовать каналы АЦП — роскошь для такого простого применения, мне кажется. Я тоже сначала думал сделать на АЦП или на каналах-компараторах — но решение на обычных портах ВВ имхо гораздо более универсальное.
можно, конечно, сместить диапазон delta-U при замкнутом и разомкнутом светодиоде так, чтобы он находился посередине порога переключения, например, включив в земляной провод 2-3 диода в прямом направлении.
Но, во-первых, это лишние элементы, во-вторых из монтажных соображений удобно, когда один из концов кнопки сидит на земле (корпусе), в третьих — помехозащищенность метода будет существенно хуже — смещение цифровой земли всего на 0.5 вольта (в начале статьи я упомянул про применение в автомобиле) сделает схему неработоспособной
не получится — так как светодиод с резистором и так притянут вход к нулю, даже если включить внутренний pull-up — так как сопротивление pull-up'а на два-три порядка больше, чем гасящего резистора — в итоге, на нем почти ничего не упадет, плюс светодиод под микротоком (ну допустим, 1 вольт) — и МК не почувствует разницы между закороченным и свободным светодиодом — оба уровня будут ниже входного порога
смысл в том, чтобы пересилить выход порта и притянуть его к нулю, и это притягивание заметил МК. Если просто закоротить диод, то резистор не позволит этого сделать — просто чуть увеличится выходной ток.
что-то шутки даже со смайлом в конце предложения идут не очень — добавил определенности, закавычив широкоизвестное название протокола во избежание нежелательных ассоциаций.
А вообще, в данном случае достаточно именно «проволочного» решения на «клиентской стороне» — без всяких контроллеров в кнопках as long as все можно сделать аппаратно-программно на «сервере»
маркетинговая ловушка. Надо было 1-wire еще и в тэги добавить, но пока держусь :)
вообще, при нынешних ценах на чипы, можно запросто рядом с каждой кнопкой расположить какую-нибудь тиньку, которая принимала-отправляла бы команды модуляцией по питающему проводу
Ну и если совсем занудствовать — если катоды диодов, активирующих линии опроса клавиатуры, подключить к стокам полевиков, активирующих разряды 7-сегментных индикаторов, то можно сэкономить три линии портов ВВ. Программно, конечно, придется привязать опрос клавиатуры к циклам индикации, но это несложно. Это практически стандартное решение в случаях, когда линий портов ВВ не хватает
А, и еще — не всякий светодиодный 7-сегментный индикатор, особенно зеленый (не знаю, какого цвета у вас) в режиме динамической индикации будет ярко светиться и питании регистра-защелки от +3.3 — так как даташит дает для его выходов 6мА вытекающего тока при +5, а даже этого мало для динамической индикации. Тут по-хорошему нужен либо индикатор повышенной яркости, либо регистр с повышенной нагрузочной способностью, либо набор p-канальных полевиков/p-n-p биполярников (хорошо бы в интегральном исполнении) для увеличения импульсного тока через сегменты до 4*Iном — тогда яркость будет на уровне.
Вот здесь на хабре описаны эксперименты с введением модуля в спящий режим — для многих применений его поддержка — единственный ключ к автономности
Вернее, так: начальную конфигурацию конечно делать неудобно, а вот реконфигурацию можно наверное сделать и средствами самого DeviceHive, предусмотрев соответствующую команду
С DeviceHive же для простых применений (типа открыть-закрыть жалюзи в комнате, включить-выключить кран, измерить температуру/освещенность), как я понимаю, даже не нужен отдельный МК — так как код выполняется в самом ESP8266, и если хватает выводов на простые функции, то за пару долларов реализуется полноценный IoT-enabled DIY-контроллер — что-то наподобие electricimp, только не требующий SD-сокета и технологической платы.
BTW, а как решается вопрос конфигурации ESP8266 'с нуля' для подсоединения к WiFi-сети?
Насчет цифровых шумов с шины — тут дело даже не в трассировке — так как потенциометрическая часть у них by design висит в воздухе, схемотехнически аналоговая и цифровая части могут (и скорее всего не будут) вообще не иметь общих цепей. Дело в другом — крутые фронты цифры через паразитные емкости на кристалле скорее всего будут проникать в аналоговую часть — интересно, насколько сильно. Если у вас уже есть готовая конструкция регулятора громкости из второй части — это ведь можно легко проверить даже на слух
Можно попробовать провести такой эксперимент — взять малошумящий ОУ, охватить его ООС, например с коэффициентом 1:1000, посадить вход на землю, и оценить величину шума в варианте а) обычного резистора в плече ОС; b) digiPot'а c таким же сопротивлением.
Полосу частот для определенности можно волюнтаристски ограничить сверху, скажем, звуковым диапазоном, поставив на выходе ОУ обычный RC-фильтр со срезом 20-30 кГц.
Еще интересен порядок коммутационного шума в процессе обмена по i2c и/или изменения сопротивления — эти устройства полностью статические (то есть в отсуствие внешних изменений никаких тактовых сигналов внутри не тикает, которые, имея широкий спектр, неминуемо пролезли бы в выход) — а вот обмен на шине (даже с чужим устройством), и особенно, собственная перестройка должны обязательно отразиться на выходе
И чтобы не писать несколько ответов — кнопки такие продаются на aliexpress.com, а вариант схемы с одним входом, развязанном диодами, конечно, работать не будет — это я загнул. Нужно будет использовать первый или второй вариант
BTW, некоторые кнопки имеют НЗ контакты (но они вроде как дороже, чем НР) — их можно включить последовательно со светодиодом/резистором, и проверять порт в режиме чтения на 1
Но, во-первых, это лишние элементы, во-вторых из монтажных соображений удобно, когда один из концов кнопки сидит на земле (корпусе), в третьих — помехозащищенность метода будет существенно хуже — смещение цифровой земли всего на 0.5 вольта (в начале статьи я упомянул про применение в автомобиле) сделает схему неработоспособной
А вообще, в данном случае достаточно именно «проволочного» решения на «клиентской стороне» — без всяких контроллеров в кнопках as long as все можно сделать аппаратно-программно на «сервере»
вообще, при нынешних ценах на чипы, можно запросто рядом с каждой кнопкой расположить какую-нибудь тиньку, которая принимала-отправляла бы команды модуляцией по питающему проводу