Странное поведение fuses в atmega8a

[Missir]

Dmitriy40 в сообщении #1684472 писал(а):

И если TWINT=1, то он будет обработан и сброшен где-то внутри обработчика

в этом и вопрос, если не выходить из обработчика то уже не нужно разрешать прерывание (1<<TWIE), но в программе оно всё равно разрешается, хотя и так уже разрешено (при TWINT=1), это не вызовет трудноуловимых ошибок? Может надёжнее этот цикл убрать, или так тоже надёжно?

Dmitriy40 в сообщении #1684472 писал(а):

Например нет обработки отсутствия ACK после адреса

если добавить default: и в нём поставить stop i2c, то это решит проблему? При любых неправильных статусах шина будет останавливаться и всё. Или это не решение?

[Dmitriy40]

Missir в сообщении #1684475 писал(а):

в этом и вопрос, если не выходить из обработчика то уже не нужно разрешать прерывание (1<<TWIE), но в программе оно всё равно разрешается, хотя и так уже разрешено (при TWINT=1),

Ну разрешено и разрешено, когда выйдет - тогда и будет важно разрешено или нет, а до выхода - без разницы, avr не поддерживает вложенных прерываний (за исключением классов приоритета в более старших мегах). Т.е. до выхода из прерывания их можно что разрешать, что запрещать - сколько угодно, важно что останется после выхода.

Missir в сообщении #1684475 писал(а):

Может надёжнее этот цикл убрать, или так тоже надёжно?

Без разницы, на надёжность это не влияет, лишь на скорость.
Из минусов: на это время тормозится обработка всех других прерываний (и основного цикла), т.е. увеличивается лаг срабатываний того же таймера. Не частота, а именно лаг реакции на метку времени. В данном случае это пофиг, всё равно пока I2C не освободилась новую транзакцию начинать нельзя (хотя проверки что i2c свободна (например TWIE==0) у вас в таймере и нет!), но в других случаях полезно помнить.

Missir в сообщении #1684475 писал(а):

если добавить default: и в нём поставить stop i2c, то это решит проблему? При любых неправильных статусах шина будет останавливаться и всё. Или это не решение?

Это хорошее решение. Но не полное - если на шине глюк или есть другой мастер или завис девайс на шине, то может не получиться выдать стоп - могут не дать поднять SDA. Некоторые такие ситуации (довольно большая часть от всех) лечатся ожиданием внешнего стопа (от другого мастера или отпусканием шины от девайса), некоторые не лечатся вообще никак кроме снятия питания.

[Missir]

Dmitriy40 в сообщении #1684482 писал(а):

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

единственное, что мне пока приходит в голову - это запустить Watchdog и сбрасывать его в основном цикле по условию done=1
данные пришли - всё нормально, данных подозрительно долго нет - перезагрузка,
но тут 2 проблемы: 1 МК как то нужно вернуть в актуальное состояние, расписание событий ведь собьётся, но это наверное решаемо;
2 - если i2c зависнет из за slave, то перезагрузка МК может ничего и не дать, а вывода reset у slave нет, можно конечно питать от ножки МК через ключ, тогда получится сбросить просто отключением от питания, но ключ нужен с очень малым падением напряжения, там ведь vcc всего 3.3V.