Не идут синхроимпульсы через TWCK.
Сконфигурировал аппаратный TWI по даташит, пытаюсь записать байт, если выполнить пошагово в отладчике, то после AT91C_BASE_TWI->TWI_THR = data; обмен идет нормально.
Если выполнять код без остановки, то проходят 2 - 3 синхроимпульса, потом на порту устанавливается единица, причем процесс носит случайный характер, может застрять в 0 или 1, также варьируется количество синхроимпульсов.

Даже не знаю в какую сторону копать , ПулАП установлен 2,5кОм.

Если поставить останов на while, обмен также идет нормально, если после while, опять начинается ерунда, как будто процессор мешает работе модуля TWI, если ядро остановить отладчиком, то все нормально.

AT91C_BASE_TWI->TWI_THR = data;
while(!(AT91C_BASE_TWI->TWI_SR & AT91C_TWI_TXCOMP));
return;

Пришлось сделать програмный I2C

И это правильно - избавили себя от борьбы с ветряными мельницами.

Попробуйте сразу после

и перед циклом ожидания сделать

Неча на TWI пенять. Работает безукоризненно.

Работает непредсказуемо на всей линейке AT91.

Может ссылку на errata можно привести? А то у меня по неопытности на двух из всей линейки AT91 I2C работает.

Если посылаете 1 байт то сразу засылайте STOP, а потом ждите TXCOMP.

Посмотрите код драйвера под Linux.
Мы писали драйвер с использованием прерываний, только так добились стабильной работы и высоких скоростей.

Если умолчать об AVR (там я использовал только мегу8), то на 9261 и G45 управлял (управляю) TWI аудиокодеками, памятью, видеокамерой.
Проблем не отмечено. Без прерываний (как бэ не нужны - все равно переключатель задач работает).

Код получен "копипастой"+"удалить ненужное"+"слишком умное упростить" из примеров. Работало сразу.
Осциллографом ни разу не тыкал в TWI.

---
Вот тов. Алеф отметил явную ошибку гр. топикастера. А если бы не отметил, то вот в копилку мнений о TWI добавилось бы еще одно, причем совершенно напрасное.

Вот как раз на AVR все просто замечательно. Из опыта с AT91 (полдюжины разных процессоров SAM7-SAM9-SAM3 и около полутора десятков типов разных слейвов) совершенно неразрешимые проблемы были получены в двух случаях: при работе с SAA7113 и AD9887.

P.S. Рассказывать мне, что я "не умею их готовить" не надо - собака съедена на этом семействе.

Логично предположить, что если TWI работает с сотней микросхем, а с двумя - не работает, то эти две чем-то отличаются от этой сотни...
Я даже могу предположить - чем. ( В бытность программирования телефонных кодеков от силиконлаб - у них при исчезновении внешнего фреймового сигнала с вероятностью 50% гробилась связь по SPI Т.е. тактирование интерфейсного блока связано с неким набором внутренних генераторов.)

Откуда вдруг сотня? Вот так легко наблюдаемые 12% превратились в 2% Я, конечно, не претендую на репрезентативность своей выборки, но, думаю, грабли
будут встречаться как минимум в 10% случаев.

Что касается самого TWI_AT91, то достаточно лишь почитать его описание, чтобы убедиться, что он построен просто идеологически неправильно.
Что помешало атмелам поставить на AT91 TWI по образцу и подобию AT90 (а он почти что замечательный, за вычетом некоторых не смертельных недостатков) - не понятно


Нет, мимо. Из видеокодеков так себя ведет, например, SAA7121. Но она как раз вполне себе нормально живет с атмеловским TWI на SAM3U (когда внешний клок есть, разумеется).
Две упомянутые микросхемы отлично себя чувствуют на других хостах или программном I2C.

Да вообще-то это известный факт что TWI на всей линейке at91 не работает как надо

http://lxr.free-electrons.com/source/drive...es/Kconfig#L287

Вот эта ветка тоже бы могла стать "общеизвестным фактом".

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

Пока вот такой задокументированности я не встречал. (Правда и не искал, ибо проблемы не стояло).

Проблема там - у TWI нет FIFO и он почти у всей линейки не подключен к PDC (только начиная с at91sam9g.. они догадались сделать это), любая незначительная задержка записи в регистр для передачи - контроллер автоматом отпраляет STOP и завершает ее.

Решается прерываниями.

"Решается", ага. Только если система "тянет" 45кГц прерываний, что бывает далеко не всегда.

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

Мы говорим о конкретных камнях или в теории?
Имхо, изначально медленную I2C постоянно турзучить?? Что-то в консерватории надо поменять.

Если вспомнить теорию, то "изначально медленная" I2C уже более 10 лет поддерживает скорости до 3.4Мбит/с.
Если же спуститься на грешную землю, то хоть в атмеловских поделиях и заявлена скорость всего 400кбит/с,
кривизна реализации требует именно упомянутой выше частоты прерываний даже при использовании PDC.
В консерватории действительно надо что-то менять. Но сделать это должны атмеловские инженеры.

Если Вас не устраивает Atmel'овская реализация используйте свою софтовую, никто же не запрещает и не настаивает, но не надо во всеуслышание заявлять о глючности TWI на AT91SAM. TWI AT91SAM работает в соответствии с datasheet. Про грабли TWI RM9200 я писал здесь на форуме, но это тоже обходится не слишком большими телодвижениями.
Бывают реализации и хуже.

Почему же не надо? Очень даже надо. Хотя бы для того, чтобы те, кто впервые сталкивается с TWI, не питали лишних иллюзий и не тратили зря время.

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

Ну дык это не глючность, а ограниченность. Eeprom 24LC работает, сканер клавиатуры LM8333 работает, кодеки серии TLV320 (Texas), ForteMedia работает, это ближайшее что по памяти. Хотя странно, у приведенных Вами микросхем максимальная частота 100кГц, откуда там 45кГц прерываний? Но всей инфраструктуры не знаю, оспаривать не буду.

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


"Там" и до прерываний толком не доходит: SAA7113 на SAM7X при чтении в произвольный момент времени обрывает передачу (NAK ловит по всей видимости), AD9887 на SAM3U просто не отзывается по своему адресу. При этом те же микросхемы на других хостах (в т.ч. программных на тех же процессорах) работают без малейших нареканий.

EEPROM'ы работают, всякие TLV и TVP из тех, что мне попадались - тоже.

вот здесь +10000
я всегда говорю разработчикам схемы что i2c на AT91 без особой надобности применять нельзя,
ОДНАКО, даже с софтовым слейвом на AVR у меня все работает, и даже при закоротке линий...
но конечно там все достаточно криво...

Полностью разделяю точку зрения aaarrr. Могу конкретно сказать за Sam3, TWI в слейве не работает. Обращался к инженерам в ATMEL, указал на проблемы и ошибки в даташите. Инженер признал и то и другое. Ошибки в шите исправили, а как заставить TWI работать не сообщили. Несколько раз писал им, чтобы про меня не забыли, на последнее мое письмо ответили, что типа как только решим проблему сообщим, но воз и ныне там. Регистр флагов TWI это что-то вообще невообразимое! Я так и не смог осознать по каким законам он живет. Заставил работать только когда определил точки сбоя и путем сброса и конфигурирования TWI восстанавливал работу.

sashad, если еще есть необходимость могу сбросить код.

А какие именно получились "точки сбоя"?