Вообщем вроде все как надо. Пишу по адресу 0x00 в 24LC00 значение (в этом примере 0x56), а читаю (Random Read, то есть по конкретному адресу) почему то 0xFF (то есть ничего не записалось получается, т.к. в памяти EEPROM по умолчению сидит 0xFF). Картинки в приложении. Вроде все верно. Пока не понял в чем дело. Может у вас есть какие-то идеи...

Вот описание 24LC00
http://ww1.microchip.com/downloads/en/DeviceDoc/21178E.pdf

А где repeated start при чтении??

Да, кстати его и нет. Спасибо!

Как это не смешно я перелопатил все примеры от TI, но так и не понял, как ИМЕННО в MSP430F2013 cделать этот repeated start. Такое впечатление, что его нужно делать "вручную", но никакого приятного глазу решения так и не придумал. Может что подскажете?

Я просто на данный момент задачу подругому решил (repeated start не понадобился), но интерес распирает...

Именно "вручную"

При первом START'e все так и есть. Но проблема в том, что у меня после переданного байта SDA low, а SCL high. То есть мне надо сделать SCL low, а потом SDA high... Ну то есть получается, что я NACK должен выплюнуть перед START...

Дык я не понял, в чем затруднения-то? В каком именно месте NACK смущает? Выдержка из спецификации I2C.

Смущает то, что никакого NACK быть не должно
http://ww1.microchip.com/downloads/en/DeviceDoc/21178E.pdf (Figure 8-2)

А откуда он там по-вашему должен получаться? Ведь после передачи 8-и бит SCL тормозится. Далее зарядили через USICNT передачу одного бита со значением 0. Это будет передачей ACK. После передачи одного бита (ACK) SCL опять тормозится. Формируем "вручную" повторный старт. Заряжаем следующие 8 бит на прием или передачу. Записываем 8 в USICNT. Поехали. Где тут "лишний" NACK получается-то?

После ACK линия SDA остается на нуле, соответственно по описанному в даташите методу никакого START не будет...

Вообще то после чтения последнего байта надо NACK выставлять, так устройство поймет что больше ничего передавать не надо, это везде так. И в даташите это написано (на картинках).

Еще раз смотрим
http://ww1.microchip.com/downloads/en/DeviceDoc/21178E.pdf (Figure 8-2)

да бага значит в даташите! должен быть NACK по идее.

Вообще-то это ACK, который формирует память в ответ на ваши байты. И который говорит вам о том, что адрес она "скушала". В первой посылке вы сформировали R/W = 0, значит вы передаете байты а память отвечает вам ACKи. И так до стопа или повторного старта. Сформировали стоп-старт или повторный старт, передали первый байт с R/W=1 - все, теперь память посылает байты а вы ей в ответ - ACKи. И снова до стопа/повторного старта.

Так вот вопрос в том, КАК!!! послать после ACK'а, который я получил - повторный старт.

С точки зрения сигналов - подаете 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)? Насколько там по времени потеря в сравнении (в зависимости от частоты конечно)?

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

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