С точки зрения сигналов - подаете 0 на SCL, память отпускает SDA, отпускаете SCL, подаете 0 на SDA - получаете старт. Как это сделать средствами вашего контроллера - не подскажу...

Я не работал непосредственно с USI вживую и вынужден доверять вам, но вот читаю в UG раздел 14.2.4 I2C Mode -> I2C Master Mode и вижу
У вас ведь режим мастер вроде? Так почему после передачи 8 бит SCL в нуле остается? У м/с EEPROM нет возможности управлять уровнем SCL. У нее SCL это чистый вход.

SCL как раз и получает high level (см. картинки в начале, там тоже видно). А менять значение SDA я не могу, пока SCL high.

Нифига там не понятно. Вы бы еще в микроскоп предложили эти картинки рассматривать. Как вы ACK на аппаратный адрес EEPROM получаете? Фрагмент кода приведите.
Почему не можете? Ведь изменение SDA во время SCL=high как раз и создает старт- или стоп-условие.

Переход снизу вверх создает стоп (мне не надо этого, потому что я еще не закончил передачу), а переход сверху вниз создает СТАРТ, но чтобы сделать этот переход мне надо сначала наверх попасть...

А примеры кода тут
http://www.ti.com/litv/zip/slac080i (кстати свежак, но с i2c все по старому)
msp430x20x3_usi_06.c

Самых интересных вещей
msp430x20x3_usi_10.с
msp430x20x3_usi_11.с
там к сожалению нет...
А в
msp430x20x3_usi_16.c
никакого RESTART на самом деле нет.

Ой, чей-то я не вкуриваю. Откуда снизу вверх-то? Перед тем как возникает нужда сделать restart (а нужда эта возникает только при RANDOM READ, времянка которого на той самой Figure 8-2 про которую вы три раза упомянули) бит ACK передает slave, а не master. Мастер в этом такте принимает/проверяет этот бит и у него SDA=high, т.е. отключен, т.к. выход open-drain. Поэтому нет никакой проблемы в том, чтобы сразу после приема ACK сделать для SDA переход high->low, создав условие для restart.

Так ACK это ноль и поэтому SDA остается в нуле... Что-то сам уже потерял уверенность...

Вот-вот, то SCL в нуле, то SDA в нуле Естественно, что SDA примет значение high (EEPROM освободит линию SDA) только после приема 9-го бита, т.е. когда произойдет переход SCL low->high. Судя по описанию в UG, это так и должно происходить автоматом когда USI работает в режиме master. Но вы свои исходники секретите и поэтому о том, как именно у вас происходит прием/проверка ACK приходится только догадываться.

case 2: // Receive Address Ack/Nack bit
USICTL0 &= ~USIOE; // SDA = input
USICNT |= 0x01; // Bit counter=1, receive (N)Ack bit
I2C_State = 4; // Go to next state: check (N)Ack
break;

case 4: // Process Address Ack/Nack & handle data TX

if(Transmit == 1){
USICTL0 |= USIOE; // SDA = output
if (USISRL & 0x01) // If Nack received...
{ // Send stop...
USISRL = 0x00;
USICNT |= 0x01; // Bit counter=1, SCL high, SDA low
I2C_State = 14; // Go to next state: generate Stop
P1OUT |= 0x01; // Turn on LED: error
}
else
{ // Ack received, TX data to slave...
USISRL = MST_Data++; // Load data byte
USICNT |= 0x08; // Bit counter = 8, start TX
I2C_State = 10; // next state: receive data (N)Ack
Bytecount++;
P1OUT &= ~0x01; // Turn off LED
break;
}
} if(Transmit == 0){

if (USISRL & 0x01) // If Nack received
{ // Prep Stop Condition
USICTL0 |= USIOE;
USISRL = 0x00;
USICNT |= 0x01; // Bit counter= 1, SCL high, SDA low
I2C_State = 8; // Go to next state: generate Stop
P1OUT |= 0x01; // Turn on LED: error
}
else{ Data_RX();} // Ack received


}
break;

Это фрагмент, который вы вырезали из примера? Зачем мне этот огрызок исходника? Я же прошу у вас тот исходник, с которым вы сами работаете и в котором у вас не идет "рандомное" чтение EEPROM. Я не имею ни времени, ни особого желания дописывать за вас недостающие части программы и оформлять все это в отдельный проект только для того, чтобы проверить мои/ваши догадки. Если хотите реальной помощи, то выкладывайте готовый/законченный (не)работающий проект или исходник, который можно легко скомпилировать и проверять. Без необходимости "допиливания" его вручную.

Вы меня сами попросили привести пример кода "как я ACK на аппаратный адрес EEPROM получаю". Я привел.

Кстати как I2C без железки проверять я не знаю. Как Вы собираетесь код (тот который компилируется) проверять? У этого мк вообще I2C не работает, когда debugger используется (порты имеют несколько функций - или это или то).

Извините, но при таком диалоге телепата с партизаном мне становится уже неинтересно. Спокойной ночи.

Спокойной ночи. (а кода у меня с собой просто нет)

То есть еще раз: я взял готовый пример (msp430x20x3_usi_12.c) и слепил из него (один в один), а REPEATED START я сделать не смог. Нет его (как мне кажется) и в примере msp430x20x3_usi_16.c, хотя они это и называют REPEATED START.

Что тут партизанить я не знаю (а коды у меня все на работе).

А кто-нибудь изучал поведение I2C реализаций в коде (в смысле SOFT I2C)? Насколько там по времени потеря в сравнении (в зависимости от частоты конечно)?

Сообщение отредактировал sergeeff Jr. - Nov 27 2010, 17:24

На всякий случай.
Уже ушёл.

(в процессе железной отладки не забывать почаще вкл/выкл питание EEPROM; это сугубо добровольно, но когда надоест тупить в непонятные глюки "один раз случайно сработало, потом навсегда перестало"...)

Сообщение отредактировал нечитатель - Nov 28 2010, 15:40