Shura (23.07.2010 16:47, просмотров: 176) ответил testerplus на 2 копии хуже 3х, т.к. только по трем можно восстановить данные (или принять решение о их некорректности). А EEPROM лучше флеш по объему (не надо по странице выделять на каждую копию), по безопасности (не нужно писать что-то туда, где есть прорамма) и по-
- Я говорю о данных, считанных из ячейки, затвор транзистора которой имеет недостаточный заряд для однозначной интрепретации его значения. Причины - любые: магнитные поля, скачки питания, наносекундные помехи, -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)
- почему? Там тоже два бортовых компьютера было, и оба успешно выполнили одни и те же ошибочные действия - koyodza(26.07.2010 15:02)
- Смешно :) - testerplus(26.07.2010 14:21)
- Меня ничего не удивляет. Но вы ведь программную память не троируете? Почему тогда призываете троировать память данных? - Shura(26.07.2010 14:07)
- Потому что процесс записи/стирания очень уязвим. Но если в задаче будет предусмотрена, например, возможность устройству оказаться в запредельных температурах, то я его сделаю и для памяти программы. - testerplus(26.07.2010 14:23 - 14:42)
- А я в таких случаях, кроме проверки целостности данных всего сектора, еще и проверку на выход за граничные величины в самих функциях делаю. На этапе инициализации программных модулей, которые эти функции используют. - rezident(26.07.2010 15:02)
- Потому что процесс записи/стирания очень уязвим. Но если в задаче будет предусмотрена, например, возможность устройству оказаться в запредельных температурах, то я его сделаю и для памяти программы. - testerplus(26.07.2010 14:23 - 14:42)
- не "Ариан-5" случаем? ;=) - koyodza(26.07.2010 14:07)
- 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)
- конечно виноваты: вместо того, чтобы сообщить о проблеме (явно ведь видно было, что читается далеко не с первого раза), они её решили по-своему - koyodza(26.07.2010 13:39)
- во-во-во, а потом будут писать по форумам "какая гадость этот ваш EEPROM" :-) - Shura(26.07.2010 11:17)
- Оооо, а это уже к вопросу о том, что во всём виноваты программисты. - =AlexD=(26.07.2010 11:38)
- Ну ради бога, только не надо ж при этом россказней про ненадёжность флеш и необходимость дублирования-троирования - Shura(26.07.2010 11:05)
- ага, видел один проект, где программисты делали 3 попытки чтения из 24С64, потом 3 по 3, потом 3 по 3 по 3, после этого оно как-то сходилось. А оказалось, подтяжки на I2C по ошибке были на 470кОм впаяны - koyodza(26.07.2010 11:12)
- :-))))) На самом деле я про причины не зря спросил. В 99% случаев это ошибки самого программиста, приводящие к записи ахинеи. Что потом они и лечат троированием, семенированием и прочими заплатками. - Shura(26.07.2010 10:35)
- Это вы чушь написали. Если эти все причины влияют на флеш данных, то на флеш программы они будут влиять тоже. Там у вас резервирование предусмотрено? - Shura(26.07.2010 10:29)
- Я говорю о данных, считанных из ячейки, затвор транзистора которой имеет недостаточный заряд для однозначной интрепретации его значения. Причины - любые: магнитные поля, скачки питания, наносекундные помехи, -40Ц и т.д. вплоть до радиации. - testerplus(23.07.2010 21:42)