наводки по фронтам
если это ловля кода по радиоканалу я бы еще поверил...

Радиоканал? С каких частот у нас радио начинается знаете? Ну а даже заваленые 20ns фронты LPX2000 великолетно наводятся на идущую параллельно висящую дорожку.

Сообщение отредактировал zltigo - Jun 17 2007, 22:23

Дык а фишка заключается в том, что Вы неразобравшись в Вашем конкретном случае
начинаете советовать остальным (неразобравшись в чем у Вас была проблемма)
как нужно организовывать обмен по i2c другим...
вот это и странно...

Знаю, но к приему сигнала по i2c без пулапов это не имеет никакого значения.
Ладно, если Вы не против довайте попробуем отвлечся и ответить на вопрос автора.


Вы понимаете что аппаратно формируемые сигналы от 24xx и от ATmegaxx имеют
по крайней мере разную форму ?
Все зависит от софта на Атмега...

Я разобрался в том, что:
1. AT24 очень НЕ КРИТИЧНА к качеству сигналов и шаманство с уменьшению pullup-ов маловероятно приведет к результату.
2. AT24 не имеет проблем с блочным режимом, по крайней мере при работе с железным I2C контроллером.
Кроме того, я разобрался в чем была конкретная проблема с конкретной платой.
О чем и написал - перечитайте пост №3.
Если Вам привиделись какие-то "советы" - это Ваши проблемы.

Я, к примеру, совершенно не удивился сообщению zltigo. И совершенно не понимаю что вас в нём удивляет? I2C - статическая шина. Следовательно поступающие сигналы не должны быть привязаны ко времени. Если подтяжки нет, то наводки на этих ножках рано или поздно но уложатся в нужный сигнал, как ни крути. Один раз я столкнулся со случаем работы контроллера дисковода (ВГ93) при обрезанном сигнале управления (то ли RD то ли WR уже не помню, но помню что совершенно необходимый). Тот милый человек, который смотрел эту плату до меня зачем-то перерезал его с помощью лезвия. Наверное потом хотел соплю кинуть, да подзабыл. Когда я нашёл настоящую неисправность и запустил злополучный синклер, то выяснил что дисковод работает, но только длинные файлы не читает. Причина выяснилась достаточно быстро. Анализирую ноги ВГ93 было обнаружено, что одна просто болтается в воздухе. Как я писал выше дисковод полностью работал и короткие файлы читал исправно.

zltigo спасибо за информацию Ваш пост я понял.

2 singlskv. Также спасибо. Я правда не совсем понял фразу

Софт на м48 писал, естественно я сам. Наверное Вы имели ввиду не "разную форму", а "работают по разному". Это, безусловно, я понимаю. Ещё раз повторяю. Если работа с at24 идёт побайтно, то никаких проблем не возникает. Два изделия работают круглосуточно больше месяца.

2 zltigo. При блочной записи. Записываю 32 байта. Границы верны. То есть принципиально всё пишется правильно. Вопрос достаточно ли одной задержки 10мс после записи страницы? Точнее части страницы. Помню в какой-то мне приходилось задержку на запись делать = Twr * число записываемых байт. Правда это в какой-то младшенькой памяти было.

Увы, я софтовой эмуляцией не занимался - работает железный контроллер все на прерываниях, т.е. никакие задержки не формируются - достаточно ACK.

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

Это-то я понимаю. Я спрашиваю про задержку после записи. Она же по-любому аппаратно не формируется.

2 Dog Pawlowa. Простите о каком бите готовности вы говорите? Я работаю с 24с512.

Можно узнать. Cмотрите раздел ACKNOWLEDGE POLLING в мануале - щупается наличие реакции на START+DEVICE ADDRESS.
Практически все очень просто - запрашиваете запись следующего блока без всяких задержек и повторяете запросы пока на запрос не получите ACK. В любом случае с предварительной задержкой или без, получение ACK на START означает завершение цикла записи блока.

Так японский городовой, - я ж этого не делаю. Я просто делаю задержку такую же как на байт. 10мс.

Похоже в этом и ошибка кроется. А то что при чтении сбои возникают, так похоже просто некоторые ячейки записываются неустойчиво. Сейчас попробовал запись побайтно, а чтение блоками. Вроде полностью работает.

А если нет ответа, то повторяется старт условие без всяких яких? Или надо запрос стопом завершить?

Да, поскольку девайс в этот момент банально отключен от линии, то наличие/отсутствие стопа ему безразлично.

Какой-то брэд у меня. У меня всегда 24с отвечает. Ошибки вроде нет. Буду разбираться завтра. Пока меня устроит запись побайтная. Время некритично, но неприятно. Так как массивы по 60к. Затягивается процесс. Но мне пока достаточно работу предъявить. А там только чтение.

Скажи а страницу я обязан полностью записывать (там 128 байт). Насколько я помню там просто копируется вся страница в озу потом модифицируется и записывается. То есть по моим понятиям я могу сколько угодно записать. Работать должна. Или я не прав? Почему может 24с всегда отвечать?

После записи страницы надо ждать 5ms для чипов с маркировкой "A", и 10ms без "A"..




Возможно сбои связаны с тем, что у вас не обрабатывается либо неправильно обрабатывается какое-то из состояний шины.
Например, при блочном чтении, очень важно устанавливать NACK перед приемом последнего байта данных.



На меге640 лучше не скупиться на буфер и сделать его размером байт в 200 (про запас) чтобы можно было размещать страницы целиком.

А драматическое уменьшение ресурса не смущает?
Про бит готовности - это у меня терминология выпала под вечер ACK, конечно же.

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

Нет, любым кусочком. Я почти всегда пишу не страницами а по 32 байта, дабы не разбираться, какой чип стоит или в некоторых случаях кусками равными размеру записи а не страницы.



Уже писал - я не разбираюсь с буковками на чипе и не жду. Банально повторяется посылка START до получения ACK.
Какой-либо задержки не используется в принципе.
Прокладок-задержек между циклами опроса, как в Вашем примере, тоже, поскольку работаю по прерываниям и там автомат самостоятельно непрерывно молотит.
Чипы производители оборудования точно ставят разные и разных производителей.