Проектирую в Proteus устройство на PIC12F675, которое работает с датчиком температуры DS18S20. Во вложении проект Proteus с частью программы которая отвечает за обмен данных между МК и датчиком. Проект компилируется без ошибок, однако при пошаговой отработке видно, что МК принимает некорректные биты от датчика. После выполнения подпрограммы Read в регистр W записывается FF (все единицы) при любой температуре. Не могу понять в чем дело. Прошу помощи у знающих.
PS. Подпрограммы по обмену данных МК-датчик брал из другого проекта (под pic16f628). Внес только некоторые изменения.

Из того, что заметил сходу.

Для чего все эти маневры с регистрами прерываний, если сами прерывания не используются?
Далее:

Если по истечении паузы датчик уведет шину в ноль, когда вы даете bsf datchik, до переключения на вход ПИК имеет шансы подпалить порт.
Дальше не смотрел.
Спать, спать, спать...

P.S. И вообще загляните в раздел Периферия, тема про эти датчики запинена. Там много полезного.
Alex, например, на последних страницах объясняет куда что подавать.

bcf datchik ;Единичный импульс
call Delay500 ;Задержка 500мкс.
bsf datchik ;Единичный импульс
Такая последовательность была изначально в другом (рабочем) проекте. Я так понял это для того чтобы шину побыстрее подтянуть к 1. А там до перевода порта на вход всего три команды. За это время, судя по мануалу, датчик не должен подтянуть шину к 0. Ну и при моделировании Сброс отрабатывается правильно (датчик отвечает), а что делать с ПП Read не пойму. Может датчик не видит команд которые проходят через ПП Write.
Ну и не могу найти раздел Периферия.

это лишнее и опасно

Сперва возвращайте пин на вход, а потом уже и bsf не нужен. Просто добавьте movf GPIO,f во всех участках, где переходите с выхода на вход. Переключили на выход, выдали на пин 0, пауза, переключили на вход, считали порт.
Симуляция не покажет вам, как сгорает порт. Об этом вы должны позаботиться сами.

Периферия.

Kuzia
Просмотри (в смысле обработчика протокола обмена с датчиком) вот от этого исходник
viewtopic.php?p=2593182#p2593182
(пик629=пик675 по лапкам за исключением отсутствия АЦП).
Правда конечная обработка блокнота для ds18B20 отличается от таковой для ds18S20 по причине несколько иной порядковости размещения данных...

Гляньте ещё сюда - http://forum.chipmk.ru/index.php/topic/ ... t__p__1543 Может чего интересного найдёте.

Добавлено after 11 minutes 29 seconds:
Датчик вообще никому ничего не должен, он имеет право притянуть линию к нулю, если посчитает нужным. По этому, во избежании всяческих коллизий ни линии, лог. единицу осуществляют с помощью подтягивающего сопротивления, переводя вывод устройства в высокоимпедансное состояние. Просто возьмите это за правило.
Интерфейс 1-Wire - не исключение. Существуют ещё интерфейсы, работающие по такому принципу.

Благодарю за теорию. Я это, вроде, понимаю. Однако не работает в симуляторе.

А вы уверены, что отправка работает корректно?
Запустите симуляцию с точкой останова после call Delay_800 (на сбросе датчика). Посмотрите регистры DS. Какое значение в ячейках температуры?

Да, точно, Write (передача датчику) не корректно работает.
Теперь появился другой вопрос: порт GP5 не переводится в высокий уровень при переключении порта на вход (в регистре GPIO остается 0). Хотя на входе порта стоит подтягивающий к питанию резистор. В регистр INTCON внесен 0X07. Порт (GPIO5) - без АЦП.
В чем может быть дело?

INTCON вообще-то регистр прерывания, которое у вас не используется. Раз уж его 7-й бит в нуле, то остальные уже роли не играют.

Если после перевода на вход порт остается синим, значит датчик удерживает его в 0.
После настройки на вход movf GPIO,f делаете? Хотя это на состояние пина не влияет, а только на корректность его чтения контроллером.

Очень Вам признателен. Второй раз подряд мне помогаете. Точно добавил movf GPIO,f и получилось как надо. Не верно написал (на форуме) не INTCON а CMCON.

Добавьте эту команду во все процедуры, где производите перевод пина с выхода на вход.

и со 2-ого раза не угадал.

Приемо-передача работат. Однако, еще пришлось поставить резистор в разрыв между портом МК и датчиком с подтягивающим резистором. Насколько я правильно понимаю это значит что в каком-то из компонентов имеется превышение по току?
Как это проще всего выявить?

Откуда эта уверенность?

Исходя из чего Вы решили, что это и есть решение?


Ни хрена Вы не понимаете. Никак не выявить. Ну или у всех компонентов поспрашивайте... Или в тепловизор поглядите. Поколение Пепси и Ардуино, мля...Думать нужно до, этого Вашего рукоблудия. После, тоже нужно думать, но это-же так скучно...

Нарушаете правила форума. п 2-3. предупреждение. FAKIR.

Видимо не с током связано. Протеус выбивает ошибку: Logic contention detected on net #00001. Отследил по времени: ошибку выбивает после (или вовремя) подачи МК-ом на порт 1, вовремя отправки датчику бита (лог 1). В чем может быть дело?

Добавлено after 45 minutes 51 second:
Все, разобрался! Всем спасибо и даже тем кто дерзил. Немного увеличил временной интервал удерживания высокого уровня. Не смотря на то что все интервалы общения с датчиком вписывались в диапазон по мануалу - не работало.

Появился очередной вопрос
При переключении порта на выход его состояние меняется на низкий уровень (синий квадратик), хотя в GPIO записана 1, линия подтянута к питанию через резистор. Пробовал ставить switch в разрыв и разрывать цепь датчика и МК, оставляя датчик подтянутым через рез к питанию, в момент прохода рабочей точки команд перевода порта на выход - и МК и датчик в этот момент имеют высокий уровень. Как так получается?

Пойдём по второму кругу ? Хорошо
Зачем Вы пытаетесь вывести лог. единицу с вывода МК, если она уже существует с помощью подтягивающего сопротивления ? Не нужно этого делать. Вывод МК переводить на выход нужно только для реализации лог. нуля !
Ну что тут может быть непонятного, объясните ?
Уже неоднократно Вам это было сказано, при том, что Вы ответили "я понимаю это всё". Но дальше упорно продолжаете совершать ошибки.

Я не пытаюсь вывести единицу с вывода МК! Низкий уровень сам там появляется при переводе порта на выход. Низкий уровень мне нужно сделать через пару команд.

Нет, ее как не странно, там нет (об этом я написал - "синий квадратик")

Мне это и нужно, только через пару команд. А так приходится пересчитывать временные интервалы для корректной приемо-передачи.

Все-таки дело в глюках Протеуса. Хотя до этого проекта ни с одним МК, которым я работал, не было ни единого бага в этом замечательном симуляторе.