testerplus (30.07.2010 16:36, просмотров: 204) ответил Shura на Не надо только резервирование программного кода сюда валить.-
- Вот я и говорю - не надо его сюда валить. Это не имеет никакого отношения к восстановлению контроллером собственной программы. - Shura(30.07.2010 16:38)
- По первому сообщению в этой ветке - резервирование как раз к теме. Я, конечно, помню, откуда ветка была перемещена, но и там тоже речь шла о резервировании. - testerplus(30.07.2010 16:50)
- Не передергивайте, там речь шла о резервировании прошивки а не о программной избыточности - Shura(30.07.2010 16:54)
- Наверное, кто-то кого-то неправильно понял. Речь шла именно о резервировании, которое включает в себя как программную избыточность, так и дублирование (или троирование) программных блоков. Троирования в МК (даже без флеши) пока не встречал, а testerplus(144 знак., 30.07.2010 17:04, ссылка)
- Нет, речь изначально шла о том, что хранение данных во флеши ненадёжно Shura(92 знак., 30.07.2010 17:07)
- Изменяемых данных. Т.к. запись и стирание - очень уязвимый процесс. - testerplus(30.07.2010 17:10)
- Обычный штатный документированный процесс. Ничем не уязвимее, чем запись в ОЗУ, регистры или порты. - Shura(30.07.2010 17:13)
- Он, во-первых, очень длительный по сравнению с RAM; а во-вторых, в отличие от RAM и портов, данные в EEPROM остаются после пропадания питания. И после включения питания ни RAM, ни порты не знают, был ли сбой. И тут о предыдущем режиме работы устройства testerplus(48 знак., 30.07.2010 17:20)
- Ну и что? Зато туда пишут гораздо реже - Shura(30.07.2010 17:23)
- В общем - да. Но иллюзии по поводу их правильности иногда могут привести к печальным последствиям. - testerplus(30.07.2010 17:25)
- Причины, которые могут привести к их неправильности в штатном режиме работы прибора известны, как с этим бороться - тоже. - Shura(30.07.2010 17:28)
- Хм :) А во внештатном? (Может, в 0xFF? А то тут кто вопрос задаст, его и не заметят) - testerplus(30.07.2010 17:30, ссылка)
- А во внештатном может что угодно быть и пытаться от этого защититься бессмысленно - Shura(30.07.2010 17:32)
- Хм :) А во внештатном? (Может, в 0xFF? А то тут кто вопрос задаст, его и не заметят) - testerplus(30.07.2010 17:30, ссылка)
- Причины, которые могут привести к их неправильности в штатном режиме работы прибора известны, как с этим бороться - тоже. - Shura(30.07.2010 17:28)
- В общем - да. Но иллюзии по поводу их правильности иногда могут привести к печальным последствиям. - testerplus(30.07.2010 17:25)
- Ну и что? Зато туда пишут гораздо реже - Shura(30.07.2010 17:23)
- Он, во-первых, очень длительный по сравнению с RAM; а во-вторых, в отличие от RAM и портов, данные в EEPROM остаются после пропадания питания. И после включения питания ни RAM, ни порты не знают, был ли сбой. И тут о предыдущем режиме работы устройства testerplus(48 знак., 30.07.2010 17:20)
- Обычный штатный документированный процесс. Ничем не уязвимее, чем запись в ОЗУ, регистры или порты. - Shura(30.07.2010 17:13)
- Изменяемых данных. Т.к. запись и стирание - очень уязвимый процесс. - testerplus(30.07.2010 17:10)
- Нет, речь изначально шла о том, что хранение данных во флеши ненадёжно Shura(92 знак., 30.07.2010 17:07)
- Наверное, кто-то кого-то неправильно понял. Речь шла именно о резервировании, которое включает в себя как программную избыточность, так и дублирование (или троирование) программных блоков. Троирования в МК (даже без флеши) пока не встречал, а testerplus(144 знак., 30.07.2010 17:04, ссылка)
- Не передергивайте, там речь шла о резервировании прошивки а не о программной избыточности - Shura(30.07.2010 16:54)
- По первому сообщению в этой ветке - резервирование как раз к теме. Я, конечно, помню, откуда ветка была перемещена, но и там тоже речь шла о резервировании. - testerplus(30.07.2010 16:50)
- Вот я и говорю - не надо его сюда валить. Это не имеет никакого отношения к восстановлению контроллером собственной программы. - Shura(30.07.2010 16:38)