Господа, хочу подтвердить или опровергнуть свою догадку. Хотя конечно работающее устройство ее подтверждает само по себе, но я боюсь подвоха.

До этого с датчиками температуры DS18x работал пару раз и извлек для себя только то, что 9-ти битный режим - это точность 0.5 градуса, но зато 90 мсек для получения температуры, а 12-ти битный точность повыше, но время конверсии аж 750 мсек.
То есть если скорость критична, а точность неважна, 12-ти битный режим не подходит. В одном проекте 12-ти битный режим мне не подошел лишь потому, что в программе на экране часто обновляются данные и пауза в 750 мсек существенно заметна.
Меняя настройки и длительность паузы я случайно допустил ошибку и НЕ ПЕРЕВЕЛ датчик в 9 битный режим, а паузу уменьшил. К моему удивлению, данные на экране были верные.
То есть получается, что после того как мы дали команду на конверсию температуры, нам не обязательно ждать 750 мсек, датчик открыт для общения, просто данные в регистре чтения будут старые, так? А пока мы что-то делаем, датчик параллельно получает данные.

Я убрал задержку вообще. У меня в программе цикл - получение данных и вывод на экран. До 10 раз в секунду. То есть пока температура вычисляется, я безболезненно обращаюсь к датчику 7 раз и он 6 раз выдает мне одни и те же данные, и на 7-й раз - обновленные.

Я все правильно понял?

Нет. Во время преобразования температуры линию DQ нужно подключить к питанию, даже при наличии активного питания датчика (не паразитного).
При высоких температурах (более 85C) видно, что линия DQ при отсутствии значительной подтяжки начинает "плыть к земле" и данные искажаются.
Например, датчик может начать выдавать максимальные показания 127C.
Разумеется, что при активной подтяжке DQ во время преобразования никакой обмен не может быть осуществлен.

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

Вы какой ответ ждете?
Хотите, чтоб все работало без "глюков" - делайте в строгом соответствии с документацией.
При отступлении от документации датчик может начать вести себя как угодно.
Есть мнение, что следует подумать над архитектурой программы, чтоб ожидание ответа от датчика не влияло на все остальное - в этом случае все встанет на свои места, и не надо будет "перекладывать проблему с больной головы (программа) на здоровую (датчик)".

ОК, у меня уже выделен таймер "планировщик", который определяет, не пришло ли время сделать что-нибудь. Добавлю туда опрос датчика.

у этой группы датчика есть команды начать преобразование, стоп преобразование, либо непрерывно делать...
подумайте вот над чем. сколько битов АЦП нужно чтоб получить достаточную разрядность на весь диапазон температур?
Для однозначности ответа - возьмите ds1821 - у него 0,01 разрешение (намекает о том, что 12 бит маловато будет).
И сравните цены на предполагаемые ацп и сами датчики.
Размышления в студию.

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

удачи вам
(круглый)
ЗЫ
Влияние подтяжки линии данных на результат замечен не был, за последние 10 лет...

С меня условия постановки эксперимента, чтоб вы смогли повторить и убедится.
Или подсказать мне, где я ошибаюсь))

я правильно понимаю, что
1) если включить три датчика серии ds18xx на разные пины
2) с нормальным питанием(без паразитного)
3) в отсутствии сканирования у одного ножку данных подтягивать к плюсу(резистором?)
4) у второго(в отсутствии сканирования) к минусу(резистором или коротить?)
5) у третьего(в отсутствии сканирования) бросить в воздухе(тут вот ложняк возможен - но думаю прокатит. инициализация приведёт в чувства)
6) засунуть все три в 100 градусов

то показания будут различны, на более чем погрешность значения?

я всё прально повторил Вашу мысль?
с уважением
(круглый)

что за хрень....
Пытался настроить датчик, уменьшить разрешение


Я писал в конфигурационный регистр 0x1F (R0=0, R1=0), после этого читал данные из регистра, там действительно был 0x1F. Но датчик выдает информацию в 16-ти битном формате. Как это понимать?

Скажите, формат данных DS1820 отличается от формата DS18B20 настроенного на 9 бит?
И еще - никак не могу найти толковых разяснений, как получать отрицательные значения температуры? Как понять что это отрицательная температура, я знаю, а как получить число...

Сообщение отредактировал zheka - Jan 9 2016, 08:48

вы получаете стандартное отрицательное число как дополнение до нуля.
из даташита:

+125°C = 0111 1101 = 7Dh
+ 85°C = 0101 0101 = 55h
+ 25°C = 0001 1001 = 19h
0°C = 0000 0000 = 00h
- 1°C = 1111 1111 = FFh
- 25°C = 1110 0111 = E7h
- 55°C = 1100 1001 = C9h

(круглый)

................
разобрался с 9-ти битным пересчетом

Сообщение отредактировал zheka - Jan 9 2016, 10:18

-E7 = 0 - E7 = FF + 1 - E7 = FF - E7 + 1 = 18 + 1 = 19hex => 25dec

Погодите... а мой даташит другое говорит


То есть не E7, а CE....

-FFCE = 0 - FFCE = FFFF + 1 - FFCE = FFFF - FFCE + 1 = 31 + 1 = 32hex => 50dec => 50 / 2 => 25.0C

Спасибо, разобрался, адаптировал и под 12-ти и под 9-ти битный формат. Это в теории, когда вместо содержимого регистра подсовывается определенное число.
Когда же запустил все это на практике выяснилось (может я и ошибаюсь, но датчик ведет себя именно так), что когда включаешь 9-ти битный режим, температура кодируется все-равно по 12-ти битному формату, но шаг изменения показаний действительно 0,5 градуса. То есть 9 бит в DS1820 и DS18B20 это не одно и то же?