Так как хранить данные в EEPROM у AVR становится все ненадежней, есть идея располагать константы во flash - благо необходимость в их изменении будет ну максимум раз в год, а то и реже. Так вот с чтением из flash проблем нет, а есть ли функции в CodeVision для записи во flash? А то стандартно по страницам не очень удобно.

Приветствую
К сожалению, нет.Только если перекрывать своими макросами.

С Уважением, Владимир

А откуда такая информация?

Я тоже хочу спросить: откуда ?
Сегодня ночью ездил на объект - слетел 16-битный параметр в еепроме в моем приборе. СтоИт мега 48.
БОД итд. В общем - полгода работал, а тут - нате... Других подобных историй не было.

Так может быть причина "слета" не в железе, а в программе? Я тоже уверен, что с EEPROM у AVR дела давно уже наладились. Хотя никто для подстраховки не помешает применять внешнюю с I2C, но это уже не то. Да и та сбойнуть может, кого винить тогда?

В особо критичных случаях стоит применять резервирование данных. Сохраняйте переменную в 3-5 копиях и применяйте медианную фильтрацию при чтении данных. Я так делаю в паре приборов - работает железно.
Ночные выезды до добра не доведут:
бессоница, утка под кроватью, некрасивая медсестра

Хотите, чтобы появилась возможность порчи не только констант, но и программы?

Товарищ по несчастью
К резервному дублированию данных и к хранению во флэш приходишь уже после таких инцидентов


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

есть ощущение что слет eeprom происходит не по вине программы, а из-за железа. По крайней мере для AVR уже давно существует ряд советов по работе с eeprom, таких как - не хранить ничего важного в нулевой ячейке, после чтения eeprom пермещать указатель на "0" и т.д..

Ситуация такая что устройства работали год и все было нормально, а потом резко у 3 из 100 запортился eeprom, как-то вряд ли программа виновата.

Ну почему же? Если какой-либо режим работы программы используется крайне редко (или просто редко), а при тестировании баг не был обнаружен, то вполне может быть.

Бывает еще как.
Ошибка в логике обработки переходного процесса... И допустить такую ошибку ой как легко, т.к. условия ее возникновения порой нельзя даже представить.
Суть даже не в eeprom'е, у меня портился NVRAM контекст (2 копии защищенных CRC16), причем как выяснилось портил я его сам при определенных условиях. А условия вот такие:

1. МК всегда безусловно пишет две копии контекста, в одном и том же порядке (вначале первую копию, потом вторую), по одним и тем же адресам NVRAM'а.
2. Питание проседает до 4.1, затем нарастает до 4.3 и так несколько раз подряд, а потом падает ниже 4.0. (BOD на 4.0).
3. Когда питание падает ниже 4.125V NVRAM уходит в себя (чтобы спасти RTC), тупо отрубается от I2C шины и ему пофиг идет транзакция или не идет в данный момент.

К чему это приводило:
Пусть МК успешно записал первую копию контекста, после чего в процессе записи второй копии напряжение проседает до 4.1V - МК естессно отваливает с ошибкой I2C timeout, пытается достучаться еще несколько раз, а девайса то просто нет на шине. Так портится вторая копия контекста в NVRAM'е.
Через некоторое время (через 1 сек) МК пробует сохранить обновленный контекст - питание к тому времени восстанавливается и NVRAM разлочен. МК начинает писать первую копию, в процессе записи питание падает ниже 4.0V - срабатывает BOD - и писец - обе копии контекста потеряны. Кто виноватъ? HW?
И сколько бы копий ни было вероятность потерять все копии остается, т.е. это БАГ ЛОГИКИ.

Спрашивается кто мешал прочитать контексты перед записью, кто мешал проверить какой из них жив, а какой - нет, и обновить только битую копию. Кто мешал промониторить питание, и даже не соваться к NVRAM'у когда ясно что он вот-вот отключится?

Я вот уверен, что дела могут так же и испортиться...


В таких случаях, все же, лучше на АВР подзабить болта


Бороццо нада за себя. Скажем, если терять все равно неча - затерроризировать всех ответственных - от самодельных мин и рогаток до прелюдного самосожжения, но с некрасивой наедине не останусь


Кто мешал... Их двое:
1. ROM
2. ЛЕНЬ