Всё по DS18(B/S)20.

[-=Vovka=-]

Самое большое неудобство при параллельном включении датчиков, это когда один выходит из строя и не дает общаться с другими!
Подумайте, сколько "теплых" слов в адрес разработчика будет отправлено, когда из за вышедшего из строя одного датчика перестанет функционировать все устройство? Например, в инкубаторе на 1000 яиц? И как назло в это время никого поблизости не было!
Потом, как понять какой из датчиков вышел из строя? Тупо менять вбивая их номера? А если датчиков с десяток или более, а техпроцесс чувствителен к изменению температуры? А если обслуживающему персоналу закрыт доступ к настройкам? .....
Лично я теперь стараюсь придерживаться правила: один датчик - один пин порта.

[Gudd-Head]

Это вы уже в отказоустойчивость ударились, это немного не то.
С таким же успехом можно сказать, что для подключения "один датчик - один пин порта" надо тянуть соотв. количество проводов вместо 2-х (3-х).
Мы обсуждаем программный вопрос этого дела.

[djrec]

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

[HHIMERA]

А зачем вам номер датчика??? Он уже не нужен... Вся прелесть подсоединения на разные пины... что пофигу номер и можно цеплять/менять датчики на ходу...

[ARV]

А зачем вам номер датчика??? Он уже не нужен... Вся прелесть подсоединения на разные пины... что пофигу номер и можно цеплять/менять датчики на ходу...

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

не_оффтоп: номер датчика - это количествнная характеристика проекта, т.е. у него не 1 датчик, а 2 или более. но чтобы это понять, надо умерить свою гордыню великого разработчика и знатока душ человеческих.

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

Код: Выделить всё

uint8_t pin_mask = _BV(PB0); // сначала работаем с линией 0

uint8_t get_bit(void){
   return PINB & pin_mask != 1;
}

то есть все функции вывода и ввода битов, а так же импульса RESET, надо переделать по аналогии (остальное можно не трогать)

тогда будете делать так:

Код: Выделить всё

// первый датчик
pin_mask = _BV(PB0);

int temperature_1 = temp_18b20();

// второй датчик
pin_mask = _BV(PB2);

int temperature_2 = temp_18b20();

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

[HHIMERA]

номер датчика - это количествнная характеристика проекта, т.е. у него не 1 датчик, а 2 или более. но чтобы это понять, надо умерить свою гордыню великого разработчика и знатока душ человеческих.

Ну высрал так высрал... Да хоть десять датчиков... или двадцать... если они на разных пинах,то всё определяется количеством занятых пинов, а не номерами датчиков...
Кому-то АВР явно весь мозг выел...

[ARV]

HHIMERA, если вы что-то пытались возразить мне - напрасно, я не читаю ваш бред.

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

простите, модераторы, за оффоп...

[HHIMERA]

А я наоборот... твой бред читаю... он веселит...
Особенно про UART в теме PIC... откровенно посмешило...

[djrec]

А как то можно использовать не маску, а переменную для замены 4го на 5 пин и обратно?

[BOB51]

Робятки...
Ежли несколько датчиков на сетке - то вроде алгоритм поиска/активации по заданному адресу выполнятся должен (SEARCH ROM [F0h]/READ ROM [33h]/MATCH ROM [55h]). А не простое обращение к "какому-то датчику" с посредства SKIP ROM [CCh] в командном пакете - тогда и проблем с "несколькими на проволочке" не будет. Притом неисправный никак на линию не повлияет - разве что КЗ задаст. Чего касательно привязки к объекту - выяснить индивидуальный номер и соответственно в ЕЕПРОМке прописать его за заданным объектом. Опять же индивидуальное творчество программиста...
Программное обеспечение конечно гораздо посложнее будет - но еше спорно, что удобнее - несколько датчиков по разным лапам или все на один канал с выборкой по индивидуальному коду датчика.
В данном случае насчет привязки к конкретному МК... штука спорная - алгоритмы даташитов микроЛАН на любом МК соорудить можно. Теперь о защите от отказов - есть три варианта - обрыв, КЗ и нарушение целостности пакета.
Обрыв - можно определить по отсутствию ответа датчика на момент цикла сброса/обнаружения присутствия по тому, что ответ от датчика не пришел;
КЗ - периодическая проверка линии данных на "неспровоцированный 0" и косвенно по несовпадению CRC в принятом пакете;
Вот только воспринял ли датчик переданные данные или во время передачи КЗ нарисовалось мы не знаем - с момента цикла сброса/обнаружения присутствия до его повторения в пакете приема состояние линии не знаем... Не помешало бы еще контролировать линию данных на КЗ перед каждым слотом записи и после передачи командного пакета...

[ARV]

А как то можно использовать не маску, а переменную для замены 4го на 5 пин и обратно?

я же вам про переменную и объяснял только в примере упоминал 0 и 2 пины

[HHIMERA]

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

Вот и я о том... всё зависит от квалификации и конечного результата... но некоторые упорно настаивают на истинности своего протухшего мировозрения...

[HHIMERA]

А как то можно использовать не маску, а переменную для замены 4го на 5 пин и обратно?

Делайте как вам удобно и как знаете/умеете... главное чтобы вам всё было понятно... тогда и работать будет...

Я на STM32 дёргал через ДМА половинку порта (8 бит) или порт (16 бит) целиком... т.е. опрос всех датчиков одновременно... Никакие номера там и даром не нужны были... Всё хардварно... по окончанию просто всё парсилось и разгребалось... на КЗ... на наличие/отсутствие датчика... на CRC... и прочее...
Для одного датчика тупо делал на таймере... тоже хардварно... по флагу просто выгребал готовое...

Здесь вариантов куча...

[BOB51]

К сожалению, параллельный одновременный опрос хорош в том случае, если параметры датчиков (включая соединительные линии) идентичны. Ежли линии разные - могут и накладки буть...
И то ж скокмо оперативки "закопать" надо... 8каналов*8бит*9байт в пакете=576байт... ( принимаем последовательно каждый байт не разрывая процесс) потом "растащить" по каналам.
Или МК с такой скоростью, чтоб сразу расфасовкой параллельного байта на 8 потоков выполнял...
Но ведь все равно даже это 9 "блокнотов" по 8 байт =72 байта...

[HHIMERA]

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

"Есть ли жизнь на Марсе, нет ли жизни на Марсе."(С)...
Что... будем сферического коня в национальные цвета вакуума раскрашивать???

И то ж скокмо оперативки "закопать" надо... 8каналов*8бит*9байт в пакете=576байт... ( принимаем последовательно каждый байт не разрывая процесс) потом "растащить" по каналам.

И что??? Да хоть 1К... Даже на гавёном 030-ом несколько кил РАМ... Зато нет прерываний... и пока ДМА автоматом накачивает буфер можно заниматься чем угодно... не отвлекаясь... Процесс, по сути, параллельный...

Или МК с такой скоростью, чтоб сразу расфасовкой параллельного байта на 8 потоков выполнял...
Но ведь все равно даже это 9 "блокнотов" по 8 байт =72 байта...

Зачем??? Получили флаг об окончании... и разгребаем... всё равно следующие данные только через секунду вытаскивать... Процесс то идёт по кругу... автоматом... без участия...

========
Что за дремучесть... обязательно нужно привычно извиваться осьминогом в АСМ-танце с классической кадрилью психоделического ногодрыга???

[eduardo]

Всем привет!!! Извините за бестактный вопрос:
Собираюсь сварганить термостат на 18в20 и никак не пойму что такое гистерезис??? Для чего он нужен? Можно ли обойтись без него?Термостат планирую сделать с 2-мя уровнями:верхний--нижний. Кто-нить донесите до моих скромномозговых способностей эту инфу....
Спасибо...

[ARV]

гистерезис - это разные моменты включения и отключения чего-либо. в случае термостата рассмотрим ситуацию, когда вы задали порог включения нагрева 50 градусов. вот у вас что-то там остывает и доходит до 50 градусов - включается нагреватель. через долю секунды температура становится 50.001 градус и нагрев отключается. через долю секунды снова остывает все до 50.000 градусов и процесс пошел.

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

чтобы исключить этот режим вводится гистерезис: нагрев ВКЛЮЧАЕТСЯ при снижении температуры до 49 градусов, а ВЫКЛЮЧАЕТСЯ при достижении 51 градуса (это для примера - промежуток между порогами включения-отключения может быть любым). очевидно, что теперь вместо "бзззз" у вас будут относительно редкие щелчки реле.

как-то так...

P.S. не принимайте близко к сердцу тысячные доли градуса в моем примере - это всего лишь пример для качественного описания проблемы безгистерезисного термостатирования

[-=Vovka=-]

Собираюсь сварганить термостат на 18в20

Вообще-то DS18B20 не работает в режиме термостата, а вот DS1821 - да.
Если нужно используя DS18B20 сделать терморегулятор с гистерезисом, то нужен микроконтроллер.

[ARV]

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

нафига такой режим придуман - мне неведомо... но он-таки есть

[UnКайF]

Здравствуйте всем !
Встал вопрос о дефектации датчиков DS18B20. Стоят на некоем промышленном оборудовании. Конструкция - латунный корпус, кабель, разъём. На кабеле армировка. Места соединений залиты герметиком. Трёхпроводная схема питания.
Вопрос: кто с какими "сумасшествиями" датчиков сталкивался ? Что по вашему мнению нужно контролировать ?
Собственно, тестер датчиков я сделал, но может чего забыл.
Датчик перевёл на разрешение 9 бит для более интенсивного обмена.
Контролируются:
1. Замыкание сигнального провода на + и -.
2. Ответ на импульс сброса.
3. Контрольная сумма.
4. Показывает температуру.
5. Контроль времени преобразования. (Таймаут взял в 2 раза дольше, чем время по даташиту.)
6. Скачки температуры от измерения к измерению не более 2 градусов. (Т=93 mS !).

Отвлекаясь от темы. Пару раз сталкивался с интересным глюком при реализации 1-Wire через UART по простой схеме с использованием диода шоттки катодом на TX. При некоторой длине кабеля до датчика (окол 2 м) приходят искаженные данные, либо вообще нет ответа. Методом тыка проблема решалась подключением конденсатора 150 пФ на землю и DQ. Предполагаю, что проблема в звонах в линии при слишком "жестком" и быстром замыкании ключа на землю. Ведь кабель - это ёмкость и индуктивность. Как пример - схема согласования 1-wire на полевиках из аппноутов. Не зря там на затвор последнего полевика подтяжка 100 кОм. На практике ставил, конечно, 5 кОм (фиг знает, какая там у меня ёмкость затвора), а вот линию DQ не на прямую на сток, а через резистор 100 Ом. Для справки Rds(on) ключа в самом датчике как раз около 100 Ом. Что вы думаете по этому поводу ?