-
- Разблокирующая последовательность не должна формироваться в коде. Зачем, если ее можно передать бутлоадеру. sbb(426 знак., 27.07.2010 15:13)
- То, как ты сформулировал, лечится! У меня устройство восстанавливает заданный режим после воздействия помехи. - Vladimir Ljaschko(27.07.2010 12:59)
- Как это? Если в результате воздействия помехи программа влетела в процедуру стирания самое себя то ничего уже она не восстановит - Shura(27.07.2010 13:03)
- Для таких участков кода делается проверка стека (и еще сигнатур в RAM, которые устанавливаются вручную при входе в функцию). - testerplus(27.07.2010 13:07)
- Если программа один раз прыгнула куда не положено, то и проверку стека перепрыгнет :-) Shura(122 знак., 27.07.2010 13:10)
- Сначала устанавливаются адреса, потом делается проверка. Если проверка перепрыгнута, то адреса по-прежнему будут указывать в безопасную область (при стартапе настраиваются), и запись туда ничего не попортит. Панацеи нет, но вероятность понизить - никогда testerplus(11 знак., 27.07.2010 13:14)
- Адреса устанавливаются в ОЗУ, забудьте про их целостность - Shura(27.07.2010 13:16)
- Ну так и проверки все через ОЗУ делаются. Где-то по-любому есть предел октазоустойчивости. Если случится сбой, то в склоке программистов со схемотехниками ни один аргумент не будет принят, какая бы защита ни стояла (схемотехнически тоже от всего не testerplus(13 знак., 27.07.2010 13:34)
- Что вы хотите доказать? Что программа, которая прыгает сама из-за бросков питания - это нормально и программист должен на каждом шагу насовать затычек и проверок, а чтоб это всё страхоуёбище не тормозило, то надо поставить камень в 3 раза шустрее и ОЗУ в Shura(121 знак., 27.07.2010 13:39)
- Не доказать, а сказать, что нельзя пренебрегать проверками, ссылаясь на схемотехников, типа "это их работа". Всего не перепроверишь, но ответственные участки защищать нужно, не рассчитывая на вылизанную электронику. - testerplus(27.07.2010 13:44)
- Могу лишь повториться - защищаться надо когда знаете от чего. А тот список, что вы вывалили, так он только улыбку вызывает. Там почти все компоненты ядерного взрыва перечислены :-) - Shura(27.07.2010 13:50)
- Я за тот список уже извинился (обсуждение шло в двух направлениях, вот я и смешал все в одну кучу). (-40Ц - это много после ядерного взрыва :-/) А вот пример из жизни: testerplus(695 знак., 27.07.2010 14:08)
- "несколько устройств ресетнулись" и "улетела флеш" это совершенно разные вещи. Если программист решил, что в автономном устройстве с батарейным питанием ресет невозможен, его надо отстранять от продолжения работ - koyodza(27.07.2010 18:52)
- Отстранять надо руководителя проекта , этот вопрос вне компетенции программиста.Хотя приличный программист должен быть всегда готов к ресету. - PlainUser(28.07.2010 09:37, )
- Вот это верно! Причем я его осуществляю так: Леонид Иванович(57 знак., 28.07.2010 12:11)
- о, "Графинъ"! :=) koyodza(67 знак., 28.07.2010 13:00)
- "Насчет семи комнат, это Вы на меня намекаете?" :) - testerplus(28.07.2010 13:11)
- о, "Графинъ"! :=) koyodza(67 знак., 28.07.2010 13:00)
- Вот это верно! Причем я его осуществляю так: Леонид Иванович(57 знак., 28.07.2010 12:11)
- Это я уже не к теме сохранности данных. Это я о взаимоответственности программеров и схемотехников. Отстранять - надо, а что толку, если убытки уже есть? - testerplus(27.07.2010 19:23)
- Отстранять надо руководителя проекта , этот вопрос вне компетенции программиста.Хотя приличный программист должен быть всегда готов к ресету. - PlainUser(28.07.2010 09:37, )
- "несколько устройств ресетнулись" и "улетела флеш" это совершенно разные вещи. Если программист решил, что в автономном устройстве с батарейным питанием ресет невозможен, его надо отстранять от продолжения работ - koyodza(27.07.2010 18:52)
- Я за тот список уже извинился (обсуждение шло в двух направлениях, вот я и смешал все в одну кучу). (-40Ц - это много после ядерного взрыва :-/) А вот пример из жизни: testerplus(695 знак., 27.07.2010 14:08)
- Могу лишь повториться - защищаться надо когда знаете от чего. А тот список, что вы вывалили, так он только улыбку вызывает. Там почти все компоненты ядерного взрыва перечислены :-) - Shura(27.07.2010 13:50)
- Не доказать, а сказать, что нельзя пренебрегать проверками, ссылаясь на схемотехников, типа "это их работа". Всего не перепроверишь, но ответственные участки защищать нужно, не рассчитывая на вылизанную электронику. - testerplus(27.07.2010 13:44)
- Что вы хотите доказать? Что программа, которая прыгает сама из-за бросков питания - это нормально и программист должен на каждом шагу насовать затычек и проверок, а чтоб это всё страхоуёбище не тормозило, то надо поставить камень в 3 раза шустрее и ОЗУ в Shura(121 знак., 27.07.2010 13:39)
- Ну так и проверки все через ОЗУ делаются. Где-то по-любому есть предел октазоустойчивости. Если случится сбой, то в склоке программистов со схемотехниками ни один аргумент не будет принят, какая бы защита ни стояла (схемотехнически тоже от всего не testerplus(13 знак., 27.07.2010 13:34)
- Адреса устанавливаются в ОЗУ, забудьте про их целостность - Shura(27.07.2010 13:16)
- Сначала устанавливаются адреса, потом делается проверка. Если проверка перепрыгнута, то адреса по-прежнему будут указывать в безопасную область (при стартапе настраиваются), и запись туда ничего не попортит. Панацеи нет, но вероятность понизить - никогда testerplus(11 знак., 27.07.2010 13:14)
- Если программа один раз прыгнула куда не положено, то и проверку стека перепрыгнет :-) Shura(122 знак., 27.07.2010 13:10)
- Для таких участков кода делается проверка стека (и еще сигнатур в RAM, которые устанавливаются вручную при входе в функцию). - testerplus(27.07.2010 13:07)
- Как это? Если в результате воздействия помехи программа влетела в процедуру стирания самое себя то ничего уже она не восстановит - Shura(27.07.2010 13:03)