На ATMega16 реализуются:
1. 3 прерывания (2 из которых внешние) и их обработки
2. сбор данных с 8 датчиков температуры (DS18B20) по интерфейсу 1-Wire

Интерфейс общения с датчиками реализован программно, поэтому в некоторых случаях прерывания прекращают реализацию интерфейсных задержек, в результате чего иногда приходят неверные значения температур. Для решения можно было бы запретить выполнение прерываний на время общения с датчиками, но их фиксирование является довольно важным. С другой стороны, прерывания возникают довольно часто и фильтрация неверных значений температур не спасет.
Возможно ли решение этой проблемы программно или же необходимо использовать контроллеры с аппаратной реализацией 1-Wire или доп. микросхемы, например SPI->1-Wire ? Спасибо.

Уже тысячу раз обсуждалось, что можно использовать UART.

UART жалко сливать на такую муру. Как по мне выгоднее рядом поставить какую-нить tiny13, пусть она обслуживает 1-wire, а основной контроллер решает свои задачи.

Юзаю 1Wire всегда на основном кристале. На 51 ядре в основном цикле. Буквально недавно переносил под АВР в фоновую обработку - кварц на 16 позволяет без проблем. Собственно надо выдержать достаточно точно только интервал в 1 мкс - что выполнимо без запрета внешних прерываний в большинстве случаев.

Правда вот от 1820 пришлось отказаться (думал заюзать CRC - в силовой электронике актуально). Они хуже чем 1821 которые применял и раньше. Не та точность и дольше по общению на шине. Но это чиссо из практики. А контроль данных решаемо - снизошло озарение

удачи Вам
(круглый)

для программного 1-wire достаточно запрещать прерывания в критические моменты приема одного БИТА - что-то около 15 микросекунд, ну 20 с запасом. промежутки между БИТАМИ могут быть любой длительности и вряд ли смогут помешать остальным процессам.

из всего обсуждения единственное, с чем могу безоговорочно согласиться: все уже обсуждалось великое множество раз!

По-мойму, во-первых, для сигнала RESET нужно удерживать линию в низком уровне ~480us. Во-вторых, отправка байт данных в интерфейсе происходит жесткоограниченными по времени тайм-слотами по ~120us; только между тайм-слотами возможна произвольная задержка.


Спасибо )


Использование UART, с моей точки зрения, является довольно громоздким решением (с аппаратной и программной точек зрения), по крайней мере у меня сложилось такое впечатление после прочтения этой статьи. Видимо, гораздо более универсальным будет использование дополнительного контроллера.


Возможно это и будет единственный выход. Можно поподробнее разъяснить, какие могут возникнуть проблемы в данном случае при связи контроллеров по SPI? Передача по этому интерфейсу также, кажется, требует реализации прерываний.

Длительность удержания шины в низком уровне должна быть не менее 480uS (см. даташит) больше - можно.

Удержание шины в низком уровне более 960 мкс ванварные слейвы воспринимают как hard-reset.

Поздно , конечно , но вдруг пригодится DS2482-100 или 101

На tiny13 реализовать SPI мастер (программный SPI) и прерываний непотребуется.
Основной контроллер сделать SPI слейвом, уже как Вам будет удобно, можно и с прерываниями. Проблема будет только одна - сообщить тиньке когда основной контроллер захочет что-то передать. Решения стандартные - или постноянный опрос со стороны тиньки, или отдельная сигнальная линия.