Программный I2C, Непонятный и интересный глюк DS1307 Опции

[manul78]

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

Мне понадобилось подключить 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 и пр. не описанные,
а так-же интересно поведение микросхемы при прерванных передачах и пр. конфликтах на шине, и соответственно
выход из данных состояний.

[manul78]

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

Wait a moment
That's almost it for simple I2C communications, but there is one more complication. When the master is reading from the slave, its the slave that places the data on the SDA line, but its the master that controls the clock. What if the slave is not ready to send the data! With devices such as EEPROMs this is not a problem, but when the slave device is actually a microprocessor with other things to do, it can be a problem. The microprocessor on the slave device will need to go to an interrupt routine, save its working registers, find out what address the master wants to read from, get the data and place it in its transmission register. This can take many uS to happen, meanwhile the master is blissfully sending out clock pulses on the SCL line that the slave cannot respond to. The I2C protocol provides a solution to this: the slave is allowed to hold the SCL line low! This is called clock stretching. When the slave gets the read command from the master it holds the clock line low. The microprocessor then gets the requested data, places it in the transmission register and releases the clock line allowing the pull-up resistor to finally pull it high. From the masters point of view, it will issue the first clock pulse of the read by making SCL high and then check to see if it really has gone high. If its still low then its the slave that holding it low and the master should wait until it goes high before continuing. Luckily the hardware I2C ports on most microprocessors will handle this automatically.

Sometimes however, the master I2C is just a collection of subroutines and there are a few implementations out there that completely ignore clock stretching. They work with things like EEPROM's but not with microprocessor slaves that use clock stretching. The result is that erroneous data is read from the slave. Beware!

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

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

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

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

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

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

Сообщение отредактировал manul78 - Nov 29 2009, 18:17

Прикрепленные файлы

 TEST_I2C.ZIP ( 125.85 килобайт ) Кол-во скачиваний: 45

 

[rezident]

Вывод: 1) Дорабатывать софт, под конкретное устройство.

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

[manul78]

P.S. хотя, посмотрев в даташит DS1307, признаю, что я немного преувеличил. SCL у нее чисто входной сигнал и растягивать SCL она не может. Но для реализации программного интерфейса I2C все, мною написанное, верно. Входная и выходная логика автомата состояний I2C должны быть связаны именно состояниями шины, а не состояниями битов регистров периферии GPIO.

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

Скорость обмена по шине TWI задается ведущим, т.к. именно он генерирует тактовые импульсы. Однако, если
ведомый не может принимать данные с такой скоростью или ему нужно время на обработку данных между приемом пакетов,
он может увеличить паузу между тактовыми импульсами, удерживая на линии SCL сигнал НИЗКОГО уровня

Т.е. Вы хотите сказать что на линии 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