Вот только утром читал статью о вредном, бесполезном раздутии кода...

Меня это тоже "раздражает", но пишете "быстро" код: через 10..30 минут, напр. уже есть рабочий образец (прогр. код и тест. конструкция), которому нужно немного, чтобы он стал "хороший". И не все профессионалы. Все в любительская часть в большинстве случаев.

А вот это не факт. Автор темы как раз об этом и пишет. Библиотечные функции могут оказаться блокирующими и нигде в более-менее серьезных изделиях использоваться не смогут.

Вот у меня как раз пример не блокирующей функции.)

Один датчик внутри корпуса на той же линии и все, второй вы уже не подключите без SearchROM

Добавлено after 8 minutes 24 seconds:

Где этот пример? Страницей ранее? Там вообще нет ничего, кусок кода. У одноваре довольно жесткие тайминги как и у любого асинхронного канала. Совсем неблокирующий код там можно сделать только повесив датчики на USART и рулить в прерывании. А это можно сделать далеко не всегда, и занимает две ноги.

Шозабред?
При количестве датчиков более одного нужно определить их ID, чтобы начать обмен с каждым из них. Определение ID посредством SearchROM для термометров требует локализации каждого ID в пространстве. Делать это через измерение температуры возможно лишь тогда, когда разница температур очевидна. С другой стороны, автоматически это сделать невозможно, если диапазоны измерений разных датчиков пересекаются.
То есть гораздо проще создать тестовый разъем для датчика, в котором он будет один и в нем будет определен его ID. После чего он может быть включен в общую линию, а его ID в ПО на соответствующую позицию. SearchROM в этой процедуре не пришей-не пристегни - тупой никчемный процесс.

Даладна...
Есть и другие способы. Например тот, который используется в самом UART на приеме.
Впрочем, все зависит от аппаратных ресурсов конкретного чипа.

Этот кусок показывает как за один проход выполняется 1 команда к датчику.

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

Добавлено after 4 minutes 19 seconds:

Я вам про это и говорю. Вы вообще читаете сообщения?

Как раз все наоборот. Это вы не читаете мои.

Тема вообще запилена исключительно для чтения своих сообщений автором этой темы.
ЗЫ. Прикольная у вас "неблокирующая" библиотека в которой передатчик 1W построен на delay... (это только то, что я не поленился посмотреть). А вы точно знаете что такое "неблокирующая"?
Или вы полагаете, что только прерывания не стоит блокировать? Впрочем, они у вас тоже блокируются.
Даю на водку. Не стоит тянуть пины МК за пределы платы - история про SearchROM она как раз про это в вашем случае... Потому не стоит извращаться с КМОП драйвером пина с целью получения однопинового драйвера шины 1W.

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

А собственно как сделать работу с асинхронной шиной без delay?
На прерываниях конечно можно. Но вот незадача, прерываний лишних не бывает.
Уважаемы КРАМ поделитесь своей реализацией одноваре без делеев? Внезапно если мы не пользуемся прерываниями это невозможно под AVR. Но вы видимо на новом уровне.

Так же, как работает приемник в UART. На таймере. Время захвата данных от синхронизирующего фронта известно. Причем тут delay?
Кстати, это время имеет приличный допуск. А на передачу допуск вообще ошеломительный - 60...120 мкс для нуля...
Какой еще нахрен delay? Вы вообще о чем?

Увы, у меня 1W крайний раз работал на 8-битном ПИКе и код был написан на АСМе примерно 12 лет назад. Такшта никаких "делеев" там нет по определению. Как и нопов со счетчиками циклов.

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

А кто с этим спорил?
Разговор шел о блокирующем коде и задержка является типичным блокирующим кодом.
Таки да, опасность блокировки зависит от остального кода и для обычного термометра с динамической индикацией вообще по барабану как писать тайминги. Но ведь термометр нужен не только как термометр. И если он часть другого функционала, то не стоит торчать в задержках на нопах.

С этим трудно не согласиться...
Слейвы на 1W работают без кварцев с таймингами плюс-минус лапоть. Поэтому протокол не требует точных интервалов. А таймер позволяет не точные интервалы формировать, а делать это прозрачно для остального кода. Если канешна эта прозрачность необходима...

а у меня два больших проекта с этими термометрами (и в каждом проекте по два термометра), и простые задержки у меня не мешают работе основного функционала.

Ну и замечательно.
Но согласись, что бывает и не так.
Аффтар обсуждал именно опасность возникновения этого "не так". Поэтому и рекламировал свой "малоблокирующий" код.
На поверку оказалось, что никакого отношения к "малоблокируемости" он не имеет.
Мало того, что с задержками на нопах, так еще и прерывания зачем то блокирует...

Бы классифицировал использование 1-wire в процентах:
- с задержками/с/без использования прерываний для других целей/: напр. 95%
- с подсчетом времени по таймеру: напр. 4%
- другими специальными средствами: slave 1-wire /с другим МК/: 1 %
- с аппаратной частью: 0% (DS2482: 1-wire to I2c и др.)
- другое: 0%

Можем переписать числа по своему усмотрению, но они мало что изменит. (Напр. до сих пор мне никогда не приходилось заменять "задержки" на "таймерное сч. время" за DS (за хобби). Но наверное мое употребление: всегда простое).

И вот именно для скорости у меня мастер не держит тайм слот до конца, он ждет когда ведомый опустит шину. Кварца то на ведомом нет. И по факту скорость работы вырастает. На поиск четырех датчиков уходит 13мс.
В любом случае весь критический код вертится в прерываниях, а хоть усрись их приходится запрещать в при работе с шиной.
Малоблокирующий код это код, который не блокирует прерывания внезапно. Ибо если на датчик уходит 3 мс то ты хоть усрись, проц эти 3 мс будет работать с шиной. А вот будут ли блокироваться прерывания в это время очень важно.

Если отвлечься от AVR (мы же обсуждаем ПРИНЦИПЫ АЛГОРИТМА, а не платформу), то если я сейчас захочу вставить термометр с 1W в любое из моих серийных изделий, то ни о каких задержках на нопах и блокировок прерываний там и речи быть не может.
Не то, чтобы МК перегружен, но есть очень критические секции исполнения, в которых прерывания требуют сортировки по приоритетам.

Дал целых 4% на эти случаи . Ну так ещё можно поговорить и про ATTiny13A, там с таймерами возникнет проблема: куда его дальше использовать . Поэтому, как и написали: решение: по необходимости.