Начну по порядку.

Мне понадобилось подключить RTC DS1307 к AVR микроконтроллеру не имеющего TWI модуля. У меня есть самодельная
универсальная отладочная плата на ATmega16. На ней я "откатываю" софт. На борту имеется RS-232, LCD дисплей, и со-
ответственно RTC DS1307. На данной плате я решил не использовать TWI, а занятся "ногодрыганием"...
Скачал готовую рабочую библиотеку, слегка подправил её и вот что получается:

Читаю посредством дерганья ногами раз на раз не приходится, то всё хорошо, то лобуда полная...
Читаю посредством TWI все ОК. Ноги использую те-же самые.
Подключил JTAG более менее выставил задержки, процент "брака" уменьшился но не без него. Заметил, что после сброса
МК часы вообще перестают вести себя адекватно, но аппаратный TWI читает всё четко. Появилась мысль, что при сбросе
МК дергает порты, и DS1307 воспринимает это как СТАРТ (RTC подключен к батарейке, соответственно "не спит" и не сбра-
сывется ) и соответственно впадает в своеобразный ступор, т.е. ждет дальнейших сигналов от хоста. Изменил программу,
сделал возможность по одной команде от терминала читает через TWI , по другой "ногодрыганием". Думал используя аппа-
ратный буду выводить DS1307 из ступора после сброса... Ничего подобного, аппаратно читает отлично - программно полную
чушь... решил еще задействовать ЛСД для отслеживания потока... и всё заработало, но не потому, что я там что-то отсле-
дил, а потому, что ЛСД дисплей начал кушать ток...

Вот теперь получается такая петрушка: При подключенном ЛСД и JTAG-е всё работает как без проблем. Никаких глюков.
Отключаю либо ЛСД либо JTAG - всё - пошла лобуда. Напряжение чёткое 5 В . Блок питания 4 Амперный, им чай кипят-
ить можно... Аппаратный TWI работает во всех случаях без проблем, читает всё как надо.

Кто сталкивался с подобными глюками подскажите пожалуйста где засада. Еще просьба, возможно имеется более по-
дробное описание DS1307, т.к. стандартный даташит вообще "не о чем". Меня интересуют таймы ACK и пр. не описанные,
а так-же интересно поведение микросхемы при прерванных передачах и пр. конфликтах на шине, и соответственно
выход из данных состояний.

В оригинальной спецификации I2C от Philips есть рекомендация, которая гласит о том, что после подачи питания нужно поCLOCKать линией SCL. Не менее 9-и тактовых импульсов без старт- или стоп-условий. Это нужно как раз для того, чтобы вывести в нормальный режим "впавшую в ступор" логику I2C-slave. Второй типовой ошибкой программной реализации I2C является управление лог.1 на выходах, подключенных к шине, вместо того, чтобы использовать open-drain или Z-состояние пинов GPIO.

Сталкивался с разными особенностями работы этой м/c, но то о чем Вы пишете слышу в первый раз.
DS1307 очень устойчиво работает на скоростях 100kHz и ниже, при соблюдении Vbat = 3..3.3V, Vcc >= 4.5V.
На скоростях выше 100kHz - она принципиально не работает!
Вероятно баг в софтовой библиотеке которую вы взяли. Баг с таймингами.
Когда подключаете JTAG и LCD что-то где-то подтормаживает и выравнивает тайминги.

БП используете импульсный или линейный? Если импульсный возможно имеют место кратковременные провалы Vcc DS'ки ниже 4.4V, которые приводят к отрубанию ее i2c интерфейса даже посреди активной транзакции.

Спасибо всем за информацию и советы.

Не буду утомлять подробностями, но помучился конкретно. Пробовал всё, и программно и с подтягивающими резисторами
игрался, рассчитывал по формуле RPU = tr (Rise time) / Cb (Capacitance load) - не помогло... Спаял еще одну схему RTC на
отдельной плате и с ней всё заработало. Что было, смешно говорить... кривая "земля"... выровнял потенциалы и всё. Ради
прикола прогнал все свои программные варианты, и как по волшебству все заработали... вот-так. Кстати надо отдать дол-
жное аппаратному TWI - работал безупречно даже с подтягивающими резисторами в 47кОм и 750 Ом... Железо

Теперь осталось пройти "Антарктиду" и "Сахару" а так-же "болтанку" при -25 и при +50... Если кому интересно, могу
рассказать результаты данных путешествий...

А я был поражен когда понял, что аппаратное TWI у меня работает __без__ подтягивающих резисторов вообще! На одной шине мега мастре и 3 меги слейва, DS'ка и AT24 (400kHz). Все работало прекрасно, потом совсем случайно заметил, что а pull-up'ов то нет...

"Чьёрт побьери..." (с) "Бриллиантовая рука"

Опять не работает...
Стоило увеличит линию связи до 20 см. и всё... "кирдык". Даже на старт не реагирует... (аппаратный TWI работает)
Сдаётся мне это емкостные дела. т.к. по даташитам емкость каждого канала I2C около 10-20 пФ, то у портов Меги она
как мне кажется намного выше + емкость самой линии... эх осциллоскопа цифрового нет !

Кто нибудь знает ёмкость портов у АТмег ? Ещё мысль посетила, что в процессе "ногодрыгания" слишком быстро проис-
ходит нарастание и падение фронтов, что вкупе с длинной линией не есть гут.

Смотрел функциональную схему аппаратного TWI, на входах-выходах там стоят схемы ограничения скорости нарастания и
помехоподавляющие фильтры. Как реализована схемотехника не известно. Посещает мысль использовать четыре ноги МК
вместо двух. Первая пара будет работать на состояние линий, а вторая подключенная параллельно только читать... Что
скажете ? Бредовая идея ?

Значит, пуллапы где то были.
На 400 кГц и с нормальными пуллапами на 2 кОм нарастающий фронт весьма поганый, не представляю, что там могло быть при подтяжке большим сопротивлением, а главное - какая при этом была реальная скорость интерфейса

об I2C и покруче Вас люди зубы ломали... Связать аппаратный TWI Меги и DS1307 любой дебил за один рабочий час сможет.
А вот настроить программный I2C при плавающем питании от 3.3 до 5 и рабочих температурах от -25 до +40 совсем другой
разговор..., так шта тусуйтесь в "курилке" уважаемый, если по делу сказать нечего...

P.S. Кстати Cyfral со своими дверями и домофонами используя AVR и I-Button (копеечные технологии) зарабатывают в
тысячу раз больше, чем Вы со своими blackfin-ами...

уже у "любого дебила" сил не хватает?

Вооружитесь осциллографом и спецификацией на I2C и увидите воочию все ваши проблемы.


А выполняют ли эту рекомендацию аппаратные контроллеры?
К примеру, при сопряжении STM32 и DS3231 это пришлось организовавать софтом, иначе иногда DS подвисала...

Аппаратно? Самостоятельно? Конечно нет! Модуль I2C (TWI) в МК нужно сначала проинициализировать, чтобы он заработал в режиме мастера. И вообще он может не использоваться в проекте или использоваться только как слейв. С какого тогда перепуга модуль I2C (TWI) должен сам какие-то импульсы по SCL генерировать?

Был-бы у меня сейчас под рукой цифровой осцилоскоп, стал-бы я вам тупые вопросы задавать...



Выполняют или нет не знаю. Я лично ставлю число попыток доступа к шине и посылаю в цикле START затем SLA+R до
получения ACK. Надо отметить не всегда отзывается с первого раза, даже если на шине всего одно устройство.

Зачем, спрашивается, задавать вопросы, если ответы вы не читаете? Я же вроде понятно написал и дал ссылку на спецификацию. После подачи питания нужно дать ≥9 импульсов по SCL без старт-условий!!!!

Ваши слова:

навели на мысль, что эти рекомендации относятся только к программной реализации I2C
Соответственно, в случае аппаратной они должны выполняться аппаратурой автоматически.

Вообще, подвисонов логики слэйвов в моей небольшой любительской практике не встречалось.
Кроме чипа DS3231. Но у него этот момент оговорён в даташите, и, имхо, является следствием бесперебойного функционирования часов от батареи, в отличие от управляющего контроллера.


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

Не нервничайте. Ответы я читаю. В данном случае я обращался к sonycman. Речь шла об аппаратном интерфейсе.

Теперь по делу: Две совершенно одинаковых RTC схемы на основе DS1307. Единственную между ними разницу я нашел это
buckapp батарейки одна Panasonic другая Maxwell... и шлейфы подключения 1) 3 см 2) 20 см

1) Работает исправно, но если читать всю память (64 байта) то иногда происходит срыв передачи в совершенно случайном
порядке. Корректных передач около 80%. Аппаратный читает всё четко - 100%

2) Не читает вообще. Не реагирует даже на START, т.к. уже после первой транзакции SLA+R нет ответа ACK.
Аппаратный читает всё четко - 100%. Грешил на повышенную емкость линии, повышал подтягивающие резисторы
от стандартных 4К7 до 15К - результат ноль. Аппаратный 100%. Начал грешить на недостаточный ток (3мА по специфи-
кации) и поехал в другую сторону - плавно понижал пулаппы до 1.5К - результат ноль. Аппаратный 100%.
Грешу на нарастание и спад фронтов. Осцилограф у меня есть только аналоговый, завтра попробую написать цикличес-
кие подпрограммы и для TWI и для программного I2C дабы сравнить фронты и пр. характеристики.


P.S. Неделю назад Harbinger мне поведал аналогичную историю как они замучались с программным I2C и в конце концов
плюнули на всё это и поставили отдельный аппаратный I2C контроллер. Т.е. он дал понять, что программный I2C
капризное и ненадежное решение годное только для "тепличных условий". Прошу всех столкнувшихся с данной
проблемой откликнутся, дабы я не бился лбом об стену. Возможно проще и надежней окажется изменение схемо-
теники устройства, т.е. переход на другую RTC, например с параллелельным или SPI интерфейсом.

Как-то уже слабо в это верится. В то, что читаете. Потому, что после этого сообщения
Вы должны были выложить исходники реализации "программного I2C". Хотя не исключено, что для вас
, то бишь не решить проблему, а "замазать" ее

Нашел кое чего, возможно будет интересно.




Англичанин пишет о "подводных камнях" в программной реализации I2C. Смысл в следующем, что примитивные устрой-
ства типа EEPROM работают обычно без проблем, т.к. передача идет непрерывно байт за байтом, а вот с другими I2C
устройствами "засада" в плане, что иногда устройство не может в данный момент передать байт информации и соответ-
ственно если аппаратный I2C может ждать, то программный пролетает и соответственно выдает некорректные данные.
В моём случае когда DS1307 передает данные возможно совпадение по обращению, т.е. попытка считать и передать на
шину например информации из ячейки "минуты", в тот момент когда RTC производит туда запись (инкремент минут).
На данную операцию приоритет выше, соответственно происходит задержка в передаче и как следствие срыв передачи
в программной реализации I2C.

Вывод: 1) Дорабатывать софт, под конкретное устройство.
2) Использовать RTC с аппаратным интерфейсом имеющимся на борту МК, в моём случае SPI (DS1305, DS1306)
места занимают больше и стоят соответственно дороже.

Если не удастся грамотно реализовать пункт 1, придется делать пункт 2... Хорошо что платы в производство не отдал



Хорошо выкладываю, хотя дело не в ней... хотя возможно она хороша для EEPROM но не годится для других I2C девайсов.

main называется stdiodemo.c , аппаратный I2C в "головном", остальные (UART, LCD) размазаны...
программный модуль I2C называется I2csw.c и еже с ним...

Да не под конкретное устройство, а в соответствии со спецификацией I2C!!! Спецификацией, которую вы упорно не желаете изучить, а игнорируете. В противном случае вы давно бы переделали функцию там, где после установки SCL (и SDA) в HI вы почему-то не делаете проверку состояния, а действительно ли линия SCL установилась в HI? Ведь именно в такие моменты RTC может подтормаживать обмен "растягивая" низкий уровень SCL. Причем замечу, что "растягивая" в полном соответствии со спецификацией I2C!
P.S. хотя, посмотрев в даташит DS1307, признаю, что я немного преувеличил. SCL у нее чисто входной сигнал и растягивать SCL она не может. Но для реализации программного интерфейса I2C все, мною написанное, верно. Входная и выходная логика автомата состояний I2C должны быть связаны именно состояниями шины, а не состояниями битов регистров периферии GPIO.

Значит получается что следующая информация конкретно на DS1307 не распространяется ?



Т.е. Вы хотите сказать что на линии SCL в DS1307 нет ключа "на землю" для реализации данной функции ?

Кстати, даже наличие "гармошки" не избавляет от проблем, а только прибавляет их. Многочисленные переключения с входа
на выход и обратно к хорошему не приведут как я думаю, хотя не пробовал ещё... Была мысль задействовать еще пару
портов чисто на вход как зонды состояния шины, подключив их параллельно. Гораздо меньше переключений и соответст-
венно отсутствие помех на шине. Т.е. 2 порта находящихся по мере надобности либо в Z состоянии (DDR -вход, PORT-1) и
лог 0 (DDR - выход, PORT - 0). Имитация I2C . И 2 порта исключительно на чтение (DDR -вход, PORT-1) , возможно
получится... Ешё грешу на слишком быстрые нарастания фронтов, возможно и из за этого обрывы передач. С фронтами
что делать не знаю. Емкость линии попробовать увеличить ?

Ежели не получится придется перейти на SPI и "замазать" проблему... Всё равно всем спасибо за поддержку !

Уууу... А ведь rezident в самом первом ответе вам сказал, что делать надо именно так. Если вы упорно выставляете на шину единицу выходом контроллера, то можете до посинения шаманить, борясь с чудесатыми граблями, которые сами себе любовно разложили. Вот вам для размышлений: http://electronix.ru/forum/index.php?showtopic=29602

Нет, не распространяется.
Судя по описанию в даташите, нету.
Жесть! Я вам еще раньше написал, что это одна из типовых ошибок программной реализации I2C! И после этого вы все еще настаиваете на том, что внимательно читаете все ответы? Не верю! (с)

Исправил библиотеку в соответствии со стандартом I2C, добавил возможность вывода DS1307 из "ступора" посредством
посылки 9 и более импульсов CLOCK при инициализации шины, так-же добавил возможность нескольких попыток доступа
к шине в случае её не готовности. Все файлы снабдил подробными комментариями.

Выкладываю source файлы + даташиты на DS1307 и полную спецификацию стандарта I2C в одном архиве.
Буду рад любым дельным советам и конструктивной критике.

На столе всё работает отлично. Брака - 0%. Расстояние линии 50 см., но так как "девайс" будет работать днём и ночью,
зимой и летом на улице питаясь от заводской сети в окружении пускателей, ТЭН-ов, коллекторных двигателей постоянного тока и их тиристорных приводов, то тема я думаю пока ещё не закрыта... Сейчас доделываю эмулятор-генератор промышл-
енных помех для тестов "на столе"... Вот когда я и "девайс" пройдем все круги ада, тогда можно будет тему закрывать.

Еще раз спасибо всем !

На столе и будет работать,в цеху при длине больше 1-1,5м даже на100кгц будет сбоить а больше 2м не работает проверено!
Вообще-то I2C ВНУТРИПРИБОРНЫЙ ИНТЕРФЕЙС,несколько раз переделывал на обьектах разработки такого типа,всё работало но вдруг рядом электрик дядя вася поставил электрошкаф с насосом и перестало работать или перенесли силовую электропроводку,передвинули на 3м технологическое оборудование с вашим датчиком и пр.
Для измерения температур есть стандарты, соответствующие датчики и очень желательно их придерживаться,во избежании проблем себе и другим.
А если разработчик ищет лёгкие пути с интегральными датчиками да ещё и с I2C то он откровенно слаб как конструктор и бездумно использует готовые шаблонные решения скачанные порой с интернета.
Вопрос использования этого интерфейса в промышленном окружении,неоднократно поднимался на форуме и как минимум 2 разработчика уже наступали на эти грабли.Поищите в поиске здесь на форуме.
А по прохождению всех кругов ада ,так вы однако инженер(программист)-мазохист !

У меня не интегральный датчик, а часы (RTC) ВЫ1307. Других вариантов нет, т.к. в МК который я использую в своем
девайсе есть всё что мне нужно, кроме аппаратного I2C (TWI).
А по поводу мазохизма, это Вы зря, есть такое понятие профессиональный перфекционизм. Изделие должно быть простым
как всё гениальное, надежным как автомат Калашникова, и красивым как Афродита...

Целиком и польностью согласен,но не понятно зачем если в контроллере нет аппаратного i2c так мучаться с программной реализацией-есть же специализированные преобразователи интерфейсов,тем более I2C(он же для телевидео) не для цеховых условий эксплуатаций.

Там в программной реализации кода на час вдумчивого писания.