Всем привет! Столкнулся со следующим явлением - датчик 18В20 (6 датчиков) в макете измеряют температуру не более 85,5 градусов, по достижении 85,5 градусов показания не увеличиваются. Поставил другие два датчика такого же типа - все нормально меряет . Поставил первые датчики на другой прибор - меряют нормально, как и положено. Алгоритм вроде правильный. Может быть кто подскажет где в таких случаях нужно искать поганку?

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

Кроме того, питание паразитное или полное? Если паразитное, то после подачи команды на преобразование температуры какому-либо датчику (или всем через "Skip ROM") нельзя давать команды остальным датчикам - для "преобразующего" это ведь будет потеря питания!

Может, совпадение, конечно... Когда-то делал себе термометр для подвала на 18В20. При проверке подогрел зажигалкой (сам дурак, знаю) и перестарался. Так вот, после умирания датчика, код от него после пересчета в градусы получался 85 (десятые доли у меня не выводились).

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

Меряет, причем на УРА!
Первый результат, даже если дать комманду на преобразование всегда будет 85 градусов. Т.е. грубо говоря, надо дать команду на конвертацию, подождать а потом снова выдать команду. Тогда уже будет реальная температура.

Итак по порядку:
- время опроса увеличивал вдвое, результат тот же. Пробовал уменьшать, тогда действительно, иногда датчик не успевал померять температуру и выводил 85 градусов. Но здесь имеет случай, когда он или не успевает померять значения температуры выше 85,56 градусов, или имеет место сброс датчика.
- питание паразитное, на шине 4 датчика. Работа с ними осуществляется следующим образом: команда преоьбразования температуры для всех датчиков, потом считывание температуры по очереди со всех датчиков, используя адресацию. т.е когда отвечает один датчик остальные молчат.

Было бы понятно, если бы температура выше 85 градусов лежала в другом байте, но это не так. Целые значения температуры лежат в двух младших байтах. Вот привожу кусок кода, где я преобразую считанные данные в температуру:



void out_curent_temp (byte i) {


byte buf1, buf2, znak;
int TEMPERATURE;
float buf3=0;




//*********************************************************
buf1 = sens[i][0];
buf2 = sens[i][1];
buf1 = (buf1 >> 4);
buf2 = (buf2 << 4);

TEMPERATURE = buf1|buf2;
znak=sens[i][1];
znak&=0xF0;
if(znak!=0) TEMPERATURE=~TEMPERATURE;

TEMPERATURE=TEMPERATURE*10;
//*********************************************************

buf1 = sens[i][6];
buf2 = sens[i][7];

buf3=0.25+(float)(buf2-buf1)/buf2;
TEMPERATURE=TEMPERATURE+(byte)(buf3*10);

Out_digit_LCD(2, 2, TEMPERATURE);

}

Умножение на 10 делаю для удобства реализации вывода чисел с плавающей запятой, чтобы использовать только целочисленные типы.



А чем это можно объяснить?

Если я все правильно понимаю, так задумано производителем... Зачем - вопрос... В любом случае практика показывает, что со второго чтения данные идут верные. Я использовал в своих проектах в сумме около 10 DS18B20 и каждый, на первой конвертации и считывании давал температуру 85 градусов.





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

Компилятор какой используешь?
В CV AVR есть готовые библиотеки... правда там есть неудобство...

Я на асме писал работу с B20 - никаких проблем не было, кроме собственных кривых рук и первоначального непонимания некоторых моментов.



Время опроса?? Наверное имеется ввиду время конвертации? Оно четко прописано в даташите и зависит от установленного разрешения.

Я же говорил о том, что надо дать команду на конвертацию, подождать (750 мСек максимум), потом снова дать команду на конвертацию опять подождать (те же 750 мСек) и только тогда, считав данные, Вы должны получить реальную температуру.

Странно... Ну у меня чуть не так, у меня меряет причем все датчики, но не более 85,5 градусов. Я попробую как Вы мне посоветовали, правда не хочется ждать два раза по 750 мсек, тем более, что первый прибор, который я сделал использует такие же датчики, только там не паразитное питание и на шине только один датчик. так вот там такого вообще не наблюдалось...
Я пишу в ИАРе.

см выше )))

А насчет того что не меряет выше... протокол сам реализовывал или готовый использовал?

Использовал готовый. Прикол в том, что есть два датчика которые меряюют как раз правильно, свыше 100 градусов.

Прошу прощения (первый пост читал невнимательно). Тогда дело точно не в протоколе. Скорее всего в железе... попробуй поменять датчики. И проверь маркировку...

Ничего подобного.

К чему вся эта бодяга с "отвечает"??? Это число. Просто 12 (или 9bit )число. Не надо никаких разборок - просто умножте это число на шаг измерения температуры. Для получения в например, десятых градуса - соответственно результат поделите и округлите. И бога ради никаких float - ну совсем ни к чему они
P.S.
Приведенный исходник читать не стал - там что-то уж совсем, извините , умопомрачительное.

Те датчики, которые в макете меряют не более 85,на приборе который описан выше меряют нормально



Ну согласен, что дробную часть вычисляю дедовским способом для датчика 1820 которые уже сняты с производства, тем не менее это тоже верный способ. Я выводил на индикатор два младших байта полученные с датчика, нагревал датчик до температуры свыше 85 градусов и в результате каждый раз я получал значение 0х55. Так причем тут алгоритм преобразования?

Только не надо возводить напраслину на дедов - они арифметику знали.

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

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

А теперь по существу, забудем про код который приведен выше. Я ничего не делая с полученным массивом байтов из датчика выводил значения двух младших байтов на индикатор. И максимум, что я мог получить, это 0х0550.

Невежественно??? Давайте забудем про "супермодераторов", давайте действительно забудем

И действительно ДЛЯ НАЧАЛА напишем пару вменяемых сторочек. Можете считать, что это является тем абсолютным минимумом знания "С" и арифметики без которого идти дальше просто нельзя.
Исходные данные - есть байтовый буфер
BYTE scratchpad[]
куда процедура чтения сложила кучку байтиков, допустим, что валидность этой инфрмации мы уже проверили подсчитав CRC и в первых двух байтах этого буфера лежит верная температура.
Кто напишет первую строчку?

Я не претендую на звание знатока Си или вообще чего либо. Сейчас я просто вывожу на ЖКИ два младших байта считанных из ОЗУ датчика. При нагреве я получаю 0х0550.

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

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

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

Большое спасибо!!! Обязательно попробую, а пока буду искать что может прерывать преобразование.

Разобрался с причиной - неправильно было организовано паразитное питание. Спасибо всем за поддержку!

Во-от, именно с этого и надо было начинать! А то "байты", "супермены" всякие...

Проверяется просто: покормить датчики нормальным отдельным питанием.

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

Ну, раз решили проблему - поздравляю!

А можно поподробнее: что неправильно?

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

У меня в протэусе всё работает, а на железе датчик выше 85 не меряет, и иногда при измерении, выдаёт ошику. Я использую готовую библиотеку CodeVisionAVR, только немного изменённую, там я в библиотеке останавливаю прерывания при обращении к 1wire. Даже при пробе переинициализации датчика во время температуры гдето 85, датчик не отвечает. Датчик подключен через экранированный стерео аудио кабель.
Вот схема:
Нажмите для просмотра прикрепленного файла
Говорят может датчик глюченый, вот скоро куплю другой и попробую. А вообще что может быть? За ранние благодарю.

Может с такотовой частотой процика связано? В протеусе одно а на самом деле что?

Смотри в каком режиме питания у тебя датчик. Если в паразитном, то обеспечь необходимые для этого условия. Или на время преобразования обеспечивай подтяжку полевичком к +5. Можешь сделать так: попробуй сначала подключить питание +5 к ноге vdd датчика, если заработает нормально - попробуй с паразитным питанием. Вобщем скорее всего с этим проблема. А если с тактовой частотой процика чтото не то, то скорее всего у тебя датчик вообще не будет отвечать.