Нашел кое чего, возможно будет интересно.
Цитата
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
" Многие вещи нам непонятны не потому, что наши понятия слабы; но потому, что сии вещи не входят в круг наших понятий." (с) К.Прутков.
Программный I2C, Непонятный и интересный глюк DS1307
Nov 14 2009, 02:02
