Atmega8+24C256, Проблемы со стабильным чтением Опции

[OLEG_BOS]

Уважаемые знатоки прошу Вашей помощи. Бьюсь уже три дня и две ночи. Перечитал кучу литературы и Data Sheets. Но так и немогу добится стабильной работы. Поэтому и решил обратится к Вам за помощью поскольку впервые начинаю работать с I2C.

Описание схемы: Связка Atmega8+M24LC256. Микросхема ЕЕPROM подключена к выводам TWI Atmega8.
Описание задачи: Читать содержимое ЕЕPROM с адреса 0х0000 по 0х0400.
Описание программы: Используется программа Software I2C (так как с Hardware TWI были еще большие проблеммы) написанная в IAR, с использванием части кода взятого на форуме - БОЛЬШОЕ спасибо Мах и Андрей http://nav2.livejournal.com/130205.html.
Описание проблеммы: Наблюдается крайне неустойчивое чтение M24LC256 (на тактовой частоте 70 КГц). Поначалу еще более менее наблюдается стабильное чтение порядка 10 байт. А далее ....Просто тихий Ужас Микросхема просто отказывается читатся Было проведенно множественное число экспериментов как с реальным железом, так и с использованием симулятора Proteus (в котором были полученны временные параметры сигналов SDA и SCL а также и всего протокола обмена (вроде все там в норме). Непонятно почему, но на каком то этапе чтения ЕЕPROM видает 0xFF (хотя в зашитом файле этого числа там просто нет !!!) . Такое ощущение будто она просто переходит в пасивное состояние и шиной просто не управляет. Повторные последующие рестарты просто ухудшают ситуацию - микросхема не выдает даже первых стабильных 10 Байт.

Вопрос: Неужели все так печально с I2C ? Может есть какой то "секрет" по работе с M24LC256 который не описан (или случайно пропущен мною) в Data Sheet ??? Читается ли у кого-либо M24LC256 с первого раза (без рестартов) стабильно как часы ?

Прошу Вашей помощи !!! Заранее багодарен.

[OLEG_BOS]

Тема закрыта. Наконец удалось раздобыть двухканальный цыфровой осцылограф. Недоспав еще одну ночь, наконец разобрался в сути проблемы. Подрихтовав маленечко пограмму - Все заработало. Микросхема наконец начала читатся стабильно. Основной проблемой было то, что упор я делал на Proteus, надеясь что терминал I2C в нем работает правильно. Но на самом деле не все там "красиво", но все таки Proteus здорово помог мне в настройке временных параметров.
Все удалось проверить подключив Atmega8 к COM порту компа.

Все ответившим спасибо за поддержку.

defunct - спасибо за код Hardware TWI, но к сожалению задача требует контроля прихода 8-го такта сигнала SCL перед ACK(NOT ACK). Поэтому все же пришлось использовать Software TWI.

[defunct]

defunct - спасибо за код Hardware TWI, но к сожалению задача требует контроля прихода 8-го такта сигнала SCL перед ACK(NOT ACK). Поэтому все же пришлось использовать Software TWI.

?!

Зачем контроллировать "приход 8-го такта сигнала SCL"?Он же контроллером генерируется... И start/stop condition тоже...

[OLEG_BOS]

defunct - спасибо за код Hardware TWI, но к сожалению задача требует контроля прихода 8-го такта сигнала SCL перед ACK(NOT ACK). Поэтому все же пришлось использовать Software TWI.

?!

Зачем контроллировать "приход 8-го такта сигнала SCL"?Он же контроллером генерируется... И start/stop condition тоже...

Но я же говорю: так требует поставленная задача....Даю намек : скажем перевод последовательных данных с шины I2C в их паральный вид с помощью сдвигового регистра.

[defunct]

Но я же говорю: так требует поставленная задача....Даю намек : скажем перевод последовательных данных с шины I2C в их паральный вид с помощью сдвигового регистра.

Все равно непонятно зачем это может понадобиться.
Особливо учитывая сабж: "Atmega8+24C256".
Пытаетесь убить двух зайцев вычитываете данные из eeprom и сразу запихиваете не только в контроллер но и еще куда-то?

Зы: прочитанные контроллером данные, можно отправить по месту назначения не применяя никаких хакерских методов. ;>

Зыы: на время работы с нестандартным устройством, подключенным к I2C шине, TWI можно отключать. И работать без старт/стоп состояний по требуемому вам протоколу. Драйвер проще получится.

[OLEG_BOS]

Но я же говорю: так требует поставленная задача....Даю намек : скажем перевод последовательных данных с шины I2C в их паральный вид с помощью сдвигового регистра.

Все равно непонятно зачем это может понадобиться.
Особливо учитывая сабж: "Atmega8+24C256".
Пытаетесь убить двух зайцев вычитываете данные из eeprom и сразу запихиваете не только в контроллер но и еще куда-то?

Зы: прочитанные контроллером данные, можно отправить по месту назначения не применяя никаких хакерских методов. ;>

Зыы: на время работы с нестандартным устройством, подключенным к I2C шине, TWI можно отключать. И работать без старт/стоп состояний по требуемому вам протоколу. Драйвер проще получится.

1. Удивительно, когда непонятны элементарные вещи Даю второй намек Уважаемый defunct, а Вы представте себе что к выходам сдвигового регистра подключена матрица R-2R .... Надеюсь теперь Вам стало понятно для чего это ?

2. Нет в данном случае я не пытаюсь убивать двух зайцев, потому что контроллеру данные из 24C256 нужны как "зайцу стоп сигнал". Его задача очень простая - адресовать данные на шину I2C и в нужный момент выставлять их на регистр.

3. Этот метод я бы назвал не "хакерским" а "KnowHow " в условиях когда к контроллеру и так подключенно много другой переферии (выводы других портов заняты), в память FLASH и так еле помещается управляющая программа, буфер RAM и без этого занят другими данными....И драйвер не совсем уж сложным получается, каких то 1-1,5 Кб.

[defunct]

1. Удивительно, когда непонятны элементарные вещи Даю второй намек Уважаемый defunct, а Вы представте себе что к выходам сдвигового регистра подключена матрица R-2R .... Надеюсь теперь Вам стало понятно для чего это ?

Мы что играем в шараду? Было бы гораздо лучше если бы вместо намеков, вы бы сразу точно описали задачу и ресурсы отведенные под нее.

2. Нет в данном случае я не пытаюсь убивать двух зайцев, потому что контроллеру данные из 24C256 нужны как "зайцу стоп сигнал". Его задача очень простая - адресовать данные на шину I2C и в нужный момент выставлять их на регистр.

Задача может быть изменена:
Контроллер буферизировано читает данные из AT24 быстро, используя TWI шину с режиме прерываний. В свою очередь это снизит загрузку проца, и он сможет заниматься во время чтения данных чем-то другим. По таймеру в realtime выводить на ЦАП данные по отдельным двум линиям. В таком виде задача будет решена классически без всяких возможных подводных камней.

3. Этот метод я бы назвал не "хакерским" а "KnowHow " в условиях когда к контроллеру и так подключенно много другой переферии (выводы других портов заняты), в память FLASH и так еле помещается управляющая программа, буфер RAM и без этого занят другими данными....И драйвер не совсем уж сложным получается, каких то 1-1,5 Кб.

Дело конечно ваше, но если сделать как было сказано выше, то драйвер работы с i2c и вывода данных в dac займет около 200 байт Flash и около ~20 байт RAM с учетом аппартного I2C и режима прерываний.

[OLEG_BOS]

1. Удивительно, когда непонятны элементарные вещи Даю второй намек Уважаемый defunct, а Вы представте себе что к выходам сдвигового регистра подключена матрица R-2R .... Надеюсь теперь Вам стало понятно для чего это ?

Мы что играем в шараду? Было бы гораздо лучше если бы вместо намеков, вы бы сразу точно описали задачу и ресурсы отведенные под нее.

2. Нет в данном случае я не пытаюсь убивать двух зайцев, потому что контроллеру данные из 24C256 нужны как "зайцу стоп сигнал". Его задача очень простая - адресовать данные на шину I2C и в нужный момент выставлять их на регистр.

Задача может быть изменена:
Контроллер буферизировано читает данные из AT24 быстро, используя TWI шину с режиме прерываний. В свою очередь это снизит загрузку проца, и он сможет заниматься во время чтения данных чем-то другим. По таймеру в realtime выводить на ЦАП данные по отдельным двум линиям. В таком виде задача будет решена классически без всяких возможных подводных камней.

3. Этот метод я бы назвал не "хакерским" а "KnowHow " в условиях когда к контроллеру и так подключенно много другой переферии (выводы других портов заняты), в память FLASH и так еле помещается управляющая программа, буфер RAM и без этого занят другими данными....И драйвер не совсем уж сложным получается, каких то 1-1,5 Кб.

Дело конечно ваше, но если сделать как было сказано выше, то драйвер работы с i2c и вывода данных в dac займет около 200 байт Flash и около ~20 байт RAM с учетом аппартного I2C и режима прерываний.

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