Цитата(*rust* @ Oct 12 2011, 11:10)

Поэтому получается, что MSP держит ckock после бита R\W перед битом ASK, до тех пор, пока байт не загрузится в UCBxTXBUF,
Правильно. А как же иначе управлять асинхронным процессом? Тут нет никакого криминала, все в пределах спецификации I2C.
Цитата(*rust* @ Oct 12 2011, 11:10)

т.к FTDI имеет источники тока на выходах SDA и SCL, которые позволяют даже на низком сопротивлении open drain иметь такую ступеньку. На картинке ASK clock похож как бы на стул. Так вот спинка этого стула, это момент когда MSP отпустил линию SCL.
Э-э-э, позвольте! Что за источники тока? Источники
втекающего тока (внутренний pull-down)?

Дык это явное нарушение
спецификации I2C! В соответствии со спецификацией входной ток должен быть не выше ±10
мкА, т.е входное сопротивление не менее 500кОм. И причем тут спрашивается MSP430? Выходной каскад пина MSP430 вполне способен принять входной втекающий ток 15мА, создав при этом уровень напряжения VOL не выше 0,6В. В даташите это явно указано. По спецификации I2C для Standard- и Fast-mode требования для VOL гораздо скромнее: не менее 3мА@0,4В и не менее 6мА@0,6В. По вашей картинке в момент конфликта на шине уровень примерно в полпитания. Если MSP430 в это время тянет шину к нулю, то выходит, что FTDI выдает лог.1 с током не меньше 30-40
мА. То бишь проблема-то в FTDI заключена. С какого фига она выходной ток лог.1 создает в тот момент, когда его быть не должно?
Сделайте эксперимент, уменьшив pull-up резисторы на шине до 560 Ом. Что при этом будет? Увеличится ли высота "сидения стула"?
Ну и смотрите внимательно настройки FTDI, возможно вы ее неправильно конфигурируете для работы с I2C.