Помогите советом кто как записывает EEPROM с протоколом . признак начала пакета кол байт контрольная сумма.
я переделал протокол wake под запись EEPROM но там много лишнего.

А зачем при записи в EEPOM нужен еще какой-то свой протокол? EEPOM обычно имеет свой физический интерфейс, который и определяет временные диаграммы чтения/записи. Может вы на самом деле хотите спросить не о протоколе связи, а о способе хранения произвольных записей в EEPROM? Некоем подобии файловой системы? Тогда встречный вопрос: про связанные списки знаете?

нет не знаю.Где про них найти

В гугле .
1-я же ссылка -
http://ru.wikipedia.org/wiki/%D0%A1%D0%B2%...%81%D0%BE%D0%BA

Реализовывать можно как угодно и на чем угодео.
Полно примеров и на C и на др. языках.

Т.е. вы подтверждаете мою догадку о том, что вам на самом деле требуется файловая система для EEPROM?

Да мне требуется файловая система для EEPROM, или её подобие.Мне надо записывать массив данных одной длинны,и при чтении знать верны ли данные.Спасибо за ссылки
я нашел на си.надо осмыслить.

При чтении определить верны ли данные можно 2 способами (в зависимости от конкретного случая), ето проверка контрольной суммы или просто условный оператор на проверку диапазона возможных значений в цикле считывания.
Я как делал ф. обновления прошивки у меня сначало мк прошивку закодированную протоколом РЦ записывает во внешнюю еепром, потом обязательно проверка контрольной суммы, если все ок загрузчик мк сам свою прошивку всю перещивает, 500раз тестировал, при ошибках передачи данных прошивки контрольная сумма не совпадает и мк себя не перешивает... поетому я так понял вам нужно реализовать просто проверку контрольной суммы и все, нечего там городить файловые системы и т.п., хотя зависит от конкретной задачи

самое главное при записи в еепром отключать прерывания, так как будут глюкы 100% при записи данных

Обоснуйте, пожалуйста. Каков механизм их возникновения при включенных прерываниях?

елементарно ватсон... запись в еепром идет долго, т.е. нужна задержка в программе при записи что бы записалось (цыклом вайл ждем пока не закончиться запись, и только тогда работаем дальше), если в ето (пока цыкв вайл ждет пока закончиться запись) время произойдет абсолютно любое прерывание, то запись может (а может и нет) заглючит и результат записи может быть любим, с такой фигней мне приборов уже 100 возвращали, и вообще голову ломал че слетают все время данные с еепрома... бод настроил и т.п... отключил прерывание при работы с еепром, как результат полтора года 800 устройств до сих пор работают замечательно

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

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

Это не описание механизма.


Так программы надо писать так, чтобы "что угодно" не случалось.

ну вот отключил прерывание и что угодно случится точно не сможет
темболия если большой проект, то все предусмотреть ооочень тяжело, включаются/выключаются прерывания всего одной командой, поетому для меня в хорошем стиле программирования должны отключатся прерывания на момент записи в еепром

aaarrr как по другому лучше сделать? сделать глобальный флаг и при записи устанавливать в 1 а при окончании в 0 и при каждой записи проверять етот флаг? особенно если писать масивы в еепром, масив может быть недописан и по прерыванию пойдет команда записать в етот масив другие значения, при возврате с прерывания будет дальше запись идти, в результате фиг знает что будет в еепром, поетому можно и флаг делать глобальный, но я сделал уже по "настоящему", отключаю прерывания и спокоен... так как коректность данных в еепром была очень важна, и играться на угад как оно получиться нельзя, как месяц или как год поработает устройство

Вероятно, Вам не попадались задачи, где приоритет записи в еепром чуть пониже плинтуса.
Прерывания и надёжность записи (в еепром), имхо, никак не пересекаются.

Оцениваете потребную среднюю скорость записи; если укладываетесь в спецификацию еепром, то организуете, н-р, кольцевой буфер достаточной длины, из которого пишете по мере возникновений прерывания окончания записи в еепром; если не укладываетесь, выбираете более приличную случаю энергонезависимую память.

контрольная сумма и есть этот флаг.Правильная контрольная сумма при чтении правильные данные.а если данные не правильные поможет кольцевой счётчик адреса ЕЕПром если данные не верны делаешь откат и читаешь предыдущие данные.

Нда...
отключать прерывания нужно ТОЛЬКО на время копирования данных во временный буфер
который используется для записи в EEPROM,
все остальное ошибки программиста...

ошибок никогда не бывает, прогто любая программа работает так, как ее написал ррограммист, а не так как она должна работать?
В любое время в любов приреванни может быть команда записи в еепром, в таком случае, или глобальную переменную мутите ли отключайте прерыванич??? я еще имел глюк с лсмд при прерываниях, кому интересно роскажу, [CENSORED] я на своем опыте работы имею след. полезный совет:

Если вы работаете с еепром и нет критического требования на реакцию мк на все прервания - отключайте еепром при записи, иначе в любой программе найдеться не предусмотернный глюк где 1 пишетться 2 раза в одно и то время по приреванич??? глюк роз в 3-4 месяца возникап, вот мне перед клиентами удоно было тол???


+ еще, при работе за ЖКИ где 4 битная ШД, так вот..... при записи 4 бит если возникает прерывание и там нуно опять дынные возобновить, так пишем еще 8 бит.... потом возвращаемся с прерывания... и дописываеи еще 4 бит.. кароче глюки слош и рядом, ну вот если вы такие умные, просвятите как избавится ог глюков работы дисплеся при 2 командал

lcd_gotoxy(0, 1);
strchis("А");

ели запустить данній код в прерівание по входу, и дать на вхоод несколько десятком кГц??? вот, значит при работе с дисплеем тоже прерівания отклювать? ато при ежедневном использовании раз в 3-4 месяца клиент находит как заглючить устроство?

так вам токо на угад, написал и досвидание??? кому перрівания не критьичні оключайте... ато как исправить глюк просвятите

lcd_gotoxy(0, 1);
strchis("А");

ПС, писать свои функции и делать на асембллерере 10000% не позволяет заказчит, поетому вот такая задача... как исправить глюк в етих 2 строках без отключения прерываний?

ПС. еемпром обновляю с частотой окколо 1кгц в 1с, статистиу тамм прибор храмин, уж очень точную, и часто туда пишет, и преріваний тьма

вот какк просвятите как избавиться от глюков бисплея без откл преріванич поверю что умныу


Мнение о пользователях скрыто по поступившей жалобе. Автор сообщения получил предупреждение и статус read only на неделю.
Модератор.

Сначала объясните, зачем может понадобиться писать таким образом? Конечно, можно писать программы абы как и "обезглючивать" их выключением оптимизации и прерываний, вместо поиска реальной проблемы, но профессиональным такой подход не назовешь.

Если для корректной записи в EEPROM приходится выключать прерывания, значит программа на 100% написана неправильно.

[CENSORED]
нужно все го лишь скопировать свои данные во временную переменную
которая для записи в EEEPROM

Абсолютно согласен!

Уважаtмый модератор, слово ",баран" не имеет национальности...
я как бы понимаю Вашу попытку соблюсти политкорректность...
но ИМХО, это не тот случай...

Уважаемый Integral, этот форум на русском языке. Будьте добры соблюдать нормы языка на форуме.
IMHO читать неприятно и тяжело.

'aaarrr' в посте №16 все объяснил, я позволю добавить, что процессор должен гарантированно успеть обработать код прерывания, до наступления следующего прерывания. (нп. обработка прерывания INT0 должна быть законченна до наступления следующего INT0)
Из этого следует, что или код прерывания должен быть очень коротким или проц. очень быстрым.
А вы явно впихнули прожорливые команды в прерывание.

И это все я описал для одного прерывания, а если у вас в это время прерывание с более высоким приоритетом будет "мурку тянуть"
(Если кто не знает что такое мурку тянуть)
то и получите "не работоспособную" прогу .

1. Сюда ходят люди, а не "бараны".
2. Публичное обсуждение действий модератора.
В совокупности - статус на неделю read only.

Я начал тему о другом запись с протоколом в память не обязательно во внутреннию ЕЕПРОМ .это пример Я так записываю в любую Энергонезависимую память.Мы ушли в другую сторону.Записывать в прерывании или нет зависит от самой программы.Если в основном цикле программы требуется одно прерывание которое не влияет на работу программы в данный момент,почему я не могу его выключить перед записью в ЕЕПРОМ или вы включаете все прерывания которые потребуются в программе сразу после сброса.

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


Если программу написать столь же грамотно, как этот текст, то непременно заглючит. Но в AVR никаких предпосылок к этому нет.


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

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

не получается у нас вернутся к основной теме.Значит все делают так, Читают байт памяти и если он не 0xff запись достоверна.

а если в ЕЕПРОМ нужно сохранить значение 0xFF ?

А если он 0xAA или 0x55 а Вы писали 0x02 / Проще вычесть прочитаное из записываемого и если не ноль то запись не верна

А Вы опишите задачу, а то так можно гадать бесконечно. Зачем Вам вообще нужен такой контроль содержимого ЕЕПРОМ?

В любом моём приборе требуется сохранение настроек пользователя, имеем блок данных которые требуется сохранить.В одних приборах используется внутренняя ЕЕПРОМ в других внешняя FROM.Но каждое сохранение записывается с протоколом.Сейчас я беру за основу
протокол для UART там байт начала байт команды кол байт блок данных контрольная сумма.Раз протокол для UART то там много дополнительного.Вот я и спрашивал кто как делает в этих случаях.

Настройки записываются в одно и то же место или Вы храните некую историю настроек и потому данные могут располагаться по разным адресам ЕЕПРОМ?

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

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

Можно сделать так: структура данных известной длины закрывается CRC . Этот блок данных записывается несколько раз (3, 5) в EEPROM. При чтении используется мажоритарная схема чтения блока данных по критерию целостности CRC (2 из 3, 3 из 5) . Недостатки: увеличение объемов записи-чтения, уменьшение ресурса записи.

Ресурс записи у ЕЕПРОМ составляет, как минимум, 100000 циклов, не думаю, что пользовательские настройки будут меняться часто, так что о ресурсе тут даже и не стоит заботиться. Прикинуть ресурс можно, получив при этом сотни лет, а потом успокоиться по этому поводу навсегда .

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

Да о чём мы говорим ! Это всего лишь EEPROM. Применять к ней протоколы сЕти , это нонсенс. Только "утяжеление" программы. Есть данные , которые пишутся и которые можно считать с EEPROM после записи . Сравнил данные и успокоился. Даже CRC считать и то - деньги на ветер. К тому же совершенно не понятно , ну записалось не то , дальше чё? Надо ещё тупо вычислить , что не прошло - кодовое слоао , команда, данные или "битая" ячейка EEPROM. Не тот случай , что бы страховаться по полной. И надо же было найти самое "быстродейсвующее" в мире устройство , что бы "напрячь" МК по полной

Спасибо!Идеи Уважаемых ILYAUL и GDI очень понравились.Хочу написать функцию где оба способа реализованы.Запись с протоколом
это быстрая запись плюнул в функцию, записал и больше не заморачиваешся полетел дальше.А второй способ неторопливый ,записал
сравнил если ошибка снова записал,можно сделать несколько таких циклов.При этом способе возможен быстрый старт устройства
так как не надо проверять достоверность данных.Эти данные всегда верны.

Вот как раз в еепром, да и любых других вариантах non-volatile ROM, данные могут побиться, пролетело нейтрино и изменило состояние ячейки. Просто явление это редкое и стоит ли так бороться за целостность данных? Лично я никогда такого не делал. Но, на другом форуме, встречал человека который говорил что его приборы настолько надежные, что он хранит 2 копии программы во флеше с контрольной суммой и во время работы ее периодически сверяет и, если что, перезагружается из другой копии. Видно ему это было надо, а для сторонних посетителей форума, его рассуждения выглядели как параноидальный бред. В общем, всё зависит от задачи, путей решения множество - выбирайте и реализуйте.

Уважаемый, шли бы вы со своим хорошим стилем проповедовать на anekdots.ru, а не на форумах electronix.
Запись одного байта в eeprom может длиться до 10 __миллисекунд__ (это примерно 100 символов на 115200), если на это время блокировать все прерывания, все функции устройства отключатся и может потеряться например контрольный пакет данных, важный входной импульс, измерение, или еще чего. Если Вы этого не понимаете, то лучше сюда вообще ничего не постить.

На тему, когда, и зачем, нужно запрещать прерывания, для успешной записи в eeprom - курите даташит. Защитить нужно только timed sequence - две идущих подряд инструкции - установка флага EEMWE, и затем установка флага EEWE в регистре EECR. Всё.



"роскажу" вам дети байку,
я про зайку однояйку,
и про ж.л.глазку
"роскажу" вам дети сказку.

В детцкий сад, пожалуйста, с такими рассказами.

Я делаю всегда так.

Конфигурационная структура, которая лежит в ОЗУ всё время жизни устройства.



В EEPROM либо FRAM, при сохранении конфигурации пишется всегда две копии по одним и тем же адресам. Далее при включении устройства:
1. в конфигурационную структуру та что в ОЗУ загружаются параметры по-умолчанию;
2. читаются обе копии из EEPROM/FRAM, увеличивается счетчик чтений конфигурации на 1 и проверяется CRC каждой записи;
3. если CRC обеих записей неверная, тогда просто сохраняются параметры по-умолчанию в обе EEPROM записи;
4. если CRC хотя бы одной записи верно, и счетчик чтений конфигурации меньше 3 (трех), тогда данные уцелевшей копии перезаписываются в "битую" копию в EEPROM, и происходит чтение с п.2;
5. если после 3-й попытки восстановить битую запись неудалось в поле status выставляется флажек read-only - запрещающий запись конфигурации, и в структуру в ОЗУ копируется уцелевшая копия.
5. если CRC обеих копий верно, тогда данные любой копии (пусть первой) копируются в структуру в ОЗУ;
6. в процессе работы устройство работает с данными из структуры в ОЗУ, по мере необходимости/обновления в процессе работы устройства вся структура из ОЗУ записывается в обе копии EEPROM (если флажек Read-only в поле статус не установлен).

Работает железно. Расширяется элементарно, допустим в новой прошивке нужно хранить еще два параметра U8, структура принимает вид:

В моих устройствах много данных которые необходимо хранить. Использую NVRAM.
Данные разбиты на группы (состояние,события,настройки и.д.).
Размер некоторых групп более 2-х Kб и вероятность выключения питания во время их записи довольно высока.
Если это произошло то необходимо вернуть предыдущие значения (откат).


Я делаю так:
В памяти присутствуют две копии каждой группы (пусть будет 'A' и 'B').
Каждая группа имеет следующюю структуру :

N байт - данные
1 байт - F флаг достоверности(True/False).
4 байта - CRC32 (от начала данных по F включительно)

Основная программа меняет поля данных только блока 'A' и при необходимости вызывает процедуру записи.
Процедура записи:
1. F=true в 'A'
2. подсчет и сохранение CRC в 'A'
3. полное копирование 'A' -> 'B'
4. F=false в 'A'
5. Выход

При включении вызывается процедура проверки.
Процедура проверки:
Если (F и CRC) в 'A' = true то вызывается процедура записи и выход.
Иначе
Если (F и CRC) в 'B' = true то копируем только поле данных из 'B' в 'A' , процедура записи и выход.
Иначе
Сообщаем главной программе что восстановление не удалось (т.е. Гаплык) и выход.

CRC -- это надёжно. Но если CRC защищает большую струкутру, то поле CRC обновляется гораздо чаще, чем любое другое поле структуры. Поэтому я выбрал вариант, когда в структуре из 5 байтов хранится только одно 16-разрядное значение. В контрольный байт пишу флаг верной копии 0x00/0xFF (и ресурс по записи в структуру ограничен ресурсом информационных байтов).

Илья

Mega8A, бытовой градусник наружной температуры с часами, датчик DS18B20 на 10м кабеле, кабель проходит через ферритовое колечко 5вит. В EEPROM коэффициент датчика, месяц градусник поработал и EEPROM слетел, пришлось переписать во флеш. В программе было одно единственное обращение к EEPROM при старте программы. Питание +5В и резервное литиевая батарейка через Шоттки, т.е. меньше 3В никак не должно падать. Батарейка работает исключительно на Mega8A, все остальные части схемы при этом отсекаются диодами, поэтому вряд ли могла возникнуть сильная просадка на батарее, тем более работа без сети - это штатный режим, сеть за месяц выключалась несколько раз и проблем не было. Блок питания - старая трансформаторная зарядка от нокии. Грешу на какие-то электромагнитные помехи и электростатические разряды (может и гроза была где-то рядом может у кого-то из соседей частотник в стиралке барахлит или накрылся и т.д. и т.п.). Замечу, что при сильной статике были случаи, что и флеш полностью стиралась, как будто там программы и не было (желающие могут поиграться электрошокером просто рядом с контроллером).

Скорее всего, это у Вас разводка платы сделана плохо, раз сбоит от ЭМП и память стирается. В этом контексте стирание ЕЕПРОМ не кажется чем то экстраординарным.

Игрался и шокером, и разрядником, и жужжащим контактором... Все работает как часы. Собственно и часы там также работают. Еще добавлю - там кондерный БП так что МК не имеет гальваноразвязки от сети. И все работает. Несколько лет.
ЗЫ. Причем замечено, что DS18B20 при том уровне помех временами подвисал.
ЗЗЫ. И работают тысячи блоков. Правда там AtMega48 или AtTiny26. Но по опыту Mega8a не менее устойчива чем AtMega48. А уж " и флеш полностью стиралась" это вообще что-то из области ...


С вероятностью 90%. Еще 10% - где-то явный ляп со схемой питания процессора.

отключенный BOD, стертые Lock'и, и наличие команды SPM в коде - даст тот же результат и при нормальном питании.

Прошу прощения, если ввел в заблуждение, но флеш стиралась не в бытовом термометре и не в mega8a, а совсем в другой плате управления, контроллер AT90S1200 там был, включенные и BOD и Locks и никаких SPM. Может причиной сбоя была и плохая разводка (правда с электронными наручными часами я тогда тоже распрощался, пришлось выкинуть, наверное в них тоже была неправильная разводка ).

Смешно . Сколько есть способов получить цифру 4 ?

90S1200 BOD не имел класс,так же как и команду SPM(а так-же команду LPM, что более обидно).
Флэш не слетала ни разу,а вот eeprom это да.Пришлось реверсить чужой дивайс и после переноса кода в pin-совместимую tiny2313 с включенным BOD проблемы ушли напрочь на той-же самой плате.