Что можно сделать ведущему,если ведомый завис.Завис именно ведомый,те 0 на SDA и/или SCL выдан ведомым.Нехорошие слова не помогают,проверял
Отключение питания не предлагать.

Ничего, кроме цепи ресета в сторону слейва от мастера. И второй цепи ресета - от слейва до зависшего мастера

Или аппаратой приблуды, которая будет ресетить всех без разбора при долгом нуле на сда или сцл

Аесли нет сброса?
Про аппаратную-мысль интересная.

Хотелось бы узнать, что из себя представляет ваш слейв? Программный? Аппаратный? Потому, что
Во-первых, с точки зрения самой шины I2C длительность нуля на шине не ограничена, т.е. шина I2C полностью статическая. Ограничена длительность нуля на шине в SMBUS.
Во-вторых, слейв имеет право "растягивать" нуль на SCL, если он слишком "тормозной тугодум". Если у вас слейв не такой, то зачем вообще допускать управлением сигналом SCL на слейве? Пускай у него SCL будет чистым входом.
В-третьих, для того чтобы вывести из ступора приемную схему I2C слейва, необходимо без выдачи старт-условия просто "поклокать" шину сигналом SCL (9-10 тактовых испульсов). Такая рекомендация даже в спецификации I2C имеется. Особенно после подачи питания рекомендуется.
Так что поясните-ка ваши проблемы подробнее. По какой-такой причине зависают ваши слейвы и что они из себя представляют?

Поясняю: в качестве ведущего трудится pic18f452( аппаратно трудится).
Ведомыми являются SAA1064 если не соврал.(схема управления 4 СД индикаторами) и чтото из часовых микросхем.Никто ничего не растягивает и не затягивает.Суть проблемы-если во время обмена выражениями между мастером и помошником этот обмен прервать,то помошник виснет(что вообщето логично).
И вопрос в том ,как его принудить к возобновлению диалога.Мысль с отключением питания,конечно,здравая но уж больно жестокая и не всегда легко реализуемая.
Обмен прерываю всегда я.

поробую

А почему нельзя штатно с выдачей стоп-условия прерывать обмен? Ну а способ я вам уже подсказал.

Если на шине висит память, то как-то стремно - мало ли что она успела насосать пока мастер был в сбросе. А стоп-условие запускает запись. Так что спокойнее "проклокать" и начать со старт-условия.

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

Нельзя,используется аппаратный сброс.Способ хорош ,а что делать если всё в нолях и виноват ведомый??

Давайте рассуждать логически. Ведомый может держать SDA в нуле выдавая бит пока не получит от ведущего импульс SCL. Тогда он станет выдавать следующий бит, который тоже может оказхаться нулем. Так может повторяться максимум 8 раз, после чего ведомый отпускает SDA для приема ACK. Не приняв его, он прекращает выдачу. Т.е. после 9 холостых тактов SCL SDA гарантировано свободна и можно делать START.

Если ведомый отвечает спецификации SMBus, то линию SCL он может "придерживать" в нуле, но не бесконечно. Максимальное время обычно оговорено в даташите (возможно косвенно, в виде параметра "минимальная частота SCL"). Если ведомый держит SCL дольше - вам надо обращаться к производителю, ибо в таком случае он должен убрать из даташита упоминание SMBus.

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

Если ведомый вашей разработки - вам надо искать и устарнять в нем ошибку. Если ни один из этих вариантов вам не подходит - то спасет только аппаратный сброс ведомого, но это такой костыль...

Нет ведомый не мой

Зал в ожидании ерзает на стульях... Огласите имя этого таинственного ведомого.

P.S. И зачем вы цитируете сообщение целиком, чтобы ответить лишь на последнее предложение из него?

Для простоты и скорости.
По многочисленным просьбам-ведомых 2
1 SAA 1064 но не уверен,на память не помню.
2М41Т56М6Е-это часы.Кстати о времени,если кто владеет инфой на эту бяку -подскажите,как рассчитывать поправку,в описи ничерта не понятно.

Вы ошибаетесь или лукавите. У всех этих слейвов (и у SAA1064 и у М41Т56M6E) вывод SCL является чисто входом, а не двунаправленным сигналом. Так что удерживать SCL в нуле они физически не могут, а для вывода их из ступора достаточно мастеру поCLOCKать SCLем. Судя по всему, глючит все же ваш мастер, который почему-то после сброса держит SCL в нуле. Изучайте тщательнее аппаратуру МК и проверяйте свою программу.

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

Хм... Вы хотите, чтобы вам помогли, или чтобы потренировались в прогнозировании? Люди сейчас начнут штудировать даташиты, ломать голову как она может делать то, чего не должна, а потом вы скажете "ой, нет, тут другой микросхем" и думаете, у кого-то останется желание решать задачу с новыми исходными данными? Развивая мысль: мы правильно понимаем, что "все в нулях" из сообщения №11 означает "ноль и на SDA и на SCL?

По теме: я согласен с rezident, что проблема где-то у вас. Чтобы окончательно убедиться в этом, помогите нам помочь вам и поймав ситуацию "всё в нолях" отключая ведомых по одному от шины локализуйте, какой именно из ведомых удерживает SCL (именно SCL, почему может быть притянута SDA и как "проклокивание" выводит из этого состояния см. ответ №12).

Да отключал я мастера а 0 оставались.Это и странно.Пока не передернеш питание стоит 0.С мастером проще он сброс имеет.

Добрый день.
Простите за бестактность. А подтяжки, при отключении мастера, вы случаем не отрубали???

Просто у меня лично была похожая проблема с процом F120 от SiLabs. На шине висели все I2C устройства слейвы, а он единственный SMBus мастер. Так зависала именно аппаратная часть этого проца. Да бы не ресетить проц целиком, я сбрасывал порты программно в 0 и и после этого SMBus контроллер в проце оживал. Можно было продолжать работу с интерфейсом. Плюс соответственно изменил подтяжки по спецификации I2C, а не SMBus. Правда у меня зависон на лицо был в проце, так как SCL было в 0, а SDA в 1, но прерывание не формировалось.

Moderator:
Не следует это делать за чужой счет.