А если в битах для конфигурируемых ног уже были единицы в ненужных местах? Некоторые ноги при включении питания содержат отнюдь не нули в этих регистрах. Вы их пытаетесь перевести в режим альтернативной функции, но если он был перед этим настроен на вывод - вы переведете его в аналоговый режим. То есть даже если сейчас все и заработает, то потом дописав настройку этой ноги на вывод где-то в начале (не знаю зачем - например для организации сброса зависшего автомата ведомого выдачей 9 тактов ручным маханием ногами) вы получите эффект отваливания I2C в совершенно другом, никак не связанном с этим дописанным кодом месте. Мы ведь не знаем, что у вас там в начале программы творится, просто видим лежащую на ровном месте граблю, которую подложил себе человек, съевший собаку.
Я, честно говоря, не понимаю - что мешает прописать весь регистр один раз целиком, задав одной записью необходимое состояние сразу всех ног? Аналогично и с остальными регистрами при инициализации - вы же знаете, что было записано в этот регистр (или вам не нужно предыдущее состояние в начале инициализации). Так запишите еще раз этот регистр полностью, но с измененными нужными битами. А вот если потребовалось изменить группу битов в регистре, состояние которого не может быть известно точно - тогда надо позаботиться о правильном состоянии всех битов. И не двумя операциями - сбросом и установкой, ведь в этом случае вы между этими операциями переводите регистр в совершенно ненужное состояние, а считыванием во временную переменную, изменением группы бит в этой переменной и записью назад в регистр за один раз уже конечного результата.

Здесь я с Вами полностью согласен и поддерживаю. Я раньше так и делал, но пару раз по ошибке запорол SWD и после этого я делаю инит всех устройств в начале проги учитывая состояние регистров по умолчанию из даташита. При чём я не пользуюсь при этой методе сторонними библиотеками, а всегда пишу свои. По этому я знаю какой бит в каком регистре установлен. И в своих библиотеках я не делаю инициализации устройств, она у меня всегда в начале программы и если мне надо что-то с устройствами сделать, то я лезу туда.

Интересное замечание, всегда делал через 2 операции. Надо будет запомнить, спасибо...

Интерфейс наконец то ожил.
Но стопор получается после передачи номера регистра.

Ниже привожу осцилограмку жёлтый данные, а синий синхро.


Сообщение отредактировал glags - Jun 19 2014, 19:27

>> Но стопор получается после передачи номера регистра.
все статусы проверяете. не догоню жёлтый луч - это датчик ACK не дал?


угу http://www.st.com/web/en/catalog/tools/PF257884# => http://www.st.com/st-web-ui/static/active/...dperiph_lib.zip

Синий лучь в конце в низу это датчик синхру не отпускает. Я проверял отпаивая датчик.
Расшифровывая осцилограмку передаётся 0х90-адрес устройства и вслед 00-номер регистра. Точнее 0х9000. А дальше *опа, датчик держит линию синхронизации.

>> Ниже привожу осцилограмку жёлтый данные, а синий синхро.
оказывается я очень внимательный человек.

хм, а точно датчик держит?

Ну я ж написал, что точно. Я его отпаял и синхра поднялась. Как мне ещё объяснить?

Да. Датчик. Когда его убирали физически, этого нет, обе линии в 1 возвращаются.

Сейчас почитаю описание датчика, а пока небольшое замечание по стию.
Вот такую конструкцию
я всегда пишу так:

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

И в чем была причина? Во-первых нам любопытно, а во вторых, возможно, когда-нибудь на это обсуждение набредет кто-то с точно такой же проблемой и, разумеется, будет рад за вас, но ему информация "наконец-то ожил" не поможет никак. А ведь он будет тратить время, читать ветку... Представляете как ему будет обидно за потраченное на бесполезное чтение время?

Этого не может быть, потому что не может быть никогда:


Вы случаем на датчике SDA и SCL не перепутали?

Однако вселенная любит пошутить.
У меня сейчас на столе mega168+I2C 24C256C.
Правда память без блокировочных конденсаторов. Пишет по 64 байта только, при отправляемых 128, а при чтении в какойто момент зажимает SDA на землю.

Дык вселенная здесь не при чем. Источник шуток наверняка располагается где-то между стулом и клавиатурой. Вас не смущает, что у 24С256 размер страницы 64 байта?

я её и не обвиняю. действительно, прочитал внимательнее всё, т.к. тестил на разных: у 512/256/128 разный размер страниц.
спасибо

ОФФ:
ps. наврано даже на сайте атмел в описании 128-й
на страничке написано, что размер страницы 256 байт, а в доке - 64 байта.

По теме с "зажиманием" сигналов. Столкнулся с похожей ситуацией на АВР. Может и здесь подойдёт.
На самом деле никто и ничего не зажимает. Наступает неопределённое состояние контроллера из-за несвоевременной отправки STOP.
Причиной оказалась опечатка. Последний байт необходимо читать выставив NOACK, а по ошибке устанавливалось ACK. Контроллер
видя это неподобство просто складывал с себя полномочия.