PIC18F67J60 + DS18B20

[kosta]

Товарищи, нужен совет.

Есть у меня PIC18F67J60 и термометр DS18B20.
Приходилось работать с данным термометром на AVRах.
На AVR работает, а на PIC не работает.
Питание 3.3V. (Вроде DS должен работать при данном напряжении)
Пытаясь инициализировать термометр опускаю шину в 0. Отпускаю. Читаю порт.... всегда получаю 1.
Пытался переносить алгоритм действий как писал для AVR - не работает.
Пытался менять резисторы. Пробовал 4.7, 3.1, 5.7. Тоже не работает.
Может кто-то догадывается почему так происходит?

[O_l_e_g]

шину переключаете на вывод когда выводите 0, а перед чтением шину нужно периводить на ввод. Если только вы не используете 2 ноги

[urry]

в общем, вопрос к экстрасенсам - кода нет. Как вариант общего ответа - вход не переведен с аналогового на цифровой, поэтому всегда считывается 1.

[kosta]

unsigned char TERM_INIT(void){
unsigned char b;
TERMPORT_TRIS = 1;
TERMPORT_TRIS = 0;
TERMPORT_OUT = 0;
DelayMs(480);
TERMPORT_OUT = 1;
TERMPORT_TRIS = 1;
TERMPORT_OUT = 0;
DelayMs(60);
b = TERMPORT_IN;
DelayMs(420);
return b;
}


Здесь опускаю линию на полсекунды, потом отпускаю. - На мультиметре это видно.
Потом жду ответа от термометра..... ничего. Функция всегда возвращает единицу.
Если принудительно замкнуть шину с землей то возвращает 0. Вроде функция правильно работает.

Может при питании 3.3В нужен другой резистор или требуется особенная настройка порта на PIC контроллере?

[urry]

DelayMs - не много ? Может, все-таки микросекунд ?
и по второму вопросу - ток через градусник может быть до 5 ма, исходя из этого, рассчитывайте сопротивление - но это уже крайний вариант - лучше в пределах 2 - 3 ма.

[O_l_e_g]

Не погнятно, а где команда конвертации температуры, где команда чтения ОЗУ. Или алгоритм работы DS1820 предусматривает автоматическую конвертацию при подаче питания. Но в любом случае конвертация длится кажеться более 700мксек. И мне кажется инициализация выполняется отправкой последовательно двух нулей. Первый длительностью НЕ МЕНЕЕ 480мкс потом пауза 16..60 мкс второй ноль длит 60..240 мкс и затем обязательна также пауза. Причем чтение каждого бита инициализируется мастером на шине, путем кратковременной выдачи нуля на шину (длит 1..15 мкс) и затем опять установки 1, после этого смотрим на шине как ответит устройство, если устройство будет удерживать на шине 0 не менее 45 мкс значит оно передает нулевой бит, в противном случае устройство передает 1. Кроме того температура передается 2 байтами. Точно не знаю достаточно ли просто считать первые 2 байта или устройство требует чтобы были прочитаны все байты ОЗУ (кажись 9). Уверены ли вы что написанная вами функция
b = TERMPORT_IN; обеспечивает требуемый алгоритм последовательного чтения битов, да еще и преобразования 2 байт в один путем округления

[urry]

OLEG. при чем здесь конвертация - чел недоумевает, почему он не может увидеть ответ градусника на сброс.
Ответ - нужно подавать не миллисекунды, как в его тексте, а микросекунды.
П.С
Слово "кажется" пишется без мягкого знака, честно.
..
http://gramota.ru/slovari/dic/?word=%EA ... 1%FF&all=x

[O_l_e_g]

Urry Безусловно зажержка должна быть в микросекундах. Вопрос в том что команда конвертации запускает измерение температуры с последущим преобразованием его в цифровой 2 байтный код. Потом посылается команда чтения ОЗУ. Дело в том что устройство не может понимать что вы хотите после инициализации. Может вы хотите считать дескриптор типа устройства. А может вы хотите считать идентификатор. Эти термометры имеют уникальный 8 байтный номер. Одним словом есть специальные команды которые мастер посылает выбранному устройству. На эти команды устройство и отвечает. Одной из таких команд есть команды измерения температуры, вторая это чтение озу, где в первых 2 байтах храниться температура, а еще есть команда сохранения ОЗУ в энергонезависимой памяти, и связанная с ней команда загрузки ОЗУ ну и так далее установка интервалов.... Хотя я не удивлюсь если есть специально построенный протокол инициализации по которому устройство сразу понимает что ему необходимо выдать 2 байта температуры, хотя мне об этом неведомо. И кроме того надо помнить что устройства этого типа могут подключаться на шину не только по одному. И всеми ими управляет мастер, а вот ответить на запрос мастера должно только одно устройство, Так что протокол должен обеспечивать возможность адресации (хотя это только мои предположения). Кроме того инициализацию передачи очередного бита должен обеспечивать мастер. Хотя может все это делает ваша продвинутая функция на СИ. Вполне возможно разработчики ПО уже обо всем позаботились. Я писал только на асемблере. Так что уровень абстракции от оборудования в СИ мне неизвестен. Но строка b{char} = TERMPORT_IN; СИЛЬНА. Слева у нас переменная в байт, а с права устройство должно выдать последовательно 16 бит причем мастер обязан запрашивать передачу каждого бита кратковременной выдачей на шину 0. Все это делает СИ самостоятельно? Хотя може быть у меня просто более продвинутый вариант DS18s20

[urry]

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

O_l_e_g

много букв - сарказм не осилил.
Слово ассемблер пишется с 2 буквами "с", простите за занудство.
Если на шине несколько устройств, то отвечать должно то, чей серийный номер Вы вызываете.
Алгоритм поиска на шине нескольких устройств и выливается, собственно, в поиск серийного номера, на си это делается или на ассемблере - все равно.
Я делал поиск, но - но топикстартеру эти разборки не интересны, его проблема очерчена - все остальное- если Вас интересует - в личку.
Кстати - ник urry - именно с маленькой буквы - мой ник и на других форумах - не пишите с большой. Ну как то так сложилось...