Argon (23.01.2022 10:27, просмотров: 12570)-
- наиболее вероятный источник сбоя выключение питания во время записи. Я использую две копии с СRC. Запись копий идет последовательно (первая копия, потом вторая), от младшего адреса, СRC пишется в последнюю очередь, при загрузке востанавливаю копию с поврежденным ЦРЦ, если оба ЦРЦ целы, актуальной является первая копия. При регулярном сохранении состояния алгоритм немного другой... - IBAH(24.01.2022 13:35)
- 1. Почему троирование, если работает дублирование (crc первого
набора не совпало, второго совпало - выбор одного из двух
однозначен, мы же верим в crc?) VLLV(108 знак., 23.01.2022 19:32)
- Ликбез по использованию 3-х копий настроек: il-2(943 знак., 24.01.2022 06:13)
- У меня памяти больше, время на сохранение есть, и CRC считаю, в
результате восстановление памяти выглядит так: VLLV(250 знак., 24.01.2022 09:43)
- Похоже на дуэль дАртаньяна с мушкетёрами m9rs(43 знак., 24.01.2022 16:49)
- Надо бы логи
дуэлейсбоев вести, но не сделал. Но сбои фигня, важно то, про что написал LordN: "2. запись не должна начинаться после пропажи питания со входа бп.", иначе запишется правильная контрольная сумма для неправильных данных. У всех те же грабли были :) - VLLV(24.01.2022 18:56)- Думаю, что LordN говорил про одну копию настроек. У себя использую две копии настроек с CRC без контроля питания. Три копии вообще непонятно зачем нужны. - Ale3000(25.01.2022 04:41)
- А как это возможно "правильная контрольная сумма для неправильных данных"? По-моему если питание падает, то уже все - до записи CRC дело может даже не дойти. Или имеете ввиду, что если дело таки дошло, то CRC вычислилось неверно? Я на этот случай заранее CRC вычисляю, для уже готового массива записываемых данных. Argon(66 знак., 24.01.2022 19:55)
- Надо бы логи
- Не понятно что делает функция RestoreAllSetup(...) Если бы она
вызывалась только (0) и (1), я бы предположил что это чтение блока
1 и 2 с проверкой CRC и тогда функция RestoreSetupUntilSuccessful
содержжит дефект. Но я вижу еще (2) и моей догадливости тут не
хватает. - AlexBi(24.01.2022 12:18)
- поясняю VLLV(818 знак., 24.01.2022 15:36)
- А запись настроек при их изменении как сделан? В принципе должно
работать, наверное - AlexBi(24.01.2022 16:09)
- Три уровня записи - во все, в два, в один. Критерии выделены. VLLV(492 знак., 24.01.2022 18:49)
- А запись настроек при их изменении как сделан? В принципе должно
работать, наверное - AlexBi(24.01.2022 16:09)
- поясняю VLLV(818 знак., 24.01.2022 15:36)
- Выглядит не очень. В основном из-за наркоманских отступов и переносов. - SciFi(24.01.2022 09:45)
- Похоже на дуэль дАртаньяна с мушкетёрами m9rs(43 знак., 24.01.2022 16:49)
- У меня памяти больше, время на сохранение есть, и CRC считаю, в
результате восстановление памяти выглядит так: VLLV(250 знак., 24.01.2022 09:43)
- 1)+1 symbions(4 знак., 23.01.2022 20:15)
- Ликбез по использованию 3-х копий настроек: il-2(943 знак., 24.01.2022 06:13)
- "-Доктор, как уберечься от триппера? -Слой бинта, слой ваты, еще
слой бинта и слой ваты. А главное - никаких половых сношений!"(с)
:)) - MBedder(23.01.2022 18:50)
- ага.... - Лaгyнoв(23.01.2022 20:13)
- По моему опыту, необходимость троирования зависит от применяемой
EEPROM. Вероятности сбоя разная. Например, в Хмегах EEPROM
оказалась не особо надежной, поэтому в проектах на них у меня по
три копии настроек, которые я побайтно прогоняю через мажоритарный
элемент при запуске. В обычных AVR и без этого проблем нет, а AVR-D
при использовании IAR ничто не спасет. AlexG(144 знак., 23.01.2022 17:24)
- Не факт... Не факт... Для АВР есть хороший способ избежать проблем
с ЕЕПРОМ, известный с первобытных времён: парковать ЕЕАР в "0",
например, после любого использования. И всё... У меня в Мегах(ещо
классичских, 128, 48) лежат калибровочные таблицы почти во всю
память. Ну ни разу не приезжало поделие с диагнозом "чота не то
меряет". С 2003 года. - mse homjak(23.01.2022 18:48)
- Я знаю про нулевой адрес и BOD. Почти всегда использовал встроенные
в компилятор функции работы с EEPROM и с обычными AVR они не
подводили (кроме как в бета-версии среды разработки). Какие-то меры
там уже приняты, подозреваю, что неиспользуемый нулевой адрес и
парковка. AlexG(787 знак., 23.01.2022 19:39)
- ох, как мне это знакомо! компилятор и линкер, все поголовно косячные, один я в белом и правильный )))) - Aleksey_75(23.01.2022 19:43)
- Дык... А если, как встарь? "Настоящий Программист может написать на
любом языке программу на
ФортранеАСМ"(С) mse homjak(278 знак., 23.01.2022 19:43)
- +1 золотое правило, не пользуем нулевой адрес и паркуем указатель не него! чтот AlexG жуткие картинки про еепром нарисовал, если так то вообще зачем такая память нужна ??? - Aleksey_75(23.01.2022 18:53)
- Я знаю про нулевой адрес и BOD. Почти всегда использовал встроенные
в компилятор функции работы с EEPROM и с обычными AVR они не
подводили (кроме как в бета-версии среды разработки). Какие-то меры
там уже приняты, подозреваю, что неиспользуемый нулевой адрес и
парковка. AlexG(787 знак., 23.01.2022 19:39)
- Не факт... Не факт... Для АВР есть хороший способ избежать проблем
с ЕЕПРОМ, известный с первобытных времён: парковать ЕЕАР в "0",
например, после любого использования. И всё... У меня в Мегах(ещо
классичских, 128, 48) лежат калибровочные таблицы почти во всю
память. Ну ни разу не приезжало поделие с диагнозом "чота не то
меряет". С 2003 года. - mse homjak(23.01.2022 18:48)
- в особо ответственных случаях применяю мажоритарную запись и
чтение/восстановление (соответствующие процедурки для AVR на
ассемблере (там пару-тройку десятков строк кода всего :)) - могу
выложить. Мажоритарное чтение (два из трёх, "голосованием") - эт
понято. Там у меня ещё чтение -проверка-модификация, - т.е. если в
результате чтения найдена сбойная ячейка, то она восстанавливается.
Мегаполезная шняга :) Adept(1293 знак., 23.01.2022 16:17)
- О! Насчет "парковки" спасибо, полезно! - Argon(23.01.2022 16:49)
- всем спасибо, пожалуй остановлюсь на варианте с дублированием - Argon(23.01.2022 12:47)
- Есть, в прошлом веке еще придумано все, коды с восстановлением
ошибок, типа Рида - Соломона и БЧХ. Даже исходники в сети находил
БЧХ 21 - 31. Восстановление 2 х ошибочных бит в любом из 31. Если
надо, выложу. - Visitor(23.01.2022 11:48)
- Выкладывайте, интересно. - Бoмж(23.01.2022 12:11)
- Если защищаемых данных мало, то иногда использую 4 копии с побитовой инверсией и без CRC (а-ля MiFare для адреса) - при известном порядке записи обеспечивается гарантированное восстановление - либо до "недописанного", либо до предыдущего валидного. В других случаях использую CRC, а дополнительная временая копия появляется собственно на время транзакции вместе с идентификатором обслуживаемого объекта и флагом (часто достаточно ненулевого значения указателя). Ну и если Vit(450 знак., 23.01.2022 11:26, ссылка)
- два простых правила позволяют мне не париться с этой темой. LordN(212 знак., 23.01.2022 11:13)
- т.к. stm32 не имеет еепрома, пишу в флешь, использую 2 страницы, друг за другом, каждая запись имеет номер и срс. даже если отключится питалово во время записи всегда есть последняя валидная настройка. при наличии еепром имелось две записи, также с номером и срс - Aleksey_75(23.01.2022 11:09)
- Я обязательно дублирую настройки и храню их в разных страницах.
Проверяю по CRC и загружаю исправную. Надо в сохраняемой структуре
еще по хорошему хранить номер сохранения, чтобы при совсем
гипотетическом случае двух целых но разных CRC взять последнюю
актуальную. - michas(23.01.2022 10:46)
- спасибо! дублирование - тоже вариант, но пока не выглядит более простым - Argon(23.01.2022 10:58)
- Придумываем несуществующие проблемы, а потом решения для них? - SciFi(23.01.2022 10:36)
- Ну да, примерно так. Однако, если так рассуждать, то и CRC не надо? - Argon(23.01.2022 10:38)
- Есть такая штука, как отключение питания во время записи. Даже
вероятность прикинуть несложно. Вот для этого контрольная сумма
нужна. - SciFi(23.01.2022 10:41)
- Ну вот! И что делать девайсу при несовпадении CRC? Задача-то собсна
в том, чтобы девайс по возможности сам решил свои проблемы. - Argon(23.01.2022 10:44)
- Не проще откатиться на default? - ILYAUL(23.01.2022 10:52)
- Проще, но по-моему, неправильнее. Это может привести к
необходимости проводить настройку/калибровку. - Argon(23.01.2022 10:54)
- Я под default имел ввиду настройки которые сохранил пользователь ,
когда проводил настройки при первом вкл. - ILYAUL(23.01.2022 11:05)
- Да это то же самое. В процессе работы ведь текущие настройки могут
поменяться. Следовательно появляется расхождение с первично
прописанными default, что говорит о том, что эти default уже не
являются решением проблемы. - Argon(23.01.2022 11:24)
- Однако default не затирают калибровки, я использую термин последние валидные настройки. - General(23.01.2022 11:32)
- Да это то же самое. В процессе работы ведь текущие настройки могут
поменяться. Следовательно появляется расхождение с первично
прописанными default, что говорит о том, что эти default уже не
являются решением проблемы. - Argon(23.01.2022 11:24)
- Я под default имел ввиду настройки которые сохранил пользователь ,
когда проводил настройки при первом вкл. - ILYAUL(23.01.2022 11:05)
- Проще, но по-моему, неправильнее. Это может привести к
необходимости проводить настройку/калибровку. - Argon(23.01.2022 10:54)
- Не проще откатиться на default? - ILYAUL(23.01.2022 10:52)
- Ну вот! И что делать девайсу при несовпадении CRC? Задача-то собсна
в том, чтобы девайс по возможности сам решил свои проблемы. - Argon(23.01.2022 10:44)
- Есть такая штука, как отключение питания во время записи. Даже
вероятность прикинуть несложно. Вот для этого контрольная сумма
нужна. - SciFi(23.01.2022 10:41)
- Ну да, примерно так. Однако, если так рассуждать, то и CRC не надо? - Argon(23.01.2022 10:38)