Добрый день, коллеги. Подскажите, что не так я делаю? Имеется 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 раз, чтоб удобней было осциллографом смотреть.

Слейв может держать 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() и т.д.:

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

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



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

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

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

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

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