Это фуфло, а не ускорение. Оно зависит от слейва.
Да и зачем ускорять термометр? Вы вообще в курсе, что измерять температуру часто не требуется, а даже ущербно для точности? Вообще то 1820 сам начинает греться от своего же функционирования...

Абсолютно согласен! И датчик и т.д. предметы имеют массу. В целом нагрев: это медленной процесс. Быстрее чем 3..10 секунд измерять смысмысла не вижу. Получаем только самонагревание.

Вы не понимаете о чем пишите.
Блокировка не равна времени работы с шиной. Блокировка - это НЕПРЕРЫВНАЯ работа с шиной или ее протоколом. То есть интервал времени, в котором никакой другой код main-а работать не может. И не требуется блокировать прерывания, ЕСЛИ ТОЛЬКО У ВАС обработчики прерываний сами по себе не являются блокирующими. Но тут уже "кто на кого учился"...

У вас в голове каша я смотрю. Скорость работы функции вам не важна? Мы не ускоряем термометр. У меня есть задачи где нужно раз в 10 сек читать температуру. Ну хозяин барин. Вы не сможете написать функцию не на нопах под AVR. Только при использовании USART.
Как это не блокировать прерывания? Там критичный ко времени код.
Понимаете есть задачи где критически важно получить температуру здесь и сейчас. Правильную.
И я вам ровно по то же самое говорю, именно про время работы функции. Она у меня работает примерно в два раза быстрее родной, а вы почему то говорите что это пофиг и температуру надо мерять раз в час )))

AVK, при работе с этими датчиками вообще пользоваться прерываниями не нужно. даже с одним прерыванием, от слова совсем.

Нет, это не так. Критичность ко времени определяется латентностью других задач.
Если вы считаете в функциях main-а по сотне миллисекунд монолитно, то вы сам себе злой буратино.
Поинтересуйтесь как работают кооперативные и вытесняющие ОСРВ. Но не для того, чтобы их поднимать на своих МК, а для того, чтобы понимать как вообще реализуется многозадачность. Ну и научитесь правильно оценивать код на предмет требований реального времени. Далеко не любая задача является задачей реального времени, даже если она с таймингами...

Вы понимаете про что я вообще говорю? Если вы хотите сделать функцию. которая не будет тратить 4мс на чтение датчика вами прийдется использовать USART и прерывания. Без вариантов.
Я просто в шоке, вроде умные люди.

Добавлено after 1 minute 42 seconds:
КРАМ вы прикалываетесь? Там критически важны тайминги. Иначе считаем мусор.

Меняете систему/mcu и... можно прерывание в прерывания. С другими МК данные не потеряете. Наверное, поэтому и существуют разные точки зрения. Так кто как привык.

Чушь не надо писать. Если тайминги допускают ДВУХКРАТНЫЙ интервал, то о какой "критичности" может идти речь? Тем более, что там речь идет о десятках микросекунд, а ваш МК работает с машинным циклом в 50...100 нс...
Вы видимо вообще не разбираетесь в железе и в транслируемом коде...

С AVR, к сожалению, инструментов меньше. с AVR мне кажется, задался целью построить высокий блок, а материалы у меня все заканчиваются (напр. vs PIC, STM32). И по целям: возможно множество решений. Вот тут возникают споры (о том, напр. кто и как пишет код для DS).

Если бы я в настоящее время не разбирал чужой код на 165-ой атмеге, то я бы может и согласился с вами, но даже один таймер может использоваться в куче задач, если правильно написать алгоритм. Так в куче задач используют SysTick в ARM-ах. Важно только правильно выбрать системный интервал и не писать монструозные вычисления в обработчике прерываний... Аналогично можно сделать и в AVR.
ЗЫ. Специально в ответах для вас делаю контрольный перевод на болгарский, чтобы по возможности исключить неоднозначности машинного перевода...

Согласен. Так или иначе внедрили таймери везде: micros(), get_ticks(), SysTick ... Только в каком-то очень старом МК такой возможности нет. Например, нет прерывание по таймеру (напр. PIC12F508?). Но и там реализовать DS18 возможно (с задержками).

В догон для автора темы ссылка на полезную для него информацию. Сама ссылка ведет на описание кооперативной ОСРВ OSA, но на этом же ресурсе есть описание вытесняющей ОСРВ TNKernel.
Обе статьи написаны двумя очень грамотными питерскими инженерами.
Повторюсь, дело не в применении ОСРВ, а в понимании идеологии многозадачности.

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

15 мкс при 20 МГц системной частоты означает 300 машинных циклов. ТРИСТА, Карл!!! А всякие "сразу" - это 1 мкс, то есть двадцать машинных циклов.
Если блокировка наступает на 20 циклов - хрен бы с ней. А вот на 300 - это уже перебор...
Опять же эти задержки следуют у автора одна за другой в непрерывном теле функции...
И в очередной раз - дело программиста решать что ему критично, а что нет. Зависит от списка задач и их допустимой латентности. Но тут разговор идет о принципиальных вопросах, которые автор пытается решить странными методами, которые на самом деле ничего не решают.

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

Тоже не вижу проблемы в методе с задержкой и кратковременной отменой прерывания. Есть несколько проектов (Arduino, AVR, PIC, STM8/32) с DS18, многозадачности нет, кроме светодиодной индикацией (4 * 80 Hz = 320 Hz, до 800 Hz протестировал). Ничто никого не мешает. Большего делать не приходилось.

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

И если бы посмотрели мой исходник вы бы это и увидели. Не стоит думать, что вы самый умный ))))

AVK, все твои посты говорят о том, что это ты считаешь тут себя самым умным.