Не могли бы Вы в соотв. ветке привести фото и описание? Я вот нагреватель никак выбрать не могу и не могу решить, делать ли ванну верикальной и прозрачной, как у многих в сети, или это излишнее украшательство.
Мне не жалко, но сам я им недоволен. Делалось "по быстрому" из того, что было под рукой. А под рукой было только электромагнитное реле, потому от ПИДа отказался - больно часто щелкало бы на большой нагрузке - быстро бы из строя вышло. Завёл гистерезис и просто включаю/выключаю реле при определённых температурах. А система сильно инерционная, так что температура осциллирует возле целевой точки на несколько градусов вверх и вниз. Для персульфата это нормально, но некрасиво как-то.
С нагревателем и конструкцией у меня тоже всё просто - из того, что было под рукой.
Киловаттная электроплитка, купленная в хозмаге по принципу "чем дешевле, тем лучше". На неё ставлю обычную кастрюлю, а в кастрюлю опускаю ванночку с раствором. Таким образом раствор оказывается в "водяной бане".
Ванночек у меня много разных размеров (для разных размеров плат). Сама по себе ванночка - это пластиковая такая хрень в которой всякие готовые салаты продаются. Я их купил всех размеров за копейки в том же хозмаге. К краям прикрепил палочки которые опираются на края кастрюли. Т.е. палочки на краях, а весь корпус ванночки внутрь кастрюли попадает. И ванночка с раствором оказывается в "водяной бане".
Датчик опускаю в кастрюлю, т.е. в чистую воду, а не в раствор персульфата, ибо хрен его знает как он там себя поведёт.
Ну, а плата - 45-ая тинька, 3-знаковый семисегментник для температуры, трёхногий RG светодиод (жетый - недогрето, зелёный - ок, красный - перегрето), три кнопки для установки целевой температуры (меньше-установить-больше). Собственно всё.
Я сейчас не дома, как приду, могу сфоткать, но думаю, Вы всё итак поняли.
А так - да, типа "не горжусь" я этим устройством, но службу свою тянет исправно. И на том ему спасибо.
Больше сотни строк, что очевидно никак "реализую протокол в несколько строк"
А чё, полтораста это не "несколько"? Ну, это оценочно - по мне, так "несколько".
Logik пишет:
И остальные проблемы, теже что и у wdrakula.
Нет, Вы не поняли - у меня нет никаких проблем. Устройство спит всё время, когда не измеряет, так что скорость - совсем не проблема ни разу.
А вот если бы я решил использовать I2C (Вы говорите, что он лучше) - у меня была бы большая проблема - пина бы не хватило на 45-ой тиньке!
Поймите Вы, не бывает ни "лучше", ни "хуже" безотносительно задачи. В какой-то задаче лучше одно, а в какой-то другое. Критерии "лучшести" у разных задач разные.
///эластичности протокола ХВАТАЕТ на обработку прерывния таймера в Ардуино.
Так свет клином не сошелся на прерывании таймера (системного времени очевидно). И т.к. протокол в "пару строк" ну никак не ложится. Выход очевиден - либку клепать. А клепая либку в какойто момент осознаеш что она не на один проект нужна (что в общем то тривиально)))), возникает проклятое стремление к некоторой универсальности. Ну хотяб 2-3 датчика, поиск их номера, ну и чтоб остальному в проекте не мешало.
А дальше все печально. И в конце возникает понимание, что тоже самое на i2c - сильно много проще было бы.
ПС. i2c у меня к "лапам" не привязан, ногодрыг-с, понимаетели. Потому реальный плюс 1ware - один пин да пару проводов. Не часто в проекте все до одного пины заняты, а провода, если не далеко, вобще не проблема.
ЕвгенийП, wdrakula, расточители, аэратор у меня только один и планируется на поение птичек, а вибромоторчиков от телефонов навалом. А пока, вообще ручками покачиваю.))))
Я тоже частенько думаю, та ну нах это аэратор - бульки от него - не видно ни хрена - выключаю и либо покачиваю ручками, либо так периодически "включу на чуть-чуть и снова выключаю".
Поймите Вы, не бывает ни "лучше", ни "хуже" безотносительно задачи. В какой-то задаче лучше одно, а в какой-то другое. Критерии "лучшести" у разных задач разные.
Безусловно, сужу с своей колокольни опыта. И задача не одна уже решена. И соответственно обобщив я и пришел к таким выводам. Да, вполне допускаю что может быть так что не хватает одного пина и i2c отсутствует (иначе можна к существующей шине довесить). Но у меня такого случая за десятки проектов не было, может потому что с тини не связывался. А вот ситуаций когда при работе с 1ware луп тормозит сильней дозволеного или прерывания сбивают чтение 1ware (а запрещать их нельзя, в них весь смысл проекта) чуть ли не каждый раз когда датчик в сложном проекте оказывается.
Ну, а я с тини работаю постоянно и "борьба за пин" - ежедневное явление. Даже высоковольтный программатор купил специально ради того, чтобы пин "ресет" можно было как цифровой использовать. Отсюда у нас и естетственная разница в оценках. Одному лучше одно, другому - другое.
Так в такой борьбе как раз логично иметь одну шину на все случаи жизни. И тут снова i2c лучший претендент. На неё все поцеплять, в т.ч. и термометр. Но вощето я не понимаю смысла возни с тиньками как для дома. Экономия копеешная, и габариты но сравнению с чистым 328р, без обвески, не сильно и выигрывают. А с обвеской и подавно. В чем интерес к "простейшим"?
Вы знаете, это на самом деле, как говорят "проблема моя и моего психиатра". Нет, серьёзно. Всё, что я делаю с электроникой - чистое хобби ради удовольствия от процесса. А вот удовольствие я всегда получал именно от работы с ограниченными ресурсами. Например, в детстве и юности я занимался фехтованием, но не признавал никакого оружия, кроме рапиры (самое ограниченное оружие - ни ударов в руки/ноги/спину, ни режущих ударов - ничего). В молодости много и успешно играл в Core Wars до тех пор, пока стандарт ассемблера не был расширен с 10 инструкций до 16 (а потом и больше). Когда расширили, я потерял интерес. А с тиньками. Иногда я делаю на 328, конечно, но до последнего стараюсь обойтись тинькой. И дело тут не в цене и размере, а в неком вызове, типа "на меге и дурак сделает, а ты тут попробуй". Ну, вот как-то так - "проблема моя и моего психиатра".
Я в детстве занимался именно рапирой. И ее ограничения, привычные опытным спортсменам, позволили мне, тогда 10-летнему мальчишке, выиграть дуэль (пока тренер не видит) у старшего.
Пока он красиво отбивал мой клинок,я ждал, когда он откроет ноги ... и килограмма 3-4 силы засадил в бедро... не спортивно, признаю, но я ВЫИГРАЛ! Ходить он не мог ровно до вечера, а синяк держался черным неделю.
Я вот сам ни резу не юзал, но мне интересно, кто-нибудь пользуеь измерение температуры, имеющееся в самой атмеге 328? Она ж умеет и температуру мерять. Кто-нибудь пользует?
Да, не, прочитать её я и сам сумею, вопрос использует ли это кто-то на практике. С одной стороны там ведь не температура окружающего воздуха, а температура кристалла, т.е. вроде как "цена на овёс". Но в DS3231 точно также, но там эту температуру тем не менее активно используют в изделиях, а здесь, я что-то ни у кого не встречал.
С одной стороны там ведь не температура окружающего воздуха, а температура кристалла, т.е. вроде как "цена на овёс". Но в DS3231 точно также, но там эту температуру тем не менее активно используют в изделиях, а здесь, я что-то ни у кого не встречал.
А какой смысл измерять температуру внутри девайса? Что Атмегой, что 3231. Если только к радиатору силовому приклеить.)))) ИМХО?
Подскажите как реализовать проект. Изначально подаем команду на расчет температуры.
ds.reset();
ds.write(0xCC);
ds.write(0x44);
Далее поиск всех датчиков на 1-ware линии.
ds.reset_search();
while (ds.search(addr))
{
if ( OneWire::crc8( addr, 7) == addr[7])
{
ds.reset();
ds.select(addr);
ds.write(0xBE);
Можно как-то реализовать поиск датчиков несколько раз в подряд. Предположим датчиков 5 при первом поиске из-за "вспышке на луне" нашлись всего 2 их надо запомнить и произвести повторный поиск датчиков. Если находятся еще новые адреса (остальные 3 из 5), то добавить их в общий массив датчиков и вывести.
Читайте не два байта как Вы это делаете, а скречпад целиком. В нём есть контрольная сумма. Неисправный или отсутствующий датчик никогда не дадут правильной контрольной суммы.
Дадут. Замкни DQ на землю и CRC с датчика совпадёт с расчётным CRC в программе. Проверено "электроникой" и уже не один год!
А про прерывания при формировании интервалов Вы вобще не вспоминрали. А что будет если оно будет?
Датчик "выплюнет" то, что ему положено в рамках таймингов а дурдуине не хватит времени всё это обработать и по итогу получим очень "гнусный" плавающий глюк, отловить который ой как не просто.
Можно как-то реализовать поиск датчиков несколько раз в подряд.
Можно, но не нужно. Поиск датчиков происходит очень медленно, в несколько этапов. Тратить на это время - моветон. Проще завести массив из номеров датчиков и опрашивать их адресно. В массиве можно завести дополнительное байтовое поле, (например) старший бит отвечает за присутствие датчика на шине и 7-мь остальных в роли счётчика ошибок по шине.
Можно поступить ещё продвинутее - в самом датчике есть 2 байта в EEPROM , можно их использовать, они энергонезависимые!
А можно и ещё коечо попродвинутее, но не в этой серии )))
Можно как-то реализовать поиск датчиков несколько раз в подряд.
Можно, но не нужно. Поиск датчиков происходит очень медленно, в несколько этапов. Тратить на это время - моветон. Проще завести массив из номеров датчиков и опрашивать их адресно. В массиве можно завести дополнительное байтовое поле, (например) старший бит отвечает за присутствие датчика на шине и 7-мь остальных в роли счётчика ошибок по шине.
Можно поступить ещё продвинутее - в самом датчике есть 2 байта в EEPROM , можно их использовать, они энергонезависимые!
А можно и ещё коечо попродвинутее, но не в этой серии )))
Вся сложность в разных датчиках и в их количестве. Я не могу привязываться к определенным это делает систему зависимой от датчиков. А время на повторный поиск есть.
Тут кто-то выше писал про философию... так вот, гоООораздо сложнее придумать саму концепцию программы, чем написать её.
По поводу 1W шины в нете много копий и стрел сломали, прежде чем прийти к общему знаменателю.
И он был описан мной выше - делаем стэк или динамический массив из номеров и пользуемся. Это работает у меня уже более 2-х лет. Никаких проблем вроде нет.
Про концепции верно сказано. Но есть еще конфликт концепций. Концепция изделия в целом с концепциями работы частей устройства. И наконец неумение "программиста" программировать с помощью концепций. Мол скопипастим примерные скетчи из интернета и вперед к реализации.
Опять же надо учитывать логистику прохождения сообщений. Если расположить по надежности передачи или приема сигнала для различных шин, то шина передачи на этих датчика является самая ненадежная и надо организовать работу с помощью этой шины, как самая зашумленная. То есть почти как интернетовская.
Я обычно адреса датчиков в EEPROM храню массивом. В софте датчики указываю по их индексу в массиве, эти индексы и определяют где датчик расположен, как называть и т.д. При старте приложения делаю поиск по сети, если результат поиска совпал с списком в EEPROM - ок, молча работаем. Если не все нашлись - сообщение что такие и такие отсутствуют. Если нашелся новый датчик и исчез старый - замена, сообщение и записываю новый в EEPROM вместо старого. Это типа базовый функционал. Расширенный функционал может в отдельном приложении быть. Там запись в EEPROM всей таблицы адресов как констант прописанных прямо в этом софте (если мне известны они то чего стеснятся), вывод этой таблицы и в сириал, поиск всех датчиков и сохранение в произвольном порядке в EEPROM, перестановка указанных адресов в массиве в EEPROM по команде с сириала. Расширенный функционал место занимает и как правило нужен только при первом запуске.
В совсем простом коде могу и в софт номера вшить. На днях такое писал, два датчика если температура одного ниже чем другого - включается вентилятор. Чего мудрить. Но поиск и проверка при старте все равно будут, уж больно сеть ненадежная. Поиск у меня с калбеком на каждый найденный, так удобней и универсальней.
Я обычно адреса датчиков в EEPROM храню массивом. В софте датчики указываю по их индексу в массиве, эти индексы и определяют где датчик расположен, как называть и т.д. При старте приложения делаю поиск по сети, если результат поиска совпал с списком в EEPROM - ок, молча работаем. Если не все нашлись - сообщение что такие и такие отсутствуют. Если нашелся новый датчик и исчез старый - замена, сообщение и записываю новый в EEPROM вместо старого. Это типа базовый функционал. Расширенный функционал может в отдельном приложении быть. Там запись в EEPROM всей таблицы адресов как констант прописанных прямо в этом софте (если мне известны они то чего стеснятся), вывод этой таблицы и в сириал, поиск всех датчиков и сохранение в произвольном порядке в EEPROM, перестановка указанных адресов в массиве в EEPROM по команде с сириала. Расширенный функционал место занимает и как правило нужен только при первом запуске.
В совсем простом коде могу и в софт номера вшить. На днях такое писал, два датчика если температура одного ниже чем другого - включается вентилятор. Чего мудрить. Но поиск и проверка при старте все равно будут, уж больно сеть ненадежная. Поиск у меня с калбеком на каждый найденный, так удобней и универсальней.
Алгоритм правильный, но.... Что будет если датчик просто оторвали? А я предложил более прямое решение на мой взгляд. Возможно не быстрое, двоичного поиска и сравнения датчиков. Если за 2 раза не нашлись значит паника и этот датчик действительно отсутствует.
Зачем хранить, переписывать, если можно вообще не привязывается к датчику. Но потратить чуть больше времени на поиск?
Но некто не может помочь с написанием данного опроса.
Как так не привязываться к датчику. Пользователю нужно температуру знать в некотором конкретном месте, например "за тумбочкой". А для этого нужно знать что "за тумбочкой" стоит именно датчик с адресом 564589659... Это и есть привязка
//Что будет если датчик просто оторвали?
В таком случае при поиске по сети не обнаружится допустим наш 564589659... а в массиве EEPROM он есть, соответственно будет выведено сообщение "датчик за тумбочкой сдох".
У меня легкое ощущение что слово "поиск" мы немного по разному понимаем. Я имею в виду что в сети 1W есть некоторая процедура, позволяющая определить адреса всех устройств подключенных к ней. При этом изначально мы вообще ничего о них и их кол-ве не знаем. Это и есть "поиск по сети", по сети добавляю чтоб отличать от поиска в массиве. Так?
Как так не привязываться к датчику. Пользователю нужно температуру знать в некотором конкретном месте, например "за тумбочкой". А для этого нужно знать что "за тумбочкой" стоит именно датчик с адресом 564589659... Это и есть привязка
//Что будет если датчик просто оторвали?
В таком случае при поиске по сети не обнаружится допустим наш 564589659... а в массиве EEPROM он есть, соответственно будет выведено сообщение "датчик за тумбочкой сдох".
У меня легкое ощущение что слово "поиск" мы немного по разному понимаем. Я имею в виду что в сети 1W есть некоторая процедура, позволяющая определить адреса всех устройств подключенных к ней. При этом изначально мы вообще ничего о них и их кол-ве не знаем. Это и есть "поиск по сети", по сети добавляю чтоб отличать от поиска в массиве. Так?
Да говорил про сделать повтор поиска по сети. У меня идет сбор информации и отправка на сервер, а сервер разруливает где какой датчик стоит. И если данные пришли на сервер без одного датчика значит он оборван. (в свое время Arduino должно сделать все возможное и невозможное для сканирования и поска всех датчиков на линии)
вообще не понимаю проблемы, дать программе (устройству) номер датчика. Зато всё чётко и ясно работает. И не нужно никаких "сервер разруливает где какой датчик стоит" (а кстати как он это делает О_О)
Не важно, есть сеть или нет. Лучше руководствоваться есть ли последние данные температуры с датчика. Не устарели ли они для дальнейшей работы. Опрос датчиков и работа с получении температур должны быть разнесена по времени и работать не зависимо друг от друга.
Да говорил про сделать повтор поиска по сети. У меня идет сбор информации и отправка на сервер, а сервер разруливает где какой датчик стоит. И если данные пришли на сервер без одного датчика значит он оборван. (в свое время Arduino должно сделать все возможное и невозможное для сканирования и поска всех датчиков на линии)
Ну дак если устройство не знает скоко/каких датчиков должно быть, так как же оно решит все ли датчики доступны? Тут или сервер (он то знает что есть пропажа) пнет устройство, мол повтори поиск, не все есть. Ну а это протокол обмена расширять. Или устройство должно таки знать и следить все ли датчики доступны, тут есть варианты: сервер задаст массив датчиков, устройство само хранит этот массив постоянно, устройство само составляет его из соображений по максимуму устройств. На крайняк вместо массива можно ограничится количеством датчиков. Если при поиске найдено меньше чем должно быть - повторяем поиск.
А вообще проблема архитектурная, как правило обнаружение и обработка ошибок происходит на том уровне где они возникли.
Не важно, есть сеть или нет. Лучше руководствоваться есть ли последние данные температуры с датчика.
Я так понял что там проблема не во время опроса, а при поиске устройств не зная сколько их должно быть. Не все находятся и соответственно не опрашиваются.
Не важно, есть сеть или нет. Лучше руководствоваться есть ли последние данные температуры с датчика.
Я так понял что там проблема не во время опроса, а при поиске устройств не зная сколько их должно быть. Не все находятся и соответственно не опрашиваются.
Скорее всего так.
Но как показывает практика на следующий опрос датчиков все хорошо.
Опять же Вы неправильно ставите вопрос. К примеру у Вас есть смартфон. Вы хотите на нем зайти в Интернет. Вопрос: Как ваше устройство должно Вам это обеспечить. Ответ:Никак. Это должны сделать Вы зайдя в раздел Настройки и подключить оператора или ВАЙФАЙ, и затем автопоиск . Причем не вообще а конкретный канал ВАЙФАЙ или конкретного оператора. Вот так и здесь . 1- в вашем устройстве должен быть режим ручной настройки под новый датчик температуры и куда его показание подключить.
ПС: Это все ясно,но народу лень и сложно это делать, вот и ищут чудо-библиотеку с чудо-кодом.
Предположим датчиков 5 при первом поиске из-за "вспышке на луне" нашлись всего 2 их надо запомнить и произвести повторный поиск датчиков. Если находятся еще новые адреса (остальные 3 из 5), то добавить их к общей куче датчиков и отобразить предположим в мониторе порта. На выходе за два прохода он должен найти все которые есть на линии не зная об их количестве.
Предположим датчиков 5 при первом поиске из-за "вспышке на луне" нашлись всего 2 их надо запомнить и произвести повторный поиск датчиков.
пост 78 по нему вопрос? если да, то там OneWire и как я понял DS18x20 (х = В или S) ?!!
маленький вопрос как у ТС вообще какой-то код выходит при наличии более одного датчика при безадресном запросе???
ds.reset_search(); while (ds.search(addr) после этого все ДЦАТЬ датчиков начинают дружно слать свой адрес в шину и учитывая Открытый Коллктор этих датчиков таки у них это получается :)
Или я динозавр и отстал от прогресса?
это не "вспышке на луне", а озарение получить "правильно" хотя бы 2 адреса двух датчиков верно.
Предположим датчиков 5 при первом поиске из-за "вспышке на луне" нашлись всего 2 их надо запомнить и произвести повторный поиск датчиков.
пост 78 по нему вопрос? если да, то там OneWire и как я понял DS18x20 (х = В или S) ?!!
Да по 78 посту. DS18B20 средством OneWire
Гриша пишет:
маленький вопрос как у ТС вообще какой-то код выходит при наличии более одного датчика при безадресном запросе???
ds.reset_search(); while (ds.search(addr) после этого все ДЦАТЬ датчиков начинают дружно слать свой адрес в шину и учитывая Открытый Коллктор этих датчиков таки у них это получается :)
Или я динозавр и отстал от прогресса?
это не "вспышке на луне", а озарение получить "правильно" хотя бы 2 адреса двух датчиков верно.
Все верно, но из-за вспашке на луне периодически не доходит адрес с датчиков.
пока шутку выше придумывал наткнулься на LM75A в ЧипДипе. 20 р. И2С, SOT-8, влагозащиту самому придумать придется
Не могли бы Вы в соотв. ветке привести фото и описание? Я вот нагреватель никак выбрать не могу и не могу решить, делать ли ванну верикальной и прозрачной, как у многих в сети, или это излишнее украшательство.
Мне не жалко, но сам я им недоволен. Делалось "по быстрому" из того, что было под рукой. А под рукой было только электромагнитное реле, потому от ПИДа отказался - больно часто щелкало бы на большой нагрузке - быстро бы из строя вышло. Завёл гистерезис и просто включаю/выключаю реле при определённых температурах. А система сильно инерционная, так что температура осциллирует возле целевой точки на несколько градусов вверх и вниз. Для персульфата это нормально, но некрасиво как-то.
С нагревателем и конструкцией у меня тоже всё просто - из того, что было под рукой.
Киловаттная электроплитка, купленная в хозмаге по принципу "чем дешевле, тем лучше". На неё ставлю обычную кастрюлю, а в кастрюлю опускаю ванночку с раствором. Таким образом раствор оказывается в "водяной бане".
Ванночек у меня много разных размеров (для разных размеров плат). Сама по себе ванночка - это пластиковая такая хрень в которой всякие готовые салаты продаются. Я их купил всех размеров за копейки в том же хозмаге. К краям прикрепил палочки которые опираются на края кастрюли. Т.е. палочки на краях, а весь корпус ванночки внутрь кастрюли попадает. И ванночка с раствором оказывается в "водяной бане".
Датчик опускаю в кастрюлю, т.е. в чистую воду, а не в раствор персульфата, ибо хрен его знает как он там себя поведёт.
Ну, а плата - 45-ая тинька, 3-знаковый семисегментник для температуры, трёхногий RG светодиод (жетый - недогрето, зелёный - ок, красный - перегрето), три кнопки для установки целевой температуры (меньше-установить-больше). Собственно всё.
Я сейчас не дома, как приду, могу сфоткать, но думаю, Вы всё итак поняли.
А так - да, типа "не горжусь" я этим устройством, но службу свою тянет исправно. И на том ему спасибо.
О вей'з мир!
Этой эластичности протокола ХВАТАЕТ на обработку прерывния таймера в Ардуино.
Такая формулировка Вас устроит???? Зануда!
думаю, Вы всё итак поняли.
Понял, спасибо. Думаю, что все ж буду делать вертикальную и стеклянную, штоп за процессом следить.... еще и с подсветкой,
... короче с блэкджеком и дамами ;) ;) ;)
Больше сотни строк, что очевидно никак "реализую протокол в несколько строк"
А чё, полтораста это не "несколько"? Ну, это оценочно - по мне, так "несколько".
И остальные проблемы, теже что и у wdrakula.
Нет, Вы не поняли - у меня нет никаких проблем. Устройство спит всё время, когда не измеряет, так что скорость - совсем не проблема ни разу.
А вот если бы я решил использовать I2C (Вы говорите, что он лучше) - у меня была бы большая проблема - пина бы не хватило на 45-ой тиньке!
Поймите Вы, не бывает ни "лучше", ни "хуже" безотносительно задачи. В какой-то задаче лучше одно, а в какой-то другое. Критерии "лучшести" у разных задач разные.
Да, зашел бедный ТС, задал маленький вопросик, а его по самые уши нагрузили. Даж заглядывать боится.))))
Понял, спасибо. Думаю, что все ж буду делать вертикальную и стеклянную, штоп за процессом следить.... еще и с подсветкой,
... короче с блэкджеком и дамами ;) ;) ;)
Ей бы еще вибратор, в хорошем смысле.))))
Понял, спасибо. Думаю, что все ж буду делать вертикальную и стеклянную, штоп за процессом следить.... еще и с подсветкой,
... короче с блэкджеком и дамами ;) ;) ;)
Ей бы еще вибратор, в хорошем смысле.))))
;););)... Я Вас понял.
Ставят внизу аэратор от аквариума, пузырьки создают достаточную вибрацию и перемешивание раствора, заодно.
Ей бы еще вибратор, в хорошем смысле.))))
Я кидаю аквариумный аэратор в ванночку. Дешево и сердито.
Анекдот про "в хорошем смысле", конечно же знаете?
///эластичности протокола ХВАТАЕТ на обработку прерывния таймера в Ардуино.
Так свет клином не сошелся на прерывании таймера (системного времени очевидно). И т.к. протокол в "пару строк" ну никак не ложится. Выход очевиден - либку клепать. А клепая либку в какойто момент осознаеш что она не на один проект нужна (что в общем то тривиально)))), возникает проклятое стремление к некоторой универсальности. Ну хотяб 2-3 датчика, поиск их номера, ну и чтоб остальному в проекте не мешало.
А дальше все печально. И в конце возникает понимание, что тоже самое на i2c - сильно много проще было бы.
ПС. i2c у меня к "лапам" не привязан, ногодрыг-с, понимаетели. Потому реальный плюс 1ware - один пин да пару проводов. Не часто в проекте все до одного пины заняты, а провода, если не далеко, вобще не проблема.
Да, зашел бедный ТС, задал маленький вопросик, а его по самые уши нагрузили. Даж заглядывать боится.))))
форум - удел смелых ))))
Анекдот про "в хорошем смысле", конечно же знаете?
Вы про: "...шо, занял денег и не вернул?! -Да нет, я - в хорошем смысле!", про этот?
Ага :)))
ЕвгенийП, wdrakula, расточители, аэратор у меня только один и планируется на поение птичек, а вибромоторчиков от телефонов навалом. А пока, вообще ручками покачиваю.))))
А пока, вообще ручками покачиваю.))))
Я тоже частенько думаю, та ну нах это аэратор - бульки от него - не видно ни хрена - выключаю и либо покачиваю ручками, либо так периодически "включу на чуть-чуть и снова выключаю".
Поймите Вы, не бывает ни "лучше", ни "хуже" безотносительно задачи. В какой-то задаче лучше одно, а в какой-то другое. Критерии "лучшести" у разных задач разные.
Безусловно, сужу с своей колокольни опыта. И задача не одна уже решена. И соответственно обобщив я и пришел к таким выводам. Да, вполне допускаю что может быть так что не хватает одного пина и i2c отсутствует (иначе можна к существующей шине довесить). Но у меня такого случая за десятки проектов не было, может потому что с тини не связывался. А вот ситуаций когда при работе с 1ware луп тормозит сильней дозволеного или прерывания сбивают чтение 1ware (а запрещать их нельзя, в них весь смысл проекта) чуть ли не каждый раз когда датчик в сложном проекте оказывается.
Ну, а я с тини работаю постоянно и "борьба за пин" - ежедневное явление. Даже высоковольтный программатор купил специально ради того, чтобы пин "ресет" можно было как цифровой использовать. Отсюда у нас и естетственная разница в оценках. Одному лучше одно, другому - другое.
Нормальная ситуация.
Так в такой борьбе как раз логично иметь одну шину на все случаи жизни. И тут снова i2c лучший претендент. На неё все поцеплять, в т.ч. и термометр. Но вощето я не понимаю смысла возни с тиньками как для дома. Экономия копеешная, и габариты но сравнению с чистым 328р, без обвески, не сильно и выигрывают. А с обвеской и подавно. В чем интерес к "простейшим"?
В чем интерес к "простейшим"?
Если "для себя" - просто спорт.
А если для дела, то интерес в энергопотреблении. Несравнимо меньше едят.
Устройство на батарейке невообразимо на 328, а на тиньке - велкам!
В чем интерес к "простейшим"?
Вы знаете, это на самом деле, как говорят "проблема моя и моего психиатра". Нет, серьёзно. Всё, что я делаю с электроникой - чистое хобби ради удовольствия от процесса. А вот удовольствие я всегда получал именно от работы с ограниченными ресурсами. Например, в детстве и юности я занимался фехтованием, но не признавал никакого оружия, кроме рапиры (самое ограниченное оружие - ни ударов в руки/ноги/спину, ни режущих ударов - ничего). В молодости много и успешно играл в Core Wars до тех пор, пока стандарт ассемблера не был расширен с 10 инструкций до 16 (а потом и больше). Когда расширили, я потерял интерес. А с тиньками. Иногда я делаю на 328, конечно, но до последнего стараюсь обойтись тинькой. И дело тут не в цене и размере, а в неком вызове, типа "на меге и дурак сделает, а ты тут попробуй". Ну, вот как-то так - "проблема моя и моего психиатра".
Понял. Оба ответа в общем об одном.
Не трогаю тиньку дальше.
удивительно тасует события судьба!
Я в детстве занимался именно рапирой. И ее ограничения, привычные опытным спортсменам, позволили мне, тогда 10-летнему мальчишке, выиграть дуэль (пока тренер не видит) у старшего.
Пока он красиво отбивал мой клинок,я ждал, когда он откроет ноги ... и килограмма 3-4 силы засадил в бедро... не спортивно, признаю, но я ВЫИГРАЛ! Ходить он не мог ровно до вечера, а синяк держался черным неделю.
Я вот сам ни резу не юзал, но мне интересно, кто-нибудь пользуеь измерение температуры, имеющееся в самой атмеге 328? Она ж умеет и температуру мерять. Кто-нибудь пользует?
В последней версии SysInfo_for_Arduino добавлен вывод с внутреннего датчика температуры:
http://arduino.ru/forum/programmirovanie/sysinfo-arduino?page=1#comment-...
Да, не, прочитать её я и сам сумею, вопрос использует ли это кто-то на практике. С одной стороны там ведь не температура окружающего воздуха, а температура кристалла, т.е. вроде как "цена на овёс". Но в DS3231 точно также, но там эту температуру тем не менее активно используют в изделиях, а здесь, я что-то ни у кого не встречал.
С одной стороны там ведь не температура окружающего воздуха, а температура кристалла, т.е. вроде как "цена на овёс". Но в DS3231 точно также, но там эту температуру тем не менее активно используют в изделиях, а здесь, я что-то ни у кого не встречал.
А какой смысл измерять температуру внутри девайса? Что Атмегой, что 3231. Если только к радиатору силовому приклеить.)))) ИМХО?
А какой смысл измерять температуру внутри девайса? Что Атмегой, что 3231. Если только к радиатору силовому приклеить.)))) ИМХО?
Вот я тоже так всегда думал, разве что для того чтобы понять, что пора включать/выключать принудительное охлаждение.
Но вижу столько проектов в которых температуру с 3231 гордо показывают на семисегментниках :)))
Но вижу столько проектов в которых температуру с 3231 гордо показывают на семисегментниках :)))
Чем бы дите не тешилось.)))))
Здравствуйте.
Подскажите как реализовать проект. Изначально подаем команду на расчет температуры.
ds.reset();
ds.write(0xCC);
ds.write(0x44);
Далее поиск всех датчиков на 1-ware линии.
ds.reset_search();
Можно как-то реализовать поиск датчиков несколько раз в подряд. Предположим датчиков 5 при первом поиске из-за "вспышке на луне" нашлись всего 2 их надо запомнить и произвести повторный поиск датчиков. Если находятся еще новые адреса (остальные 3 из 5), то добавить их в общий массив датчиков и вывести.
то проверяйте контрольную сумму.
Читайте не два байта как Вы это делаете, а скречпад целиком. В нём есть контрольная сумма. Неисправный или отсутствующий датчик никогда не дадут правильной контрольной суммы.
Дадут. Замкни DQ на землю и CRC с датчика совпадёт с расчётным CRC в программе. Проверено "электроникой" и уже не один год!
А про прерывания при формировании интервалов Вы вобще не вспоминрали. А что будет если оно будет?
Датчик "выплюнет" то, что ему положено в рамках таймингов а дурдуине не хватит времени всё это обработать и по итогу получим очень "гнусный" плавающий глюк, отловить который ой как не просто.
Можно как-то реализовать поиск датчиков несколько раз в подряд.
Можно, но не нужно. Поиск датчиков происходит очень медленно, в несколько этапов. Тратить на это время - моветон. Проще завести массив из номеров датчиков и опрашивать их адресно. В массиве можно завести дополнительное байтовое поле, (например) старший бит отвечает за присутствие датчика на шине и 7-мь остальных в роли счётчика ошибок по шине.
Можно поступить ещё продвинутее - в самом датчике есть 2 байта в EEPROM , можно их использовать, они энергонезависимые!
А можно и ещё коечо попродвинутее, но не в этой серии )))
Можно как-то реализовать поиск датчиков несколько раз в подряд.
Можно, но не нужно. Поиск датчиков происходит очень медленно, в несколько этапов. Тратить на это время - моветон. Проще завести массив из номеров датчиков и опрашивать их адресно. В массиве можно завести дополнительное байтовое поле, (например) старший бит отвечает за присутствие датчика на шине и 7-мь остальных в роли счётчика ошибок по шине.
Можно поступить ещё продвинутее - в самом датчике есть 2 байта в EEPROM , можно их использовать, они энергонезависимые!
А можно и ещё коечо попродвинутее, но не в этой серии )))
Вся сложность в разных датчиках и в их количестве. Я не могу привязываться к определенным это делает систему зависимой от датчиков. А время на повторный поиск есть.
Тут кто-то выше писал про философию... так вот, гоООораздо сложнее придумать саму концепцию программы, чем написать её.
По поводу 1W шины в нете много копий и стрел сломали, прежде чем прийти к общему знаменателю.
И он был описан мной выше - делаем стэк или динамический массив из номеров и пользуемся. Это работает у меня уже более 2-х лет. Никаких проблем вроде нет.
Про концепции верно сказано. Но есть еще конфликт концепций. Концепция изделия в целом с концепциями работы частей устройства. И наконец неумение "программиста" программировать с помощью концепций. Мол скопипастим примерные скетчи из интернета и вперед к реализации.
Опять же надо учитывать логистику прохождения сообщений. Если расположить по надежности передачи или приема сигнала для различных шин, то шина передачи на этих датчика является самая ненадежная и надо организовать работу с помощью этой шины, как самая зашумленная. То есть почти как интернетовская.
А какой смысл измерять температуру внутри девайса? Что Атмегой, что 3231. Если только к радиатору силовому приклеить.)))) ИМХО?
Имеет смысл только если Мега основное время находится в слипе. Тогда это будет измерение температуры окружающей среды.)
Я обычно адреса датчиков в EEPROM храню массивом. В софте датчики указываю по их индексу в массиве, эти индексы и определяют где датчик расположен, как называть и т.д. При старте приложения делаю поиск по сети, если результат поиска совпал с списком в EEPROM - ок, молча работаем. Если не все нашлись - сообщение что такие и такие отсутствуют. Если нашелся новый датчик и исчез старый - замена, сообщение и записываю новый в EEPROM вместо старого. Это типа базовый функционал. Расширенный функционал может в отдельном приложении быть. Там запись в EEPROM всей таблицы адресов как констант прописанных прямо в этом софте (если мне известны они то чего стеснятся), вывод этой таблицы и в сириал, поиск всех датчиков и сохранение в произвольном порядке в EEPROM, перестановка указанных адресов в массиве в EEPROM по команде с сириала. Расширенный функционал место занимает и как правило нужен только при первом запуске.
В совсем простом коде могу и в софт номера вшить. На днях такое писал, два датчика если температура одного ниже чем другого - включается вентилятор. Чего мудрить. Но поиск и проверка при старте все равно будут, уж больно сеть ненадежная. Поиск у меня с калбеком на каждый найденный, так удобней и универсальней.
Я обычно адреса датчиков в EEPROM храню массивом. В софте датчики указываю по их индексу в массиве, эти индексы и определяют где датчик расположен, как называть и т.д. При старте приложения делаю поиск по сети, если результат поиска совпал с списком в EEPROM - ок, молча работаем. Если не все нашлись - сообщение что такие и такие отсутствуют. Если нашелся новый датчик и исчез старый - замена, сообщение и записываю новый в EEPROM вместо старого. Это типа базовый функционал. Расширенный функционал может в отдельном приложении быть. Там запись в EEPROM всей таблицы адресов как констант прописанных прямо в этом софте (если мне известны они то чего стеснятся), вывод этой таблицы и в сириал, поиск всех датчиков и сохранение в произвольном порядке в EEPROM, перестановка указанных адресов в массиве в EEPROM по команде с сириала. Расширенный функционал место занимает и как правило нужен только при первом запуске.
В совсем простом коде могу и в софт номера вшить. На днях такое писал, два датчика если температура одного ниже чем другого - включается вентилятор. Чего мудрить. Но поиск и проверка при старте все равно будут, уж больно сеть ненадежная. Поиск у меня с калбеком на каждый найденный, так удобней и универсальней.
Алгоритм правильный, но.... Что будет если датчик просто оторвали? А я предложил более прямое решение на мой взгляд. Возможно не быстрое, двоичного поиска и сравнения датчиков. Если за 2 раза не нашлись значит паника и этот датчик действительно отсутствует.
Зачем хранить, переписывать, если можно вообще не привязывается к датчику. Но потратить чуть больше времени на поиск?
Но некто не может помочь с написанием данного опроса.
Как так не привязываться к датчику. Пользователю нужно температуру знать в некотором конкретном месте, например "за тумбочкой". А для этого нужно знать что "за тумбочкой" стоит именно датчик с адресом 564589659... Это и есть привязка
//Что будет если датчик просто оторвали?
В таком случае при поиске по сети не обнаружится допустим наш 564589659... а в массиве EEPROM он есть, соответственно будет выведено сообщение "датчик за тумбочкой сдох".
У меня легкое ощущение что слово "поиск" мы немного по разному понимаем. Я имею в виду что в сети 1W есть некоторая процедура, позволяющая определить адреса всех устройств подключенных к ней. При этом изначально мы вообще ничего о них и их кол-ве не знаем. Это и есть "поиск по сети", по сети добавляю чтоб отличать от поиска в массиве. Так?
Как так не привязываться к датчику. Пользователю нужно температуру знать в некотором конкретном месте, например "за тумбочкой". А для этого нужно знать что "за тумбочкой" стоит именно датчик с адресом 564589659... Это и есть привязка
//Что будет если датчик просто оторвали?
В таком случае при поиске по сети не обнаружится допустим наш 564589659... а в массиве EEPROM он есть, соответственно будет выведено сообщение "датчик за тумбочкой сдох".
У меня легкое ощущение что слово "поиск" мы немного по разному понимаем. Я имею в виду что в сети 1W есть некоторая процедура, позволяющая определить адреса всех устройств подключенных к ней. При этом изначально мы вообще ничего о них и их кол-ве не знаем. Это и есть "поиск по сети", по сети добавляю чтоб отличать от поиска в массиве. Так?
Да говорил про сделать повтор поиска по сети. У меня идет сбор информации и отправка на сервер, а сервер разруливает где какой датчик стоит. И если данные пришли на сервер без одного датчика значит он оборван. (в свое время Arduino должно сделать все возможное и невозможное для сканирования и поска всех датчиков на линии)
вообще не понимаю проблемы, дать программе (устройству) номер датчика. Зато всё чётко и ясно работает. И не нужно никаких "сервер разруливает где какой датчик стоит" (а кстати как он это делает О_О)
Не важно, есть сеть или нет. Лучше руководствоваться есть ли последние данные температуры с датчика. Не устарели ли они для дальнейшей работы. Опрос датчиков и работа с получении температур должны быть разнесена по времени и работать не зависимо друг от друга.
Да говорил про сделать повтор поиска по сети. У меня идет сбор информации и отправка на сервер, а сервер разруливает где какой датчик стоит. И если данные пришли на сервер без одного датчика значит он оборван. (в свое время Arduino должно сделать все возможное и невозможное для сканирования и поска всех датчиков на линии)
Ну дак если устройство не знает скоко/каких датчиков должно быть, так как же оно решит все ли датчики доступны? Тут или сервер (он то знает что есть пропажа) пнет устройство, мол повтори поиск, не все есть. Ну а это протокол обмена расширять. Или устройство должно таки знать и следить все ли датчики доступны, тут есть варианты: сервер задаст массив датчиков, устройство само хранит этот массив постоянно, устройство само составляет его из соображений по максимуму устройств. На крайняк вместо массива можно ограничится количеством датчиков. Если при поиске найдено меньше чем должно быть - повторяем поиск.
А вообще проблема архитектурная, как правило обнаружение и обработка ошибок происходит на том уровне где они возникли.
Я так понял что там проблема не во время опроса, а при поиске устройств не зная сколько их должно быть. Не все находятся и соответственно не опрашиваются.
Я так понял что там проблема не во время опроса, а при поиске устройств не зная сколько их должно быть. Не все находятся и соответственно не опрашиваются.
Скорее всего так.
Но как показывает практика на следующий опрос датчиков все хорошо.
Как реализовать программно повторный поиск?
ПС: Это все ясно,но народу лень и сложно это делать, вот и ищут чудо-библиотеку с чудо-кодом.
Но как показывает практика на следующий опрос датчиков все хорошо.
Как реализовать программно повторный поиск?
А как реализован первичный поиск? Так же и повторный делать, не вижу в чем сложность.
Мне нужен более умный поиск.
Предположим датчиков 5 при первом поиске из-за "вспышке на луне" нашлись всего 2 их надо запомнить и произвести повторный поиск датчиков. Если находятся еще новые адреса (остальные 3 из 5), то добавить их к общей куче датчиков и отобразить предположим в мониторе порта. На выходе за два прохода он должен найти все которые есть на линии не зная об их количестве.
del
Мне нужен более умный поиск.
Предположим датчиков 5 при первом поиске из-за "вспышке на луне" нашлись всего 2 их надо запомнить и произвести повторный поиск датчиков.
пост 78 по нему вопрос? если да, то там OneWire и как я понял DS18x20 (х = В или S) ?!!
маленький вопрос как у ТС вообще какой-то код выходит при наличии более одного датчика при безадресном запросе???
ds.reset_search(); while (ds.search(addr) после этого все ДЦАТЬ датчиков начинают дружно слать свой адрес в шину и учитывая Открытый Коллктор этих датчиков таки у них это получается :)
Или я динозавр и отстал от прогресса?
это не "вспышке на луне", а озарение получить "правильно" хотя бы 2 адреса двух датчиков верно.
Мне нужен более умный поиск.
Предположим датчиков 5 при первом поиске из-за "вспышке на луне" нашлись всего 2 их надо запомнить и произвести повторный поиск датчиков.
пост 78 по нему вопрос? если да, то там OneWire и как я понял DS18x20 (х = В или S) ?!!
Да по 78 посту. DS18B20 средством OneWire
маленький вопрос как у ТС вообще какой-то код выходит при наличии более одного датчика при безадресном запросе???
ds.reset_search(); while (ds.search(addr) после этого все ДЦАТЬ датчиков начинают дружно слать свой адрес в шину и учитывая Открытый Коллктор этих датчиков таки у них это получается :)
Или я динозавр и отстал от прогресса?
это не "вспышке на луне", а озарение получить "правильно" хотя бы 2 адреса двух датчиков верно.
Все верно, но из-за вспашке на луне периодически не доходит адрес с датчиков.