Помогите. У меня MSP430F169 у него есть модуль I2C. Но пока не могу понять... Написано, что I2C генерирует АСК после каждого полученного байта, а у меня устройство(DS1337), которое перестаёт передавать мне, когда получит NACK.
Причем, иногда работает и так, но очень часто вешает всё напрочь;( Опускает SDA и всё... Приходится снимать питание с часиков!
Вот... Может у кого-нить есть какие-нибудь идеи?

Аппаратные модули I2C довольно сложные и запутанные устройства, причем не только в MSP430. ИМХО если требуется общаться только с аппаратными I2C-slave (RTC, EEPROM) и не требуется реализация поддержки режима "мультимастер", то программная реализация I2C-мастер попроще будет, чем освоение аппаратного модуля I2C.

Понятно... Мне уже приходила в голову такая идея Хотелось по человечески, а получется надо как всегда...
Спасибо за ответ.

Зря

Это нормальное поведение любого устройства - по NACK прекращать передачу. Более того, это единственный способ для мастера закончить прием. Поэтому принимая последний байт вы должны сформировать NACK. Может невыполнение этого условия и вводит всю вашу систему в ступор?

Может быть... Вот только я никак не пойму, как через стандартный модуль MSP430F169 I2C послать NACK! Сейчас вроде запустил, но если верить документации на DS1337 - как оно сейчас работает без NACK оно вообще не должно работать

А генерации STOP-условия разве недостаточно для завершения приема? Условия формирования его в Table 15−1.Master Operation из User's Manual указаны.

Для генерации STOP линия данных должна быть в 1. Точнее, слейв не должен ее тянуть в ноль. Если не сформировать NACK, то к моменту формирования STOP слейв выставляет на шину первый бит следующего байта, который вполне может быть и нулем. И сформировать STOP будет невозможно.

P.S. С аппаратным I2C в MSP не работал.

Я тоже с этим модулем не работал. Просто чисто логически сделал вывод, что если задать ему STOP-условие, то модуль сам сформирует и NACK и STOP-условие.

Знаете, очень похоже что Вы оказались правы! Именно так я и реализовал, что ,как я замечал в предыдущем посте, мне кажется немного расходится с документацией! В дукументации написано что после адреса регистра надо сказать шине рестарт, но так у меня она не заработала Я честно генерю стоп, а после этого снова старт - и вот так она заработала Странно!!!
Но тьфу-тьфу... пока работает!:) Что вообщем не может не радовать! Всем кто откликнулся на призыв о помощи, большое спасибо!:)

Вот только возникла другая проблемка!:( Часики у меня на батарейки, а вот микропроцессор нет! В итоге, если пропадает питание во время передачи по I2C, часики блокируют шину(Опускают SDA) и не отпускают её Как только снимаю батарейку, они сбрасываются и разблокируют шину! Вот как с этим бороться я не знаю! Только схему наверное придется править!:( Может кто знает, что можнор сделать в данном случае?

В рекомендациях по инициализации шины I2C пишут, что после подачи питания неплохо бы "поклокать" шину. Т.е. не создавая START- или STOP-условий просто генерировать сигнал SCL, чтобы таким вот как RTC зависшим устройствам давать возможность "прочухаться". Количество тактов SCL не менее 10 желательно.

Ага... Вот как... Попробую сегодня!;) А идея не плоха.... Вообщем-то логично!;) Спасибо! Попробую отпишу!;)

Вот блин "невезуха" %) Не удалось привести шину в такое состояние Но инициализацию написал и оставил, чисто на всякий случай!:) Большое спасибо rezident'у за помощь, а особенно за последнее предложение, вообщем всё гениальное просто!:)

Предложение было очень правильное! Спасибо! Разглючил!) Всё оки!