может быть и везет. А может что-то не так с тестом.

Атача нет..

А!!! Понятно... С мегами48 не работал... А в других мегах по 8,5 мСек.. Вот и усомнился

1. Да, было бы не плохо, что бы еще кто-нибудь помучал (-ся) с проблемой убийства ЕЕПРОМ.
2. Что-то не получилось подключить файлик. дублитрую

eeprom unsigned char sacrifice;
поменяйте:
volatile eeprom unsigned char sacrifice;
мало ли какие причуды CV оптимизатора, без volatile он вправе брать значение из регистра.

Да вроде бы все путем. Вот ассемблерный код:



а вызов __EEPROMWRB выглядит так:


Да и просмотр с помощью программатора ЕЕПРОМ-овского байта (по адресу 00) говорит о том, что запись идет.

К записи претензий нет. Я высказал только недоверие по отношению к чтению.

sacrifice = n;
return (sacrifice == n); <--- вот этот код может быть выброшен оптимизатором.

и функция будет возвращать всегда TRUE

Ага. Спасибо! Я на это дело тоже обратил внимание. В самом начале, в самой первой версии, я вообще чтение (и сравнение) и запись в ЕЕПРОМ разнес в разные функции (разные вызовы). Тоже боялся, что компайлер заоптимизирует. Но когда посмотрел, что он дает на выходе, то решил сделать так, как это сейчас есть.

А по проге, в целом, -- не проблема! Я для того и выложил ее код, чтобы было от чего отталкиваться. Цель -- хотелось бы оценить границы хотя бы примерно. А то живем и знать не знаем, где "земля заканчивается и начинается небо".

Интересно, однако



Получается, что если писать одно и то же то даже и никак не узнаешь, что запись реально не происходит! Вот так компилятор заботится об EEPROM'e.
Я вижу, что в сишной программе пишутся разные значения! Но является ли ЗАПИСЬЮ в полном смысле операция записи нулевого бита поверх нулевого и так же единицы поверх единицы? получается, что за цикл 00..255 младший бит перезапишется 255 раз, а старший - всего 2! Или байт портится целиком?

вот кусок отассемблированного кода по чтению:

оптимизации нет, на что указывает вызов __EEPROMRDB.




Я записываю только младший байт.

При чём байт? Я говорил про бит. Когда испортилось, что Вы читаете? КАК портится ячейка памяти?

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

Ведь, прежде чем записать новое значение в ячейку памяти (байт), автомат записи сначала ее стирает (0хFF). Под действие электрического импульса стирания попадают все биты, вне зависимости от их состояния. А вот под воздействие записи попадают только нулевые биты. Если это так, то тогда теоретически получается, что младший бит "изнашивается" быстрее, чем старший. А как оно практически получается -- х.з. Вот, типа мы все тут пытаемся установить.

Попробуйте переделать прогу, может у Вас быстрее получится убить мегу.

Если он сначала стирает, то вообще нужно писать нули постоянно. Естественно, обойдя чтение-сравнение.
Например писать 0-1-0-1... Никто почему-то не пишет, что происходит с битами, а может быть это и есть источник разницы в тестах?


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

Я всё же решился Пожертвовать ячейкой EEPROM с адресом 0 в одном из своих девайсов и решил провести тест до её убийства.

Тест запустил в 18-40 по московскому времени.. Темп записи примерно 7000 записей в минуту или 420000 записей в час. После каждых 256-ти записей (примерно раз в 2 сек) у меня моргает светодиод. Посмотрим когда он остановится. Если верить даташиту он должен был прекратить моргать в 18-54.. Сейчас 18-54.. Ещё пока моргает

P.S. Прога написана на АСМ-е.. Так что никаких глюков оптимизатора


Логично. Полностью с Вами согласен

Сообщение отредактировал Боинг749 - Aug 29 2008, 15:01

Насчет более быстрого изнашивания младшего бита - defunct в 25 посте привел результаты своего теста, так там отличаются записанный и прочитанный байт вовсе не младшим разрядом. Например 7F <-> 77.

Прервал тест, чтобы доработать прогу тестирования в плане сохранения ожидавшегося значения. Т.е. я пишу в EEPROM по адресу 0 содержимое счётчика R25, а затем считываю содержимое ячейки 0 в R24. Так вот, раньше у меня не было предусмотрено сохранение R25 в случае обнаружения ошибки записи. Теперь же в случае ошибки я записываю R25, на котором остановился тест, в 7-ю ячейку EEPROM.

Расскажу вкратце как я тестирую. У меня есть малый цикл, когда R25 меняется от0 до 255. И большой когда инкрементируется 16-ти разрядный счётчик больших циклов.
После того, как R25 "пробежит" от о до 255 я инкрементирую счётчик больших циклов. Этот 3 копии счётчика больших циклов храню в EEPROM.

Раньше R25, на котором "споткнулся" тест, я не сохранял. Но после слов одного из участников, что при таком тесте более вероятно что первым "накроется медным тазом" самый младший бит, решил проверить эту теорию. Для чего переделал прогу и ПЕРЕзапустил тест.

Да, фусе-бит EESAVE, чтобы содержимое EEPROM не терялось при перепрошивке программы, у меня уже был запрограммирован ранее.

Далее, тест рестартует только после выключения/включения питания. Для чего в программе анализирую бит PORF.


И так.. Глянул сейчас на счётчик больших циклов. Он равен $096A. Значит было произведено $096A х 256 = 616000 записей... И полёт пока нормальный.. Светодиод по-прежнему мигает каждые 2 сек.

(написал это где-то час назад... Светодиод пока мигает Ну не хочет никак убивацц ячейка )