На вид - да, правильные. То есть, если запустить выбор слейва в цикле (Start->Addr->Stop), то на осциллографе наблюдается стабильная картинка с периодически пропадающим ACK. И так на любой скорости.

У меня этот эффект тоже вызвал недоумение.



Не соглашусь: стандарт это позволяет, значит можно


Нет, START вроде как не при чем. На чтении дело обстоит еще хуже: при последовательном чтении группы регистров в какой-то момент времени SAA перестает передавать данные (скорее всего ловит STOP или NACK мастера).


Меня тоже почти все устраивало до времени. С ним у меня вполне нормально работали EEPROM'ы разных производителей, далласовские часы, TI'шные кодеки... Я даже готов был с пеной у рта доказывать, что все в порядке и просто надо читать еррату А вот в последнем проекте пришлось перейти на софтварную реализацию.

Очень похоже на проблему фронтов/уровней сигналов.


Если придерживаться стандарта, то в софтверной реализации надо реализовывать мониторинг SCL

Фронты и уровни не зависят от реализации (SW/HW).


В девайсе с TVP5150 я так и сделал.

В теории. А на практике имеем NACK без причины.


Я понимаю эту фразу так - мастер выдает всегда одинаковую форму сигналов на шине. Отличие только в таймфрейме ACK от слейва. Коль так, то слейву что-то не нравится и это что-то зарыто явно не в форме сигнала (иначе бы Вы заметили нестабильность). Значит на модуль грешить нельзя - его задача дать форму и он ее дает.

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

А грешить мне, кроме как на модуль, больше не на что.

ИМХО:
- I2C статическая шина просто по определению
- попросы подвешивания шины должны решаться механизмами таймаутов как на стороне мастера
так и на стороне слейва(особенно при софтовой реализации слейва)
- исходя из статической природы I2C обязателен мониторинг SCL мастером
- снижение скорости шины(для устройств которы не готовы отвечать мгновенно) только уменьшит
пропускную способность всей шины
ИМХО, конкретный пример:
- слейв - микроконтроллер
- запрос от мастера может иметь разную длинну
- при получении запроса от мастера слейв должен чего-нить сделать(банально скопировать
запрошенные данные в буфер обмена)
- время готовности слейва зависит от типа(длинны)/сущности запроса

По стандарту, мониторить SCL есть прямая обязанность мастера.

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



Пример не убедительный. Предложу свой протокол, который решает проблемы задержек при обмене МК-МК.
типы транзакций:
1. Команда (от мастера к слейву)
2. Ответ (от слейва к мастеру)
3. Индикатор (от слейва к мастеру)
4. Подтверждение индикатора (от мастера к слейву) по формату то же что и "1".

Теперь как это работает.
A. каждый пакет начинается байтом длины (что накладывает ограничение на длину пакета - 255)
B. от мастера к слейву - никаких проблем, мастер просто передает блок данных, слейв просто принимает и складывает по прерыванию каждый байт данных. (уж положить байт в буфер не бог весть какая задача, если программа сделана без delay_ms в обработчиках прерываний, то ACK слейв сформировать без задержек успеет).
C. По приему всего пакета слейв начинает его разбор. Столько веремени сколько нужно. Мастер в это время волен общаться с другим слейвом.

D. мастер забирает ответ слейва или индикатор (от слейва к мастеру).
- Если у слейва есть что отправить (команда выполнена есть подготовленный к отправке "ответ", или есть запрос к мастеру "индикатор"), то первым байтом слейв передает длину блока. Мастер инициализирует счетчик ожидаемых байт и продолжает прием, зная когда надо отправить NACK на последный байт.
- Если у слейва ответ не подготовлен, то он сразу шлет 0 без разбора, мастер ставит NACK, вытаскивает еще один байт данных, завершает обмен. И переходит к другому слейву.

Вот и все, все синхронно и никаких задержек.

PS: в моей системе мастер выполняет роль маршрутизатора (принимает данные с одного быстрого канала и шлет (направляет пакеты) на несколько до 64х медленных каналов, которые обслуживаются I2C слейвами mega'ми). Мастер раздает команды всем слейвам, потом забирает ответы.

Правильно: забьем на стандарт, сделаем свой глючный и несовместимый модуль и назовем его TWI, чтобы еще и денег платить не пришлось

Я так понял, исходя из беседы, что аппаратный TWI в AT91SAMxxx глючноват, тем более применимо к TVP5150/SAA71xx. А я как раз собираюсь подключить TVP5150 к SAM9260. Рано или поздно я его конечно запущу, но чтобы не наступать на грабли, не дадите ли ссылку на приличный софтовый I2C и общих рекомендаций по стыкованию?

Рекомендации по стыкованию есть в доках от TI, а простой софтовый I2C написать - пара-тройка часов работы.