AT91SAM7X I2C, Просто хотел поделиться... Опции

[mungo]

Много раз читал тут, что у людей аппаратный и-квадрат в этом камне не работает. Видел софтовые реализации.
Однажды я наткнулся на пример от атмела и сделал свою реализацию. Работает уже год без проблем.
Сначала запуск железа:

Код

AT91F_PMC_EnablePeriphClock(AT91C_BASE_PMC,(1<<AT91C_ID_TWI));
*AT91C_TWI_CWGR=0x033C3C;

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

Код

void    ReadI2C(char *s,unsigned count,char dev,word iaddr)
{
unsigned    i,stt,j;
if (count==0) return;
*AT91C_TWI_CWGR=0x030F0F;
*AT91C_TWI_CR=AT91C_TWI_MSEN;
stt=*AT91C_TWI_SR; while (!(stt&AT91C_TWI_TXCOMP)) {stt=*AT91C_TWI_SR;}
if (dev==0xD0) i=AT91C_TWI_IADRSZ_1_BYTE; else i=AT91C_TWI_IADRSZ_2_BYTE;
*AT91C_TWI_IADR=iaddr;
*AT91C_TWI_MMR=(dev<<15)|i|AT91C_TWI_MREAD;
if (count==1) {
*AT91C_TWI_CR=AT91C_TWI_START|AT91C_TWI_STOP;
stt=*AT91C_TWI_SR; while (!(stt&AT91C_TWI_TXCOMP)) {stt=*AT91C_TWI_SR;}
s[0]=*AT91C_TWI_RHR;
*AT91C_TWI_CR=AT91C_TWI_MSDIS;
return;
} else *AT91C_TWI_CR=AT91C_TWI_START;
s[0]=*AT91C_TWI_RHR;
for (i=0; i<count; i++) {
stt=*AT91C_TWI_SR; j=10000; while (!(stt&AT91C_TWI_RXRDY)&&--j) {stt=*AT91C_TWI_SR;}
if (!j) {error|=NOEEP; return;}
s[i]=*AT91C_TWI_RHR;
}
*AT91C_TWI_CR=AT91C_TWI_STOP;
stt=*AT91C_TWI_SR; while (!(stt&AT91C_TWI_TXCOMP)) {stt=*AT91C_TWI_SR;}
*AT91C_TWI_CR=AT91C_TWI_MSDIS;
}

И запись:

Код

void    WriteI2C(char *s,unsigned count,char dev,word iaddr)
{
unsigned    i,stt,j;
if (count==0) return;
switch (dev) {
    case    0xEE: i=AT91C_TWI_IADRSZ_NO; *AT91C_TWI_CWGR=0x033C3C; break;
    case    0xD0: i=AT91C_TWI_IADRSZ_1_BYTE; *AT91C_TWI_CWGR=0x030F0F; break;
    case    0xA6:
    case    0xA0: i=AT91C_TWI_IADRSZ_2_BYTE; *AT91C_TWI_CWGR=0x030F0F; break;
}
*AT91C_TWI_CR=AT91C_TWI_MSEN;
stt=*AT91C_TWI_SR; j=20000; while (!(stt&AT91C_TWI_TXCOMP)&&--j) {stt=*AT91C_TWI_SR;}
*AT91C_TWI_MMR=(dev<<15)|i;
*AT91C_TWI_IADR=iaddr;
if (count==1) {
*AT91C_TWI_CR=AT91C_TWI_START|AT91C_TWI_STOP;
*AT91C_TWI_THR=s[0];
stt=*AT91C_TWI_SR; j=20000; while (!(stt&AT91C_TWI_TXCOMP)&&--j) {stt=*AT91C_TWI_SR;}
*AT91C_TWI_CR=AT91C_TWI_MSDIS;
return;
} else *AT91C_TWI_CR=AT91C_TWI_START;
for (i=0; i<count; i++) {
*AT91C_TWI_THR=s[i];
stt=*AT91C_TWI_SR; j=20000; while (!(stt&AT91C_TWI_TXRDY)&&--j) {stt=*AT91C_TWI_SR;}
if (!j) {
error|=NOEEP;
return;}
}
*AT91C_TWI_CR=AT91C_TWI_STOP;
stt=*AT91C_TWI_SR; j=20000; while (!(stt&AT91C_TWI_TXCOMP)&&--j) {stt=*AT91C_TWI_SR;}
*AT91C_TWI_CR=AT91C_TWI_MSDIS;
}

В примере записи происходит переключение скоростей под разную переферию. Используются часы, два епрома и пик. Все работает!

[singlskv]

Много раз читал тут, что у людей аппаратный и-квадрат в этом камне не работает. Видел софтовые реализации.
Однажды я наткнулся на пример от атмела и сделал свою реализацию. Работает уже год без проблем.

Он как бы работает но не совсем, самая главная проблемма в работе
i2c на sam7 заключается в том, что i2c на sam7 работает практически в синхронном режиме,
те рассчитывать на то что slave может задержать транзакцию на неопределенное время не
приходиться....

то есть слейв просто должен начинать отвечать практически мгновенно...

для железок типа EEPROM это всегда выполняется...

[defunct]

рассчитывать на то что slave может задержать транзакцию на неопределенное время не
приходиться....

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

Собсно программный I2C (надежный как бревно) разве чем-то отличается? Тоже синхронный.
Или кто-то мониторит SCL?

[aaarrr]

Собсно программный I2C (надежный как бревно) разве чем-то отличается? Тоже синхронный.
Или кто-то мониторит SCL?

Почему-то с программным (и без мониторинга SCL) работают NXP'овские кристаллы, точнее, они почему-то не работают с аппаратным.

[defunct]

Почему-то с программным (и без мониторинга SCL) работают NXP'овские кристаллы, точнее, они почему-то не работают с аппаратным.

Какие именно NXP кристалы не работают? И на какой скорости?
LPC в качестве слева прекрасно связывается с SAM'овским мастером на ~100kHz.

В предыдущем посте говоря (надежный как бревно) я имел в виду действительно надежный. Вместо бревно лучше сказать "скала" - нечто большое и прочное. ;>

самая главная проблемма в работе i2c на sam7 заключается в том, что i2c на sam7 работает практически в синхронном режиме

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

[aaarrr]

Какие именно NXP кристалы не работают? И на какой скорости?

SAA7113, на любой. При этом картинка на линиях вроде бы вполне себе хорошая, да вот только слейв переодически выдает NAK.

Не успевает слейв, значит NACK и в сад такой слейв, и освободить шину для тех кто успевает.

Есть слейвы, которые принципиально всегда держат SCL при обращении к некоторым регистрам (TVP5150, например) - так что, в сад их всех?

[defunct]

Есть слейвы, которые принципиально всегда держат SCL при обращении к некоторым регистрам (TVP5150, например) - так что, в сад их всех?

там же есть I2C Timing Requirements
ставить подобающую скорость. (для TVPS5150 - 15kHz для тех регистров которые тормозят).

Действительно выдает.

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

PS: я доверяю Вашему 7-ми летнему опыту работы с этими чипами, но и просто проверяю. Потому как взять вот так вот и принять на веру, что модуль недееспособен не могу.

[aaarrr]

там же есть I2C Timing Requirements
ставить подобающую скорость. (для TVPS5150 - 15kHz для тех регистров которые тормозят).

Согласитесь, что нормальный I2C-контроллер не должен вынуждать пользователя заниматься такими извращениями - ронять скорость обмена в 30 раз.

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

Нет, не в слейве, т.к. на софтверном I2C с теми же линиями на той же скорости все прекрасно работает.
Я не стал разбираться до конца, что же именно происходит, так как время дорого, а потрачено его было и так изрядно.

[defunct]

Нет, не в слейве, т.к. на софтверном I2C с теми же линиями на той же скорости все прекрасно работает.

Так сигналы на линии правильные или нет?
Пока имеем из Ваших слов:

При этом картинка на линиях вроде бы вполне себе хорошая

Значит мастер шлет правильные сигналы?
Тогда возникает вопрос - почему же при правильных сигналах:

да вот только слейв переодически выдает NAK. (Действительно выдает.)

?
Вопрос открытый т.к.

Я не стал разбираться до конца, что же именно происходит, так как время дорого, а потрачено его было и так изрядно.

Понимаю. Промоделировать ситуацию с NACK'ом у меня не вышло. Предполагаю, что причина может быть связана с генерацией START'a.
А по работе с i2c слейвами с которыми работаю я, SAM'овский TWI мастер меня устраивает.

Согласитесь, что нормальный I2C-контроллер не должен вынуждать пользователя заниматься такими извращениями - ронять скорость обмена в 30 раз.

Соглашусь, не должен. (только софтверная реализация ведь еще сильнее будет бить по производительности...). А согласитесь ли Вы, что нормальный I2C слейв не должен вынуждать мастера ждать ~100mks на ровном месте?

[aaarrr]

Так сигналы на линии правильные или нет?

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

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

Соглашусь. Но также согласитесь, что нормальный I2C слейв не должен вынуждать мастера ждать 100mks на ровном месте.

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

Промоделировать ситуацию с NACK'ом у меня не вышло. Предполагаю, что причина может быть связана с генерацией START'a.

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

А по работе с i2c слейвами с которыми работаю я, SAM'овский TWI мастер меня устраивает.

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

[defunct]

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

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

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

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

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

[aaarrr]

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

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

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

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

[defunct]

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

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

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

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