А они(Atmel) нигде об этом прямо и не пишут
У них есть только одна фраза на этот счет в документации:
"Модуль TWI прекрасно подходит для обмена информацией с EEPROM производства Atmel"
примерно так

>> if(hTimer_1ms) hTimer_1ms();
>> if(hTimer_1s) hTimer_1s();
Насколько бысторо выполняются эти 2 функции ?


любая транзакция(прерывание) по i2c должна заканчиваться записью TWINT в TWCR
иначе будем бесконечно ловить прерывания
по этому в конце switch обязательно должно быть:
default:
TWCR=(1<<TWINT)|(1<<TWEN)|(1<<TWEA)|(1<<TWIE);

так же обязательно ловить код
#define I2C_BUS_ERROR 0xF8

примерно так:
case (I2c_BUS_ERROR):
TWCR= (1<<TWINT)|(1<<TWSTO)|(1<<TWEN)|(1<<TWEA)|(1<<TWIE);

продолжение следует ....

скорее вот этот
адрес -> вычитывание большого блока

на самом деле много байтиков туда(SAM->mega)
и много байтиков обратно (SAM<-mega)
внутреняя адресация в SAM не используется

SAM->mega вобще без проблем
mega->SAM с вышеописанным глюком

Это заметно И пожалуй больше не для чего. Насколько хорош TWI у мег, настолько паскуден у АРМов. А казалось бы одна контора, могли использовать одинаковый IP-блок.


в милисекундном стоит счетчик на 50 мс. В нем сдвиг бегущего бита и чтение порта. В секундном - мигание светодиодом.



Вы об этом? Так я ж сказал - поскипано для ясности. Отрабатываются все возможные состояния - general call,arbitration lost итд, default тоже есть. Предусмотрена работа с раздельными буферами приема и передачи, софтовый байт статуса с флагами занятости и ошибки. А вот написано местами весьма неоптимально - весь файл представляет собой switch на 300 строк.


Мне кажется это генетическое. В прошлом году делал проект, где из EEPROM вытягивалась программа в эдаком байт-коде и передавалась на исполнение. Я на вытягивание программы убил вдвое больше времени, чем на отладку интепретатора. Терялись биты в конце. Было два решения - либо ставить холостой байт в конце каждого блока либо брать меньшими порциями. Побил вычитку на блоки по 32 байта - все работает без вопросов и живет в серии.

Это то же такое "специальное" знание

Вероятно в режиме мастера в каком-то состоянии нужно сделать нечто подобное

Кстати, решение по остановке TWI у SAM есть - просто выключаем его в PMC на необходимое время.

Если конкретно, то в таком цикле вычитки из EEPROM :



приведенный финт ушами прекрасно работает

Забавно иногда смотреть. Разные программисты в разных городах и часовых поясах используют очень близкие решения.

Я недавно бился со связкой двух мег по I2C. m640+m48. Где м48 использовалась в качестве часов+чтение датчиков, а с точки зрения м640 была 24с01. И проблемы всплыли толь при уходе от байтового режима в страничный. На этой же шине сидели 2 микрухи 24с512.

Так вот вычислил такой момент. У меня м48 практически постоянно находилась в IDLE. Просыпалась по часам и TWI. Работала от внутреннего генератора 8MHz. Процедуры обработки - минимальны.

У меня м48 не успевала правильно обработать шину i2c в режиме слэйв с частотой свыше 150кГц. Наверное где-то не успевала просыпаться и что-то упускала. Как результат мешала работе 24с512. При снижении частоты ниже 150 - всё прекрасно заработало.

К сожалению подробности не выяснял. Как обычно - некогда.


Кстати. Один раз я использовал для связи двух AVR SPI обмен. Плотность 8000 байт в секунду. Всё работало совершенно устойчиво. Никаких сбоев и коллизий. Правда микрухи стояли с двух сторон одной и той же платы. То есть длина проводников - 1см. В серию не пошло. Мы потом всё таки выкинули вторую и впёрли всю обработку в одну.

В том проекте по связке SAM7+mega8 мне удалось получить устойчивую связь даже
на частоте i2c 600KHz при этом реальный(полезный) поток получился ~27000 байт/сек.
При 400KHz i2c трансфер был ~22Kb/sek
Быстрее мега не успевала готовить данные, она там еще много чем полезным занималась
(до 16 дискретных вxодов/выходов с фильтрацией, SPI, PWM, запись во
внутреннюю EEPROM, и тд )
И все работало на частоте меги 8MHz.
На 16Mhz трансфер наверное был бы повыше, правда SAM7 начинал уже подтормаживать

Мужчина!

Это Вы о чем ?
Познакомиться ?

Мне сабж всю душу вымотал. Вот именно в аналогичной конфигурации.
Если вкратцее -- у at91sam7x256 недоделанный и глючый TWI. Сбоит и
зависает от любой помехи на шине. И без костылей и подпорок ™ в виде
таймаутов, принудительных сбросов и принудительной же, ручной, манипуляции сигналами с целью освободить шину от "зависших" в таком состоянии slave -- зависает вусмерть. Благо что программно сбрасывается (причём где-то за несколько десятков микросекунд -- какие там процессы при этом внутри происходят, одному Билу Гейцу известно).
При том, что сам протокол I2C так интересно устроен, что отвалившийся
невовремя мастер в свою очередь вводит в неадекватное состояние
подчинённых (TWC если когда пропал невовремя), см. выше. С AVR проще, за ним
неадекватностей не замечено, за исключением того (у меня их много),
что арбитраж в режиме slave они "умеют" (именно, что в кавычках) только
на байтовом уровне. Требуют аккуратного обращения с флагом подтверждения обработки прерывания (ВНИМАНИЕ!) и, похоже, запись в CR без паузы в пару тактов иногда не имеет действия. В итоге -- у меня работает, вроде...

А, да, ещё в догонку. AR91SAM7 не умеет "repeated start condition" (для SMBUS),
впрочем ARV их толком и не распознаёт...



90%, что забыл, что в конце последнего байта NACK давать надо.

А, ещё одно. Перед установкой MREAD прочитай RHR...