доброго времени суток. я сделал себе для котла автоматику на атмега 8 и 18b20 но вот не могу програмно организовать проверку на обрыв или замыкание проводов во время работы. пишу на си. если включить прибор и по шине i2c нет ответа то ошибка высвечивается а если во время работы отключать то тупик.и мне именно надо получать ошибку в случае обрыва или замыкания проводов а не ту которую может передавать сам ds . поделитесь мыслями как поступить .вроде задача пустяковая а толкусь на месте. спасибо.

i2c, ds18b20 - вы точно ничего не попутали?
Presence impulse, CRC - как минимум это можно использовать для проверки работоспособности шины и адекватности устройств.

При команде инициализации шины, проверяй отклик датчика и состояние самой шины (есть сигнал высокого уровня, или нет), вот по этим параметрам и делай вывод о готовности самой шины и присутствии на ней датчика.

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

CRS надёжней будет.

Не понял… какая пауза? Код опроса датчика сам писал, или библиотеку используешь? Если библиотека толковая, то там уже это всё организовано… если писал сам, то алгоритм опроса должен начинаться с проверки высокого уровня на шине… затем производишь сброс шины (подтягиваешь шину к «земле») и отпускаешь её… затем следишь за ответом датчика… если он ответил и шина восстановилась в высокий уровень, значит шина в полном порядке и датчик присутствует… только после этого начинаешь общаться с датчиком…
Если пишешь код на асме, то даже CRC можно считать, но это уже на пределе интервала динамической индикации… на Си 9 байт прочесть за 5 мс сложновато…

До CRC ещё нужно дойти… какой смысл опрашивать датчик если шина неисправна или датчика вовсе нет…

Наличие датчика или КЗ/обрыв линии, определяется во время импульса присутствия, с которого начинается любой обмен данными с датчиком. Ничего сверхъестественного тут нет, в интернете полно статей на эту тему. Даже в любом даташите на 1-Wire девайс есть все диаграммы.

А какая разница на каком языке ? Время ограничивает сам интерфейс, а не язык.
Да и индикация тут совсем не при чём. Реализуем на прерывании по таймеру и радуемся жизни

Да ну ? Примеров в сети - вагон и маленькая тележка. Тут даже думать не надо, тупой копипаст сойдёт

Не только…
Если использовать библиотеку как есть, то большая… если её поправит, то никакой…

Имелось ввиду, что нужно вначале проверить шину и датчик, а затем уже по СRC определять правильность прочитанных данных.

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

Я не могу понать - зачем вам CRC?
Как я делал (делаю)
Нашел прогу читающая под Windows ROM кода. Етот код забъваю в EEPROM-а МК. И работаю. Работаю двумя 18В20 на одной линией. И никакой CRC. Да и в документаций написано, что CRC только для проверки правилности чтение ROM code. И если уже имеется правилнъй код то никакой CRC нам не нужно. Если ТС думает менят датчики в процесе работъ - тогда да - нужно.

ПИД регулятор для инкубатора "непредсказуемо" подрагивал до тех пор, пока не выловил, что читаемая из датчика температура иногда бывает +50, а иногда - минус 12... А вот когда сделал проверку - проблемы ушли. Это хорошо, если на DS-ке простой термометр сделан, а когда устройство, да еще и ответственное?

Откръваем даташеет и читаем

и видим что CRC генерируетса только при въполнение одной командъ Read ROM 0х33 и при никакой другой командъ.

Ето не я говорю, ето документация ....

Всё верно, потому при подсчёте CRC нужно читать все 9 байт. А если просто термометр, то читать достаточно всего 2 байта температуры, без подсчёта CRC. Всё зависит от задачи…

Найдите в datasheet строчку "DS18B20 Memory Map". Именно из этой памяти мы и читаем данные. А уж кто сколько их читает...

Да, команду Read Scratchpad (0xbe) я не использую. Но все таки я читаю первъе два байта етой паняти по команде Convert (0x44) и у меня проблем не бъло.
Прав АСУ, "зависит от задачи" - у меня термометр на две температуръ - и все (по части DS18B20).

дорогие друзья. в том и вся заморочка что если обрыв в линии то никакого чтения байт не возможно.пишу на си и использую библиотеку из кодевижн. вот функция касаема температуры она вызывается цыклически.

void izmerenie(void)
{
#asm("cli"); // запрещаем прерывания
if (!ds18b20_select(0)) ; // выбираем датчик по адресу
w1_write(0x44); // запускаем преобразование температуры
#asm("sei"); // разрешаем прерывания
delay_ms(100); // ожидаем преобразования
#asm("cli"); // запрещаем прерывания
if (!ds18b20_read_spd(0)); // читаем регистры памяти
#asm("sei"); // разрешаем прерывания
work_18b20 = __ds18b20_scratch_pad.temp_msb; // формируем число int из двух байтов
work_18b20 = work_18b20 << 8;
work_18b20 |= __ds18b20_scratch_pad.temp_lsb;
lcd_18b20 = ((int) work_18b20 * 0.0625)*10;
digit_1=number[lcd_18b20/100%10]; тут выводим данные температуры
digit_2=number[lcd_18b20/10%10];
};

Исходник библиотеки или хотя бы хеадер изучался?
Ничего тут не настораживает?
В каких-то случаях функция вернёт "0"... может при ошибке?
И тут аналогично.
Во, эта функция возвращает return !w1_dow_crc8(&__ds18b20_scratch_pad,9);

этот кусочек мне товарищ наделил я в него не в вникал что касаемо датчика

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

(круглый)
ЗЫ
Меня забавляют "разработчики" которые пытаются тащить в свои творения глюкало-библиотеки, экономя на пару минут собственной разработки при сложности задачки 2+2.
ЗЫ ЗЫ
Хорошие библиотеки могут выкладывать только те, кто имеет профит с другого. Ну например разработчики камня, или там скажем сложность кода достаточно высока и область обособленна (ну скажем там расчёт по каким-нить матрицам, с использованием навороченной тригонометрии). Да и то, всё требует контроля с точки зрения ошибок. Увы, идеальный фри код редко можно найти на просторах инета.

спасибо. ну для того и общение чтобы ктото пинка волшебного давал.