caxapa.ru :: Не чушь, мне жаловались (однажды правил программу, управляющую подъемником в производственном цехе). Два года работало как часы, а потом подъемник стал зависать между "этажами" (ячейками). Как выяснилось, проблема была в исчерпанном "цикло"-ресурсе

testerplus (22.07.2010 11:08, просмотров: 134) ответил koyodza на чушь редкостная. EEPROM нет ни у MSP, ни у силабса, ни у STM/STR, и никто не жалуется. Запись данных во FLASH обычно требует немного больше ОЗУ (на буфер страницы), которого в PIC/AVR хронически мало

Не чушь, мне жаловались (однажды правил программу, управляющую подъемником в производственном цехе). Два года работало как часы, а потом подъемник стал зависать между "этажами" (ячейками). Как выяснилось, проблема была в исчерпанном "цикло"-ресурсе flash. После получения указаний (куда двигаться), данные о них сохранялись во flash, чтобы восстановиться, если что. Через два года flash стала сбоить. А насчет "не пишут в одни и те же ячейки" есть большой минус: для хранения одного параметра (пускай даже многобайтового) нужно выделять целый блок. И еще, если сбой происходит во время стирания, то можем получить большую проблему: после ресета МК может и не догадаться, что флеш недостерта, а недостертые ячейки будут нестабильно читаться и время от времени давать разные значения.

Ответить

- ни один из приведенных аргументов не выдерживает критики. Shura верно указал на источник проблем - koyodza(22.07.2010 11:47)
  - Да с источником проблем все понятно. А какой из аргументов не выдерживает критики? Я привел два: требуется большой объем памяти для хранения малого объема данных (это когда пытаемся стирать пореже) и проблемы с содержимым flash при потере питания во testerplus(16 знак., 22.07.2010 11:55)
    - нет никаких проблем при стирании, просто стираемый сектор остаётся с мусором. Хранить по одному параметру в одном секторе тоже не нужно, есть несколько способов решения. То, что памяти тратится больше - пусть, кого это волнует? Ну выделил я два участка koyodza(123 знак., 22.07.2010 12:14)
      - Он остается не с мусором, а с данными, которые будут нестабильно читаться. Тут и контрольная сумма может не спасти (тем более на практике видел, как некоторые ее вычисляют простым XOR-ом). А насчет "кого волнует больше памяти": в контроллере LPC1102 32 testerplus(635 знак., 22.07.2010 12:30)
        
        это с какой радости память программ контрольной суммой тестируется, а память данных нет? Ну а 2кБ я указывал как пример, мне обычно хватает 1кБ для настроек и столько же для их дублирования. Для защиты применяется СRC, запись копии не начинается до koyodza(268 знак., 22.07.2010 12:41)
        
        Все должно тестироваться контрольными суммами. Но в Вашей схеме с одним блоком есть слабое место: когда-то его придется стереть для перезаписи. Понятно, что пропадание питания или мега-нано-помеха в этом случае редкость (хотя, смотря в каких условиях testerplus(161 знак., 22.07.2010 12:55)
        
        кто сказал про один блок? Чукча не читатель? "столько же для их дублирования" - koyodza(22.07.2010 13:30)
        
        Пардон, прочитал как "их же для дублирования" :) Но тогда ведь уже ощущается потеря памяти? testerplus(322 знак., 22.07.2010 13:56)
        
        ну у Вас то вообще троирование Ж=Р - koyodza(22.07.2010 16:20)
        
        А что тут смешного? Есть вариант проще? Я как раз готовлю материал по теме отказоустойчивости ПО в МК, там затрону тему сохранения данных в энергонезависимую память. С радостью опишу более простой и надежный вариант, чем троирование. И к слову: testerplus(315 знак., 22.07.2010 16:45)
        
        Как удалось увидеть столько чужих исходников? Все же их скрывают, так как боятся, что будут осмеяны. - Леонид Иванович(23.07.2010 02:03)
        
        По работе в основном занимаюсь выискиванием ошибок в программах. Есть постоянные клиенты. А насчет осмеяния: этого боятся, наверное, только в России, тут прогаммисты поамбициознее в плане иллюзий по поводу своей ведущей роли в проектах, а просветления testerplus(777 знак., 23.07.2010 09:22 - 09:33)
        
        С такой работой можно и веру в человечество потерять. - PlainUser(23.07.2010 09:56, )
        
        Как говорил Остап Бендер: "Я не только трудился. Я даже пострадал. После разговоров с Берлагой, Скумбриевичем и Полыхаевым я потерял веру в человечество. Разве это не стоит миллиона рублей, вера в человечество?". Я за это деньги получаю. - testerplus(23.07.2010 10:31)
        
        тут можно смотреть, например -> - Snaky(23.07.2010 08:52, ссылка)
        
        Исходники приоритетного троирования! Смейтесь! :) Vladimir Ljaschko(455 знак., 23.07.2010 07:33)
        
        Немного странная реализация. Конечно, надо видеть, что там дальше делается (и что внутри РестореОллСетап'а), но это все же дублирование (даже если 5 копий сделать), а не троирование. testerplus(514 знак., 23.07.2010 09:31)
        
        "контрольная сумма все еще будет сходиться, а данные уже будут битыми" - поясните - 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)
        
        проще предложить не смогу, это факт. Насчёт среднего уровня коммерческих разработок моя статистика примерно та же - koyodza(22.07.2010 17:13)
        
        Поддерживаю. Всегда считал дополнительным риском запись в программную флеш в процессе работы. Хорошо, когда в МК есть аппаратная защита отдельных блоков флеш, которая не снимается просто программой. - sbb(22.07.2010 15:51)
        
        эти предрассудки происходят видимо от тех же АВР, на которых многие обходят ячейку EEPROM с адресом 0, и не нужно проецировать эту проблему на всех. Что касается аппаратной защиты отдельных блоков, то она у современных МК есть - koyodza(22.07.2010 16:29)
        
        Не, у меня точно не от AVR, ибо его-то EEPROM не использовал:) Видимо с тех времен, когда ни AVR, ни встроенной еще флеш не было. sbb(533 знак., 22.07.2010 17:21)
        
        зашита есть в стм32 и стр91 например. В силабсах есть, но там чуть другое. Насчёт мсп подробностей не помню, давненько на них ничего не делал - koyodza(22.07.2010 18:04 - 18:07)
        
        Я в курсе об STM32, применяю. - sbb(22.07.2010 18:56)
- Проблема была не в исчерпанном "цикло"-ресурсе flash а в мозгах у разработчика. "Грамотным" долбежом можно и EEPROM замучить и даже FRAM - Shura(22.07.2010 11:36)

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