caxapa.ru :: Немного странная реализация. Конечно, надо видеть, что там дальше делается (и что внутри РестореОллСетап'а), но это все же дублирование (даже если 5 копий сделать), а не троирование.

testerplus (23.07.2010 09:31, просмотров: 166) ответил Vladimir Ljaschko на Исходники приоритетного троирования! Смейтесь! :)

Немного странная реализация. Конечно, надо видеть, что там дальше делается (и что внутри РестореОллСетап'а), но это все же дублирование (даже если 5 копий сделать), а не троирование. Первая функция возвращает первый правильно считанный сетап. Смысл перестраховки в виде троирования не только в том, что при записи одной из копий может случиться сбой (тут и дублирование может спасти), а в том, что случившийся сбой останется незаметным, т.е. контрольная сумма все еще будет сходиться, а данные уже будут битыми. Здесь первая копия может вопсриняться как достоверная, хотя таковой уже не будет. По второй функции уже можно делать анализ, но, опять же, надо еще сравнивать данные между собой.

Ответить

- "контрольная сумма все еще будет сходиться, а данные уже будут битыми" - поясните - koyodza(23.07.2010 14:17)
  - Несовпадение контрольной суммы гарантирует неправильность данных. Но ее совпадение ничего не гарантирует. Если на 7 байт данных держим 1 байт контрольной суммы, то есть в среднем 2^48 вариантов, при которых она совпадет. Во-первых, никто не может testerplus(216 знак., 23.07.2010 14:52 - 14:55)
    - я разве где-то предлагал КС считать XOR`ом? Да и троирование само по себе ненадёжно, если делать его через (_|_) Например, некоторые размещают все три копии в одном секторе - koyodza(23.07.2010 14:57)
      - А я разве Вас обвинял в XOR'ение? Да, бомбоубежище тоже ненадежно, если прятаться за ним, а не в нем. Просто при грамотном подходе троирование даст гарантию сохранности данных, а дублирование - нет. Другое дело, это не везде нужно. testerplus(276 знак., 23.07.2010 15:04)
        
        Как говорил известный вам О. Бендер, полную гарантию может дать только страховой полис. А троирование её не даёт даже близко. - Shura(23.07.2010 15:29)
        
        +500 - koyodza(23.07.2010 16:10)
        
        Вам виднее. - testerplus(23.07.2010 15:58)
- Да, у меня не мажоритарное сравнение, а Vladimir Ljaschko(613 знак., 23.07.2010 09:59)
  - Я просто отметил, что Ваш пример - это не троирование. Там, где допускается частичная потеря данных, вполне нормальный подход. А оптимальность алгоритма (не реализации) обратнопропорциональна требованиям к надежности. Порой хватает и одной копии (с testerplus(37 знак., 23.07.2010 10:28)
  - Вопрос в критерии по которому могут быть использованы данные , при двух последних сбойных используется самый старый блок.Если так то есть время записать и три одинаковых. - PlainUser(23.07.2010 10:25, )
    - Вопрос ещё проще. Если, как тут рассказывали, помехи такие сильные, что повреждают данные при записи во флеш, то кто им мешает повредить данные в ОЗУ, которые потом будут успешно 3 раза переписаны в EEPROM :-) - Shura(23.07.2010 15:55)
      - "Люди думали" (с) Автоматически сохраняется только последний банк. Все банки сохраняются только в редких случаях UI, когда информация прошла проверку целостности. - Vladimir Ljaschko(23.07.2010 16:13)
      - И чем здесь 2 копии лучше 3х? - testerplus(23.07.2010 16:00)
        
        Ничем. А чем здесь EEPROM лучше Flash? :-) - Shura(23.07.2010 16:05)
        
        2 копии хуже 3х, т.к. только по трем можно восстановить данные (или принять решение о их некорректности). А EEPROM лучше флеш по объему (не надо по странице выделять на каждую копию), по безопасности (не нужно писать что-то туда, где есть прорамма) и по testerplus(69 знак., 23.07.2010 16:15)
        
        Вы уж сначала определитесь - что вы считаете некорректными данными и какие возможные причины их появления. Ибо бороться можно только с известными явлениями, но не с вторжением инопланетян. - Shura(23.07.2010 16:47)
        
        Я говорю о данных, считанных из ячейки, затвор транзистора которой имеет недостаточный заряд для однозначной интрепретации его значения. Причины - любые: магнитные поля, скачки питания, наносекундные помехи, -40Ц и т.д. вплоть до радиации. - testerplus(23.07.2010 21:42)
        
        Это вы чушь написали. Если эти все причины влияют на флеш данных, то на флеш программы они будут влиять тоже. Там у вас резервирование предусмотрено? - Shura(26.07.2010 10:29)
        
        Пардон. Перечитал, признаю, что про причины ответил не в тему. В контексте нашего разговора причины - пропадание питания или помехи во время записи/стирания. - testerplus(27.07.2010 01:20)
        
        А что Вас удивляет в резервировании программной памяти? Сам с этим дела пока не имел, но сейчас работаю с человеком, который в 90-е годы разрабатывал электронику для спутников. Параллельно стояли и выполняли одни и те же действия два 386-х процессора, testerplus(274 знак., 26.07.2010 14:04)
        
        не "Ариан-5" случаем? ;=) - koyodza(26.07.2010 14:07)
        
        Смешно :) - testerplus(26.07.2010 14:21)
        
        почему? Там тоже два бортовых компьютера было, и оба успешно выполнили одни и те же ошибочные действия - koyodza(26.07.2010 15:02)
        
        Просто в тему :). Нет, не Ариан-5. Он не рассказывал подробностей, но он занимался не пусковой системой, а самим спутником. - testerplus(26.07.2010 15:18)
        
        Меня ничего не удивляет. Но вы ведь программную память не троируете? Почему тогда призываете троировать память данных? - Shura(26.07.2010 14:07)
        
        Потому что процесс записи/стирания очень уязвим. Но если в задаче будет предусмотрена, например, возможность устройству оказаться в запредельных температурах, то я его сделаю и для памяти программы. - testerplus(26.07.2010 14:23 - 14:42)
        
        А я в таких случаях, кроме проверки целостности данных всего сектора, еще и проверку на выход за граничные величины в самих функциях делаю. На этапе инициализации программных модулей, которые эти функции используют. - rezident(26.07.2010 15:02)
        
        Очень правильный подход. Как ни странно, он у многих опытных тоже вызывает нарекания, типа "да расслабься, ничего такого не будет" - testerplus(26.07.2010 15:19)
        
        Дык на учете энергоресурсов, когда скажем в подаче холодной воды получаются значения ниже -10°C или выше +120°C, то это уже авария (датчик или линия неисправны, монтажники каналы датчиков перепутали или труба замерзла или пожар на котельной) и считать rezident(74 знак., 26.07.2010 15:25)
        
        while(1){while(1){nop; nop; nop;}} :> - Snaky(26.07.2010 10:31)
        
        :-))))) На самом деле я про причины не зря спросил. В 99% случаев это ошибки самого программиста, приводящие к записи ахинеи. Что потом они и лечат троированием, семенированием и прочими заплатками. - Shura(26.07.2010 10:35)
        
        Не надо мне рассказывать о причинах ошибок в ПО. Но к криволапости и прямоизвильности программиста (которые, несомненно, на первом месте) я бы еще добавил несколько причин (это помимо внешних, которые я уже описал): testerplus(1303 знак., 26.07.2010 14:06 - 27.07.2010 21:21)
        
        Shura, ты из нас хочешь Дохтуров сделать. Не упрощай. Да, ошибки разработчика. Например можно написать ненадежно работающий программный I2C. Который потом покрыть дублированием. Бывает так, что нужен результат любой ценой. - Vladimir Ljaschko(26.07.2010 11:03)
        
        ага, видел один проект, где программисты делали 3 попытки чтения из 24С64, потом 3 по 3, потом 3 по 3 по 3, после этого оно как-то сходилось. А оказалось, подтяжки на I2C по ошибке были на 470кОм впаяны - koyodza(26.07.2010 11:12)
        
        Оооо, а это уже к вопросу о том, что во всём виноваты программисты. - =AlexD=(26.07.2010 11:38)
        
        конечно виноваты: вместо того, чтобы сообщить о проблеме (явно ведь видно было, что читается далеко не с первого раза), они её решили по-своему - koyodza(26.07.2010 13:39)
        
        ну канешна, канешна :-)))) - =AlexD=(26.07.2010 13:48)
        
        во-во-во, а потом будут писать по форумам "какая гадость этот ваш EEPROM" :-) - Shura(26.07.2010 11:17)
        
        Ну ради бога, только не надо ж при этом россказней про ненадёжность флеш и необходимость дублирования-троирования - Shura(26.07.2010 11:05)
        
        по пунктам: koyodza(1078 знак., 23.07.2010 16:28)
        
        "Да и туда, где находится программа, никто не пишет, страницы выделяются отдельные." Я так понял, что если в программе используются таблицы, то их, грубо говоря, записывать подальше от программного кода? Чтобы в другие страницы mazur(106 знак., 26.07.2010 11:18)
        
        нет, таблицы (константные данные) тут ни при чём. Речь шла о данных, изменяемых в процессе работы - koyodza(26.07.2010 11:39)
        
        Понял. - mazur(26.07.2010 11:43)
        
        По пунктам 2 и 4 возражения считаю несерьезными. А по первому и третьему я бы поспорил, но уже устал бодаться. (Надеюсь, в п.3 про АВР и местоположение EEPROM - это шутка?) testerplus(3191 знак., 23.07.2010 21:39)
        
        Пять раз перечитал -- не понял. Чушь. Все "проблемы Flash" свойственны и EEPROM в равной степени... Про троирование тоже чушь. Характеристики сбоев в Flash таковы, что суммы адекватной разрядности (>=32) -- достаточно... - fk0(24.07.2010 02:16)
        
        В институте на лекциях, навреное, тоже не с первого раза все понимали? По-хорошему, с таким тоном Вас надо бы послать на хер. Либо обоснуйте возражение, либо не лезте в тему, с которой не знакомы. - testerplus(24.07.2010 11:47 - 12:02)
        
        Нет, это Вы тут дезинформируете читателей, несёте явную чушь и никак не подтверждаете свои утверждения. - fk0(25.07.2010 23:47)
        
        расскажите, как Вам поможет троирование, если первый блок переписался корректно, второй сбойный, а третий остался предыдущим? - koyodza(23.07.2010 22:22)
        
        Ответ в вопросе - достоверный первый блок (CRC у первого и третьего должны быть правильными). - testerplus(23.07.2010 22:29)
        
        Вы с "Доктором Т" случайно не знакомы? koyodza(1529 знак., 23.07.2010 22:07)
        
        "Да, лично я на АРМ использую именно CRC16 даже при хранении данных во флеши. Вас это удивляет?". Если честно, то удивляет. Серьезно. Всегда считал это хорошим тоном, но никогда в чужих исходниках не видел, чтобы для запси в eeprom/flash testerplus(1870 знак., 23.07.2010 22:51 - 22:54)
        
        Вот у меня в текущем проекте конфиг в atmel dataflash. Там пара десятков копий конфигурации (с номерами версий). При сбое просто откатится на предыдущий. Разумеется в разных страницах. Чем оно хуже варианта в EEPROM, без CRC и т.п.? Чем хуже EEPROM -- fk0(122 знак., 24.07.2010 02:23)
        
        А кто говорил про конфиг? Я говорил о данных, которые нельзя терять, а не о кофемолках, где "Выберите помол: мелкий, средний, крупный. Спасибо!" Никаких откатов к предыдущим данным, даже в разных страницах. А если в соседней странице пара битов testerplus(75 знак., 24.07.2010 11:46)
        
        Конфиг -- это данные которые нельзя терять. Ибо работать не будет. Не кофемолка. Откат не пред. версию эквиэвалентен полностью выключению питания до записи новой версии. А питание может пропасть всегда. - fk0(25.07.2010 23:49)
        
        Про сумму -- чушь. Сумма всех битов совпадёт только если равное число битов сбросилось и установилось. Что физически весьма маловероятно (пиздец который не лечится, ага). - fk0(24.07.2010 02:20)
        
        Вы физически топологию флеш-памяти представляете? Если она физически организована как, например, 128 битная, то транзисторы каждого 16-го байта побитно будут находиться на одной линии. Так что порча данных в одном и том же разряде - это не миф. Если не testerplus(33 знак., 24.07.2010 11:45)
        
        В сфере быдлокодинга быдлоконтроллеров. - fk0(25.07.2010 23:53)
        
        Ещё раз. Сумма битов (единичный: +1, нулевой: +0) ГАРАНТИРУЕТ, что условии, что "Порча" половины бит в "нулевые", а другой половины в "единичные" при одной операции стирании/программировании -- невозможна физически. Впрочем как и массовое облучение fk0(81 знак., 25.07.2010 23:52)
        
        Рассказы про "невозможно физически" или "вряд ли" оставьте для заказчиков. При записи (не стирании) ошибки могут возниктуть только "0"->"1" ("1" случайно нулем не станет, если мы не рассматриваем произвольное изменения состояния триггера). А testerplus(1716 знак., 26.07.2010 14:13)
        
        Согласен с Вашими рассуждения, но заметил бы, что в для приведенного случая б) обычно используется запись не непосредственно суммы, а, например, ее инверсии. Как-то поможет при одновременной порче в одну строну одинаковых разрядов данных и КС. - sbb(26.07.2010 16:36)
        
        "обычно используется" != "fk0 сказал, что можно просто складывать" :) Конечно КС можно (и нужно) усилить и инверсией, и начальным значением (т.е. суммировать с константой), и т.д. вплоть до CRC16 (или 32). - testerplus(26.07.2010 16:46 - 16:57)
        
        не обращайте внимания, Виктор, пишите статью. действительно интересно будет почитать. - Snaky(26.07.2010 15:30)
        
        полностью поддерживаю vitalka(93 знак., 26.07.2010 15:42)
        
        ..как раз физически ничего не маловероятно (было такое). Контрольная сумма также не обнаруживает перестановку байт местами и еще много чего. - blackbit(24.07.2010 11:07)
        
        Кстати да, большие современные EEPROM часто не побайтовые, а по-страничные -- и при сбое питания гробится страница (до 256 байт) целиком. Atmel как бы подтверждает... - fk0(23.07.2010 18:06)
        
        По-безопасности: flash позволяет данные хранить на кристалле с MCU. Его снаружи не считать. А EEPROM на I2C? Нужно шифрование. - fk0(23.07.2010 18:04)
        
        Это еще что и о чем? Вы о какой безопасности говорите? При чем тут утчека информации? - testerplus(24.07.2010 11:46)
        
        При том, что есть приложения, где чтение EEPROM внешним программатором -- недопустимо с т.з. безопасности. Потому, что позволяет потенциально обойти собственно эту безопасность. Ибо пароли хранятся. - fk0(25.07.2010 23:55)
        
        Вы не поняли, речь не о безопасности доступа и не о защите информации. - testerplus(26.07.2010 14:14)
        
        0. Мы в 1998 году освоили i2c eeprom совместно с pic16c86 и до конца света в 2013 году будем его ставить. - fk0(23.07.2010 18:03)
        
        данные во внутренней флеши удобны хотя бы тем, что не нужно дополнительное время на их чтение. Внешняя EEPROM фактически будет требовать держать всё что часто нужно в ОЗУ. Кроме того, это дополнительное место на плате (критично для девайсов мелких koyodza(80 знак., 23.07.2010 19:35)
        
        Я бы к этому добавил, что наличие дополнительного чипа EEPROM увеличивает номенклатуру, и соотвественно риск снятия чипа с производства. Для того, что выпускается много-много лет проблема срока жизни элементов имеет место быть, и чем меньше элементов, sbb(354 знак., 24.07.2010 01:12)
        
        И убедительный аргумент. Солнце всходит - не трогай. - Vladimir Ljaschko(23.07.2010 18:18)
        
        Вы до сих пор используете 8748? - koyodza(23.07.2010 19:30)
        
        Вы уже передергивать начали - Alex B.(23.07.2010 17:03)
        
        ничем ;=) - koyodza(23.07.2010 16:11)

Микроконтроллеры