Всем привет! Кто нибудь измерял время опроса 1 датчика температуры DS18x20? И на какое время удлинняется опрос при использовании 2, 3 и т.д. датчиков. Каково время поиска датчика? Время опроса датчика(ов) DS1821 для микроконтроллера АТ89С5115 (MCS-51) с резонатором 24 МГц (в режиме стандартных 12 тактов) 7 мс и практически не зависит от количества, так как датчики подключаются к отдельному выводу.

Не поверите! Производитель измерял. И даже опубликовал результаты - в даташите

Вы, уважаемый, или вопроса не поняли, или сознательно оскорбить хотите? Меня не интересует время преобразования АЦП (750 мс по даташиту), а то бесценное время микроконтроллера, которое я потрачу на общение с этим датчиком(ами) последовательно выставляя (если уже найдены) уникальный (64 бит) код(ы) датчика(ов), посылая команды и читая данные. Причём особо интересует насколько это время увеличивается при подключении следующего датчика. Интерес вовсе не праздный - во время опроса прерывания должны быть запрещены, то есть МК глух и слеп к внешнему миру. Часто это весьма критично. 8 датчиков DS1821 опрашиваются за 7 мс. За какое минимальное время можно опросить 8 датчиков DS18x20? Не через какое, а за какое! (Казнить(,) нельзя (,)помиловать)

Оскорбить не хотел, а вот заставить заглянуть в ДШ хотел. В частности в раздел, описывающий протокол 1-wire. Все тайминги описаны - осталось сложить.

Выбираем индустриальные и медицинские источники питания MEAN WELL в открытом исполнении

Использование модульных источников питания открытого типа широко распространено в современных устройствах. Присущие им компактность, гибкость в интеграции и высокая эффективность делают их отличным решением для систем промышленной автоматизации, телекоммуникационного оборудования, медицинской техники, устройств «умного дома» и прочих приложений. Рассмотрим подробнее характеристики и особенности трех самых популярных вариантов AC/DC-преобразователей MW открытого типа, подходящих для применения в промышленных устройствах - серий EPS, EPP и RPS представленных на Meanwell.market.

Подробнее>>

глупости это все: прерывания при работе с 1-wire должны быть запрещены на время от 15 до 60 мкс (точно не помню - может, чуть поболее) - что-то мне подсказывает, что столь маленькое время совершенно некритично практически для любых ситуаций.

Не помнишь - учи матчасть! Тот же даташит. Вообще то только тайминги инициализации по даташиту мин 480 мкс на ресет и 480 мкс на присутствие. Таймслоты от 60 до 120 мкс на передачу/чтение ОДНОГО бита. А в том то и дело, что на весь опрос уходит уйма байт в отличие от DS1821, где только команды и данные (нет 8 байт уникального кода), причём передаются и принимаются параллельно. Посчитаем (вот ведь, котяры, заставили таки - ведь и спрашивал именно потому, что в лом считать было). Пример 1 из даташита. Сброс 480 мкс+Присутствие 480 мкс. Далее команда Match ROM - байт, то есть 8Х60=480 мкс. Далее 64 бита уникальный код. 64Х60=3840 (!). Далее наконец то команда запуска преобразования для АЦП байт + ещё 480 мкс. Итого 5,76 мс. Вот тут ждём 750 мс до конца преобразования АЦП и можем разрешить прерывания. Далее опять бадяга. Сброс-присутствие 55h, уник.код, байт команды чтения скрэтчпэда и 9 байт, включая CRC. Итого 480+480+480+3840+480+9х8х60= 10080 мкс или 10,08 мс. И если запуск преобразования можно осуществить минуя уникальный код (Skip ROM), то чтение температуры (10,08) должно осуществляться для каждого датчика отдельно. Итого имеем для 8 датчиков 10,08х8= 80,64 мс, то есть более чем в 10 раз дольше, чем для DS1821. И ещё геморр с обнаружением и идентификацией датчиков в случае отказа (одного, двух...). А если добавить сюда ещё и помехи... В сухом остатке. Минимальное время запрета прерываний для одного датчика DS18S20 - 10,08 миллисекунды и возрастает прямо пропорционально количеству подключенных датчиков. Если устройство работает с внешними асинхронными прерываниями (по входам, UART(Modbus slave) и т.д.), то применение ЭТИХ датчиков НЕЦЕЛЕСООБРАЗНО

я всенепременно последую вашему совету учить матчасть. а взамен вам порекомендую пользоваться мозгом: в матчасти сказаны диапазоны, которые считаются нормальными для ВСЕХ импульсов - то есть допуски. И кроме тайм-слотов записи-чтения, эти допуски достаточно велики, чтобы не запрещать прерывания на время сигналов RESET и PRESENCE. что касаетс тайм-слотов записи-чтения одного БИТА, то их надо реализовывать при запрещенных прерываниях, но критически важной по времени является только начальная часть тайм-слота, и как раз она-то в зависимости от вида тайм-слота и длится от 15 до 60 мкс (может чуть больше - простите неуча). таким образом, даже если допустить, что НЕОБХОДИМО аж целых 120 микросекунд работать при запрещенных прерываниях, думаю это не испортит обедни... на ОБЩЕЕ ВРЕМЯ работы с датчиком запрещать прерывания не нужно.

насчет импульса присутствия - как бы порядка 100 микросекунд, не ?
И зачем выдавать серийник, если термометры разнесены по ножкам, тоже не понимаю.
Совет относительно "учите матчасть" применим и к ТС.
А его вывод о недопустимости просто повысил настроение, за что ему отдельное спасибо

Нет уж, неуча не прощу. И допускать ничего не буду. Я с датчиками DS1821 уже 5 лет работаю. А они работают по тому же самому протоколу 1-Wire, что и DS1820. Протокол сам реализовывал с нуля. И всё прекрасно работает. Вы РЕАЛЬНО с этими датчиками работали? Именно так, как рекомендуете? И всё в порядке? Тогда пример кода в студию. А если серьёзно, то спрашивал тех, кто реально что то делал.

не, 480 мкс мин, но датчик может выдать и раньше = это не основные затраты времени.
DS1821 разнесены DS18S20 на одной шине (это разные датчики!)
я не топикстартер, но учу постоянно, что не так?
на здоровье

я в своей жизни 1 раз повесил 8 датчиков на 1 шину и организовал опрос-поиск серийника - больше я так не делал, так как был большой гемор с тем, что параллельно соединенные кабеля, которые идут к датчикам, увеличили емкость линии настолько, что датчики начали врать.
Теперь - времянки - на 1 датчик я обычно выделяю 1 мс - этого достаточно, чтоб его сбросить, например или выдать - прочитать байт.
При динамической индикации, например, эта миллисекунда у меня получается после того, как отработан очередной разряд - я в прерывании ставлю флаг разрешения, в основном цикле его анализирую, если есть - сбрасываю и делаю очередную операцию над датчиками. Обычный свич с статической переменной.
Задержки - по запрету прерываний. Для того, чтобы понять, 1 или 0 принимается, достаточно 15 микросекунд. Если выдаем 0, то запрещать прерывания не обязательно, потому что допуск +- лапоть. Если 1 - нужно. Ничего страшного в этом нет - если работаем с уартом, например, это ведь не значит, что съелся на 20 микросекунд стартовый бит - прерывание возникает по приему байта, когда он уже готов. А там еще есть буфер.
Вроде все...

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

вот информация из даташита:
1. MASTER TX RESET PULSE MINIMUM 480 мкс - это означает, что можно генерировать интервал при разрешенных прерываниях. как известно, обработка прерываний может только увеличить длительность задержки, а значит, от 480 и БОЛЕЕ - все это будет RESET
2. DS18S20 waits 15-60 мкс - это время ответа PRESENCE. то есть ведомый не позже 60 мкс просто обязан ответить, если он уловил RESET.
3. presence pulse DS18S20 60-240 мкс - это длительность импульса PRESENCE. совместно с п.2 можно сделать вывод. что если не ранее 60 мкс и не позже 120 мкс произвести опрос линии на предмет низкого уровня - пропустить ответ (или считать ошибочно) просто НЕВОЗМОЖНО. итак, имеем запас на 60 мкс - по-моему, вполне можно отрабатывать задержку без запрета прерываний, не так ли?
4. Таймслоты чтения и записи мастера начинаются с ТОЧНОГО интервала 15 мкс, а "хвост" тайм-слота может плавать довольно в широких пределах - следовательно, при запрещенных прерываниях надо отработать только 15 мкс задержки от начала тайм-слота, а остальное - уже не обязательно.
5. Таймслоты ведомого полностью аналогичны - 15 мкс железно надо отработать, а остальное - плюс-минус "километр". во всяком случае, главное не переборщить с общей длительностью тайм-слота в 120 мкс

итак, резюмирую: если обработчики ваших прерываний написаны по уму, т.е. максимально быстро возвращают управление (грубо говоря, длятся не больше 60 мкс) - достаточно запрещать прерывания ТОЛЬКО НА 15 мкс в начале таймслотов. в крайнем случае - на 60 мкс. все остальное - излишество.

что скажет на это гуру?

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

вот информация из даташита:
1. MASTER TX RESET PULSE MINIMUM 480 мкс - это означает, что можно генерировать интервал при разрешенных прерываниях. как известно, обработка прерываний может только увеличить длительность задержки, а значит, от 480 и БОЛЕЕ - все это будет RESET
2. DS18S20 waits 15-60 мкс - это время ответа PRESENCE. то есть ведомый не позже 60 мкс просто обязан ответить, если он уловил RESET.
3. presence pulse DS18S20 60-240 мкс - это длительность импульса PRESENCE. совместно с п.2 можно сделать вывод. что если не ранее 60 мкс и не позже 120 мкс произвести опрос линии на предмет низкого уровня - пропустить ответ (или считать ошибочно) просто НЕВОЗМОЖНО. итак, имеем запас на 60 мкс - по-моему, вполне можно отрабатывать задержку без запрета прерываний, не так ли?
4. Таймслоты чтения и записи мастера начинаются с ТОЧНОГО интервала 15 мкс, а "хвост" тайм-слота может плавать довольно в широких пределах - следовательно, при запрещенных прерываниях надо отработать только 15 мкс задержки от начала тайм-слота, а остальное - уже не обязательно.
5. Таймслоты ведомого полностью аналогичны - 15 мкс железно надо отработать, а остальное - плюс-минус "километр". во всяком случае, главное не переборщить с общей длительностью тайм-слота в 120 мкс

итак, резюмирую: если обработчики ваших прерываний написаны по уму, т.е. максимально быстро возвращают управление (грубо говоря, длятся не больше 60 мкс) - достаточно запрещать прерывания ТОЛЬКО НА 15 мкс в начале таймслотов. в крайнем случае - на 60 мкс. все остальное - излишество.

что скажет на это гуру?

P.S. а админ что-то планирует делать с Gateway timeout и SQL Error (1040) Too many connections ??? задолбался сообщение отправлять, а теперь их оказалось целая куча - я не виноват!!!!

Ну вы гегемонию развели!
На второй странице я писал (наверное никто не заметил) что опрос датчика DS1820 делал в прерываниях полностью, ничего не надо отключать (прерывание происходит с частотой 10000Hz, частота tiny13a 9,6MHz), если кому интересно могу скинуть исходник.

Какая была суммарная длина? Какой кабель (категории 5? экран?) Pullup резисторы не пробовали уменьшать? Скорость обмена не пробовали понижать? Имхо это из-за больших скоростей (дооптимизировались )


В общем всё понятно и не возникает возражений. На быстрых (RISC) МК так всё и будет - от проблем с длиной до отсутствия проблем с прерываниями. На медленных (MCS-51) с точностью до наоборот, с длиной проблемы вряд ли возникнут, а вот с прерываниями... У Вас может и есть ещё буфер, а у меня уже нет. Надо на АРМы переходить - там в UARTе стек FIFO на 16 байт

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

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

а по существу моих вам возражений что скажете?

а цена? по eFind.ru в 3 раза разница!