Добрый день, коллеги. Подскажите, что не так я делаю? Имеется PIC16LF628A (мастер) и 24LC512 (слейв); программный i2c из примеров HT-PICC 9.80. Пытаюсь записать один байт по адресу, скажем, 0:
1. Посылаю старт-условие и управляющий байт (0b10100000);
2. Посылаю 2 байта адреса (нули);
3. Посылаю байт данных (например, 0xAA);
4. Посылаю стоп-условие.
Прием байтов (пп. 1-3) слейв подтверждает, затем контроллер генерит стоп-условие, однако память почему-то в это время держит SDA в нуле, поэтому стоп условия не получает. Зациклил для наблюдений такой кусочек кода:

Симуляция в протеусе показывает, что слейв не отпускает SDA:

В реальном железе наблюдаю настоящим осциллографом то же самое. в линиях включены резисторы по 150 Ом, со стороны контроллера "стоповый" импульс примерно 2 В, со стороны памяти совсем маленький...
В даташите процесс записи нарисован так:

Вроде все правильно делаю, а работает неправильно.
Прилагаю модель для протеуса и прошивку, хелп!

Я извиняюсь за такой вопрос, но есть ли у вас на линиях шины I2C pull-up резисторы? Если есть, то какого номинала? "в линиях включены резисторы по 150 Ом" - это о них или о резисторах, включенных последовательно с линией?
И еще. Вы зря сразу стали пробовать запись. Попробуйте вначале проверить алгоритм работы I2C на чтении EEPROM.

Подтяжка, естественно есть, по 10 кОм; 150 Ом последовательно в линиях SDA, SCL между памятью и МК. С чтением тоже проблемы, но еще глубоко не копал в чем дело, сейчас этим занимаюсь. Кстати, забыл сказать - все тайминги в хайтековском модуле i2c.h увеличил в 100 раз, чтоб удобней было осциллографом смотреть.

Сообщение отредактировал stas00n - Jan 10 2011, 11:50

Слейв может держать SDA если хочет выдать на шину данные, либо выдать бит ACK. Так как вы туда записываете, то остается последний вариант. Может вы на шине CLK не додаете 1 такт чтоб слейв закончил выдавать acknowledge? (Т.е. он выдает ACK, а фронт по CLK который заканчивает эту операцию, слейв не получает)

p.s.
А подтяжка должна быть посильнее 10 кОм

Такты считал - ровно 9 штук:
А резисторы 10кОм рекомендованы для частоты 100 кГц, у меня будет намного меньше.

9-й такт должен закончится нулем. В единичном состоянии CLK, слейв не имеет права менять сигнал на SDA. попробуйте дернуть CLK еще раз, посмотрите что поменяется.

Да! так заработало! Подправил макрос i2c_Stop() и вуаля, все пишется и читается! Спасибище огромное! А ведь исходник-то "фирмовый" хайтековский, вот ведь как бывает..

Кстати, напряжение половины уровня лог.1 может также свидетельствовать о некорректности реализации алгоритма I2C, когда лог.1 выдается мастером не ОК или Z-состоянием выхода SDA, а нормальной лог.1. При этом к питанию линию "тянет" транзисторный выходной каскад, а не внешний pull-up резистор. Проверьте, что это не так.

rezident, да есть такое дело, для дергания выводами в хайтековском модуле применяются макросы SDA_HIGH(); SDA_LOW() и т.д.:

Может, стоит изменить их на такие:
?

Сообщение отредактировал stas00n - Jan 11 2011, 08:00

В том месте мастер должен быть неактивен, а 24LC512 выводить бит ACK. Может быть там на короткий момент происходит конфликт на шине когда слейв выдает 0, а мастер тянет к логической 1.



Теоретически так и надо

Дык это уже криминал. Никто на шине I2C не имеет права тянуть ее принудительно к лог.1 ни в какой момент времени.

Тем не менее, такие вот фокусы подсовывает хайтек. Реализация i2c из папки с примерами из комплекта компилятора. Уже начинаю думать - не проще ли было бы самому с нуля написать?

Может и не проще, но уж точно полезнее. Вылавливать глюки в чужих программах сложнее, особенно когда для них нет никакой внятной документации (хотя бы в виде описания алгоритмов).

Да нет, ACK нормально проходил, мастер переключался на вход, конфликт возникал позже, когда мастер пытался послать стоп-условие установкой выхода SDA в "1" (к тому же, как выяснилось, - некорректно), а слейв держал SDA в нуле из-за того что отрицательный фронт не поступал на SCL после передачи ACK.
Сейчас все исправил, работает