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?

[singlskv]

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

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

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

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

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

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

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

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