| |
 Программный I2C, Непонятный и интересный глюк DS1307 |
|
|
|
|
 Nov 29 2009, 18:11
|
Местный
Группа: Участник
Сообщений: 403
Регистрация: 14-05-07
Из: Россия, г.Пенза
Пользователь №: 27 719
|
Нашел кое чего, возможно будет интересно. Цитата 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... Хорошо что платы в производство не отдал  Цитата(rezident @ Nov 29 2009, 20:47)  Как-то уже слабо в это верится.  В то, что читаете. Потому, что после этого сообщения Вы должны были выложить исходники реализации "программного I2C". Хотя не исключено, что для вас , то бишь не решить проблему, а "замазать" ее Хорошо выкладываю, хотя дело не в ней... хотя возможно она хороша для EEPROM но не годится для других I2C девайсов. main называется stdiodemo.c , аппаратный I2C в "головном", остальные (UART, LCD) размазаны... программный модуль I2C называется I2csw.c и еже с ним...
Сообщение отредактировал manul78 - Nov 29 2009, 18:17
--------------------
" Многие вещи нам непонятны не потому, что наши понятия слабы; но потому, что сии вещи не входят в круг наших понятий." (с) К.Прутков.
|
|
|
|
|
|
|
|
Nov 29 2009, 18:28
|
Гуру
Группа: Свой
Сообщений: 10 920
Регистрация: 5-04-05
Пользователь №: 3 882
|
Цитата(manul78 @ Nov 29 2009, 23:11) Вывод: 1) Дорабатывать софт, под конкретное устройство. Да не под конкретное устройство, а в соответствии со спецификацией I2C!!! Спецификацией, которую вы упорно не желаете изучить, а игнорируете. В противном случае вы давно бы переделали функцию там, где после установки SCL (и SDA) в HI вы почему-то не делаете проверку состояния, а действительно ли линия SCL установилась в HI? Ведь именно в такие моменты RTC может подтормаживать обмен "растягивая" низкий уровень SCL. Причем замечу, что "растягивая" в полном соответствии со спецификацией I2C! P.S. хотя, посмотрев в даташит DS1307, признаю, что я немного преувеличил. SCL у нее чисто входной сигнал и растягивать SCL она не может. Но для реализации программного интерфейса I2C все, мною написанное, верно. Входная и выходная логика автомата состояний I2C должны быть связаны именно состояниями шины, а не состояниями битов регистров периферии GPIO.
|
|
|
|
|
|
|
|
Nov 30 2009, 00:23
|
Местный
Группа: Участник
Сообщений: 403
Регистрация: 14-05-07
Из: Россия, г.Пенза
Пользователь №: 27 719
|
Цитата(rezident @ Nov 29 2009, 21:28) 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 и "замазать" проблему...  Всё равно всем спасибо за поддержку !
--------------------
" Многие вещи нам непонятны не потому, что наши понятия слабы; но потому, что сии вещи не входят в круг наших понятий." (с) К.Прутков.
|
|
|
|
|
|
|
|
Nov 30 2009, 01:07
|
Гуру
Группа: Модераторы
Сообщений: 8 455
Регистрация: 15-05-06
Из: Рига, Латвия
Пользователь №: 17 095
|
Цитата(manul78 @ Nov 30 2009, 02:23) Многочисленные переключения с входа
на выход и обратно к хорошему не приведут как я думаю, хотя не пробовал ещё... Уууу... А ведь rezident в самом первом ответе вам сказал, что делать надо именно так. Если вы упорно выставляете на шину единицу выходом контроллера, то можете до посинения шаманить, борясь с чудесатыми граблями, которые сами себе любовно разложили. Вот вам для размышлений: http://electronix.ru/forum/index.php?showtopic=29602
--------------------
На любой вопрос даю любой ответ"Write code that is guaranteed to work, not code that doesn’t seem to break" ( C++ FAQ)
|
|
|
|
|
|
|
|
Nov 30 2009, 17:31
|
Гуру
Группа: Свой
Сообщений: 10 920
Регистрация: 5-04-05
Пользователь №: 3 882
|
Цитата(manul78 @ Nov 30 2009, 05:23) Значит получается что следующая информация конкретно на DS1307 не распространяется ? Нет, не распространяется. Цитата(manul78 @ Nov 30 2009, 05:23) Т.е. Вы хотите сказать что на линии SCL в DS1307 нет ключа "на землю" для реализации данной функции ? Судя по описанию в даташите, нету. Цитата(manul78 @ Nov 30 2009, 05:23) Кстати, даже наличие "гармошки" не избавляет от проблем, а только прибавляет их. Многочисленные переключения с входа
на выход и обратно к хорошему не приведут как я думаю, хотя не пробовал ещё... Жесть!  Я вам еще раньше написал, что это одна из типовых ошибок программной реализации I2C! И после этого вы все еще настаиваете на том, что внимательно читаете все ответы? Не верю! (с)
|
|
|
|
|
|
|
|
Dec 9 2009, 19:28
|
Местный
Группа: Участник
Сообщений: 403
Регистрация: 14-05-07
Из: Россия, г.Пенза
Пользователь №: 27 719
|
Исправил библиотеку в соответствии со стандартом I2C, добавил возможность вывода DS1307 из "ступора" посредством посылки 9 и более импульсов CLOCK при инициализации шины, так-же добавил возможность нескольких попыток доступа к шине в случае её не готовности. Все файлы снабдил подробными комментариями. Выкладываю source файлы + даташиты на DS1307 и полную спецификацию стандарта I2C в одном архиве. Буду рад любым дельным советам и конструктивной критике. На столе всё работает отлично. Брака - 0%. Расстояние линии 50 см., но так как "девайс" будет работать днём и ночью, зимой и летом на улице питаясь от заводской сети в окружении пускателей, ТЭН-ов, коллекторных двигателей постоянного тока и их тиристорных приводов, то тема я думаю пока ещё не закрыта... Сейчас доделываю эмулятор-генератор промышл- енных помех для тестов "на столе"... Вот когда я и "девайс" пройдем все круги ада, тогда можно будет тему закрывать. Еще раз спасибо всем !
Сообщение отредактировал manul78 - Dec 9 2009, 19:30
--------------------
" Многие вещи нам непонятны не потому, что наши понятия слабы; но потому, что сии вещи не входят в круг наших понятий." (с) К.Прутков.
|
|
|
|
|
|
|
|
Dec 10 2009, 06:38
|
Местный
Группа: Участник
Сообщений: 315
Регистрация: 5-05-08
Из: Kursk
Пользователь №: 37 282
|
Цитата(manul78 @ Dec 9 2009, 22:28) На столе всё работает отлично. Брака - 0%. Расстояние линии 50 см., но так как "девайс" будет работать днём и ночью,
зимой и летом на улице питаясь от заводской сети в окружении пускателей, ТЭН-ов, коллекторных двигателей постоянного тока и их тиристорных приводов, то тема я думаю пока ещё не закрыта... На столе и будет работать,в цеху при длине больше 1-1,5м даже на100кгц будет сбоить а больше 2м не работает проверено! Вообще-то I2C ВНУТРИПРИБОРНЫЙ ИНТЕРФЕЙС,несколько раз переделывал на обьектах разработки такого типа,всё работало но вдруг рядом электрик дядя вася поставил электрошкаф с насосом и перестало работать или перенесли силовую электропроводку,передвинули на 3м технологическое оборудование с вашим датчиком и пр. Для измерения температур есть стандарты, соответствующие датчики и очень желательно их придерживаться,во избежании проблем себе и другим. А если разработчик ищет лёгкие пути с интегральными датчиками да ещё и с I2C то он откровенно слаб как конструктор и бездумно использует готовые шаблонные решения скачанные порой с интернета. Вопрос использования этого интерфейса в промышленном окружении,неоднократно поднимался на форуме и как минимум 2 разработчика уже наступали на эти грабли.Поищите в поиске здесь на форуме. А по прохождению всех кругов ада ,так вы однако инженер(программист)-мазохист ! 
Причина редактирования: Излишнее цитирование.
--------------------
"Если я в чем-то сомневаюсь, я возвращаюсь к началу"
|
|
|
|
|
|
|
|
Dec 10 2009, 15:08
|
Местный
Группа: Участник
Сообщений: 403
Регистрация: 14-05-07
Из: Россия, г.Пенза
Пользователь №: 27 719
|
Цитата(Verifi @ Dec 10 2009, 09:38) А если разработчик ищет лёгкие пути с интегральными датчиками да ещё и с I2C то он откровенно слаб как конструктор и бездумно использует готовые шаблонные решения скачанные порой с интернета. У меня не интегральный датчик, а часы (RTC) ВЫ1307. Других вариантов нет, т.к. в МК который я использую в своем девайсе есть всё что мне нужно, кроме аппаратного I2C (TWI). А по поводу мазохизма, это Вы зря, есть такое понятие профессиональный перфекционизм. Изделие должно быть простым как всё гениальное, надежным как автомат Калашникова, и красивым как Афродита...
Причина редактирования: Излишнее цитирование.
--------------------
" Многие вещи нам непонятны не потому, что наши понятия слабы; но потому, что сии вещи не входят в круг наших понятий." (с) К.Прутков.
|
|
|
|
|
|
|
|
Dec 11 2009, 06:18
|
Местный
Группа: Участник
Сообщений: 315
Регистрация: 5-05-08
Из: Kursk
Пользователь №: 37 282
|
Цитата(manul78 @ Dec 10 2009, 18:08) А по поводу мазохизма, это Вы зря, есть такое понятие профессиональный перфекционизм. Изделие должно быть простым как всё гениальное, надежным как автомат Калашникова, и красивым как Афродита... Целиком и польностью согласен,но не понятно зачем если в контроллере нет аппаратного i2c так мучаться с программной реализацией-есть же специализированные преобразователи интерфейсов,тем более I2C(он же для телевидео) не для цеховых условий эксплуатаций.
--------------------
"Если я в чем-то сомневаюсь, я возвращаюсь к началу"
|
|
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
