PlainUser (22.07.2010 07:27, просмотров: 120071) Shura-
- Уточняю , отдельную страницу флеши для доступа в которую необходимо ВРУЧНУЮ чего-нибудь попереключать в регистрах можно приравнять к ЕЕПРОМ в контексте данного топика.Речь именно о возможной порче исполняемого кода при корявой записи каких-нибудь PlainUser(12 знак., 26.07.2010 12:31,
)
- Почему бы тогда не вести речь о просто возможно неправильной ("корявой") работе программы? Хотя некоторые контроллеры имеют защиту от стирания/записи для части программной памяти. - fk0(26.07.2010 22:48)
- Если в процессе записи будут проблемы с питанием то возможна порча кода вследствии появления неверных адресов на шине.В отдельном-же банке нужно еще его переключить. - PlainUser(27.07.2010 07:18, )
- Но согласитесь, если в контроллере индивидуальная супер-пупер установка разрешения стирания/записи секторов, то теоретически программная память никогда не испортится. Но и не обновится :) Vladimir Ljaschko(261 знак., 27.07.2010 08:52)
- Не супер-пупер а обычный регистр в котором нужно поставить нужный битик или снять его. PlainUser(155 знак., 27.07.2010 10:47, )
- При чем тут идиот? Vladimir Ljaschko(423 знак., 27.07.2010 10:58)
- Защиту от перезаписи блоков флеши в некоторых МК посерьезней защищают (увы, не у всех:)). sbb(468 знак., 27.07.2010 12:46)
- Если в программе есть строка, где эта самая разблокирующая последовательность формируется, то кто помешает при сбое программе попасть именно туда? ;-) Shura(207 знак., 27.07.2010 12:53)
- Разблокирующая последовательность не должна формироваться в коде. Зачем, если ее можно передать бутлоадеру. 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)
- Если в программе есть строка, где эта самая разблокирующая последовательность формируется, то кто помешает при сбое программе попасть именно туда? ;-) Shura(207 знак., 27.07.2010 12:53)
- Программа конечно может вылететь на неправильный адрес , физически это возможно , вот только приличных методов борьбы с этим в рамках одного процессора нет. - PlainUser(27.07.2010 12:08, )
- Вы тут чё-то все загнались не по-детски! Можно подумать прям разрабатываете какие-то суперкрутые системы для ракет или самолётов! Прям и ресет надо обрабатывать и метки какие-то в ОЗУ хранить! Пипец! Может ещё будете ставить диагностический процессор, FDA(386 знак., 28.07.2010 09:12)
- А устройству и не надо работать в таких условиях, достаточно просто однажды оказаться в них (пускай при транспортировке). - testerplus(28.07.2010 12:00)
- При-чем тут флеш , рядом должна стоять железная дура на релюшках и осуществлять цензуру. PlainUser(130 знак., 28.07.2010 09:26, )
- Кстати в конце цепочки контролирующих систему устройств видимо должно стоять абсолютно твердое и абсолютно черное тело. - PlainUser(28.07.2010 10:40, )
- С жезлом :-) Имхо, тема себя исчерпала, давайте завязывать - Shura(28.07.2010 10:45)
- тема себя исчерпала уже на следующий день после того, как началась. Даже не исчерпалась, а превратилась в докторский бред - koyodza(28.07.2010 10:48)
- В отличии от разных докторов я практик , иногда даже больше чем хотелось-бы.Вот количество этой практики , как и положено пытается перейти в качество.Много лет наблюдаю одно и то-же.Разные люди , разные коллективы и каждый сам себе теоретик PlainUser(263 знак., 29.07.2010 08:46, )
- А по мне так, пожалуй, единственная тема за последние несколько лет, в которой реально поднимаются не очевидные вопросы надежности ПО и аппаратуры на МК. Dir(2405 знак., 28.07.2010 14:01)
- В статье собирался осветить несколько вопросов из списка и еще несколько других. Только пока не знаю, когда будет готово (да и писанины по прикидкам больше чем на 100 страниц получится) - testerplus(28.07.2010 14:50)
- Весьма высоко ценю ваш опыт полученный на нелегкой работе.Если не затруднит хотел-бы ознакомится с любыми опубликованными вами по этой теме материалами.Сегодня , завтра , через год -два...время роли не играет . plainuserГАВmail.ru - PlainUser(29.07.2010 09:01, )
- А у меня материалов не так много, и они больше адресованы начинающим -> - testerplus(29.07.2010 12:52, ссылка)
- А начать и обкатать можно в википедии. - General(28.07.2010 16:53, ссылка)
- "Обкатать" - это пободаться, как с темой про Flash? :) - testerplus(28.07.2010 17:17)
- Такую статью (>100 страниц) никто не примет. Если опыт есть, сразу на книгу можно замахнуться. А вот обкатать тематику можно и на конфе. При серьезном фактическом обосновании тон обсуждения будет совсем другой. - Dir(28.07.2010 15:21)
- Весьма высоко ценю ваш опыт полученный на нелегкой работе.Если не затруднит хотел-бы ознакомится с любыми опубликованными вами по этой теме материалами.Сегодня , завтра , через год -два...время роли не играет . plainuserГАВmail.ru - PlainUser(29.07.2010 09:01,
- заметьте, что ни я ни Shura не подвергали сомнению важность вопроса надёжности и прочее, а только высказались против утверждений в стиле "встроенная FLASH не годится для хранения данных" и "троирование данных - лучший вид их защиты" - koyodza(28.07.2010 14:13)
- Да нет, со стороны ваши возражения выглядят как непрерывные поиски д-ра Туамосеса и почти всегда заканчиваются: "тема себя изжила"... Возможно я не прав, т.к. только что из отпуска. - Dir(28.07.2010 14:34)
- можете попробовать перечитать в хронологическом порядке. Кстати, сама тема - всего лишь ветка из другого обсуждения, по поводу замены мега8 на лпц1111 - koyodza(28.07.2010 14:37)
- ОК. Попробую. - Dir(28.07.2010 14:43)
- можете попробовать перечитать в хронологическом порядке. Кстати, сама тема - всего лишь ветка из другого обсуждения, по поводу замены мега8 на лпц1111 - koyodza(28.07.2010 14:37)
- Да нет, со стороны ваши возражения выглядят как непрерывные поиски д-ра Туамосеса и почти всегда заканчиваются: "тема себя изжила"... Возможно я не прав, т.к. только что из отпуска. - Dir(28.07.2010 14:34)
- В статье собирался осветить несколько вопросов из списка и еще несколько других. Только пока не знаю, когда будет готово (да и писанины по прикидкам больше чем на 100 страниц получится) - testerplus(28.07.2010 14:50)
- В отличии от разных докторов я практик , иногда даже больше чем хотелось-бы.Вот количество этой практики , как и положено пытается перейти в качество.Много лет наблюдаю одно и то-же.Разные люди , разные коллективы и каждый сам себе теоретик PlainUser(263 знак., 29.07.2010 08:46,
- тема себя исчерпала уже на следующий день после того, как началась. Даже не исчерпалась, а превратилась в докторский бред - koyodza(28.07.2010 10:48)
- С жезлом :-) Имхо, тема себя исчерпала, давайте завязывать - Shura(28.07.2010 10:45)
- Вот не люблю это - смешно, не смешно. Можно выполнить вполне серьезное программное действие - обнаружить сбой и сброситься или остановиться. Vladimir Ljaschko(238 знак., 28.07.2010 09:33)
- Смешно это значит строго говоря бессмысленно.Устройство подвегшееся действию помех (где гарантия что она была одна ?) не может само себя контролировать , во всяком случае уровень доверия такому контролю весьма низкий.Конкретные меры(CRC заглушки ловушки) PlainUser(502 знак., 28.07.2010 10:06, )
- Надо различать понятия "сбой" и "последствия сбоя". Устройство, имеющее самодиагностику, может перевести себя в безопасный режим, отключив все узлы. Оно по крайней мере не будет "бездумно" следовать алгоритму, но с уже сбитыми параметрами. Понятно, testerplus(113 знак., 28.07.2010 12:04)
- А бут-область проверяете, когда уже аппликейшн функционирует? :-) - amusin(28.07.2010 09:56)
- Смешно это значит строго говоря бессмысленно.Устройство подвегшееся действию помех (где гарантия что она была одна ?) не может само себя контролировать , во всяком случае уровень доверия такому контролю весьма низкий.Конкретные меры(CRC заглушки ловушки) PlainUser(502 знак., 28.07.2010 10:06,
- Кстати в конце цепочки контролирующих систему устройств видимо должно стоять абсолютно твердое и абсолютно черное тело. - PlainUser(28.07.2010 10:40,
- Вы тут чё-то все загнались не по-детски! Можно подумать прям разрабатываете какие-то суперкрутые системы для ракет или самолётов! Прям и ресет надо обрабатывать и метки какие-то в ОЗУ хранить! Пипец! Может ещё будете ставить диагностический процессор, FDA(386 знак., 28.07.2010 09:12)
- Снять битик в регистре программа сама не сможет , и талантливый дятел изучающий глубины ООП в общем то-же.Запись в регистр это действие которое нужно совершить осознанно.А вот писать не в тот адрес из-за дурацких указателей на структуры это легко. - PlainUser(27.07.2010 11:10, )
- Ну а если МК содержит встроенный бутлоадер, то устройство может сбойнуть, запустить бутлоадер и стереть само себя, так? :-) - Shura(27.07.2010 11:01)
- Начинаешь понимать! ;) - Vladimir Ljaschko(27.07.2010 11:22)
- Защиту от перезаписи блоков флеши в некоторых МК посерьезней защищают (увы, не у всех:)). sbb(468 знак., 27.07.2010 12:46)
- При чем тут идиот? Vladimir Ljaschko(423 знак., 27.07.2010 10:58)
- Не супер-пупер а обычный регистр в котором нужно поставить нужный битик или снять его. PlainUser(155 знак., 27.07.2010 10:47,
- Но согласитесь, если в контроллере индивидуальная супер-пупер установка разрешения стирания/записи секторов, то теоретически программная память никогда не испортится. Но и не обновится :) Vladimir Ljaschko(261 знак., 27.07.2010 08:52)
- Если в процессе записи будут проблемы с питанием то возможна порча кода вследствии появления неверных адресов на шине.В отдельном-же банке нужно еще его переключить. - PlainUser(27.07.2010 07:18,
- Почему бы тогда не вести речь о просто возможно неправильной ("корявой") работе программы? Хотя некоторые контроллеры имеют защиту от стирания/записи для части программной памяти. - fk0(26.07.2010 22:48)
- Достаточно бредовое утверждение. При адекватном контроллере Flash, ГРАМОТНОМ КОДЕ и т.п. -- Flash даже лучше. Но в счёт большей софтовой сложности, за то EEPROM и любят. - fk0(23.07.2010 16:26)
- хорошо сказал - koyodza(23.07.2010 16:30)
- чушь редкостная. EEPROM нет ни у MSP, ни у силабса, ни у STM/STR, и никто не жалуется. Запись данных во FLASH обычно требует немного больше ОЗУ (на буфер страницы), которого в PIC/AVR хронически мало koyodza(344 знак., 22.07.2010 09:54 - 10:05)
- Много нюансов в которые вдаваться неохота. Тема вообщето про дешевый и простой проц.Для использования флеша нужно приличный источник питания что по цене дороже доп еепрома и приличная программа , чтоб точно писать куда надо когда надо.Все это с PlainUser(41 знак., 22.07.2010 12:08, )
- при чём тут источник питания? Голову и руки надо в нужных местах иметь. А это и правда дороже - koyodza(22.07.2010 12:18)
- Ну слава Богу, хоть головами и руками стали меряться! ;) - Vladimir Ljaschko(22.07.2010 12:38 - 13:35)
- Источник-то ?Я думал всем это очевидно.Он должен обеспечить непрерывность питания на время записи. - PlainUser(22.07.2010 12:40, )
- C EEPROM проще , слетела и хрен с ним заполним по новой (речь не про СИ). - PlainUser(22.07.2010 12:11, )
- при чём тут источник питания? Голову и руки надо в нужных местах иметь. А это и правда дороже - koyodza(22.07.2010 12:18)
- Не чушь, мне жаловались (однажды правил программу, управляющую подъемником в производственном цехе). Два года работало как часы, а потом подъемник стал зависать между "этажами" (ячейками). Как выяснилось, проблема была в исчерпанном "цикло"-ресурсе testerplus(541 знак., 22.07.2010 11:08)
- ни один из приведенных аргументов не выдерживает критики. 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, )
- С такой работой можно и веру в человечество потерять. - PlainUser(23.07.2010 09:56,
- тут можно смотреть, например -> - 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)
- Как говорил известный вам О. Бендер, полную гарантию может дать только страховой полис. А троирование её не даёт даже близко. - Shura(23.07.2010 15:29)
- А я разве Вас обвинял в XOR'ение? Да, бомбоубежище тоже ненадежно, если прятаться за ним, а не в нем. Просто при грамотном подходе троирование даст гарантию сохранности данных, а дублирование - нет. Другое дело, это не везде нужно. testerplus(276 знак., 23.07.2010 15:04)
- я разве где-то предлагал КС считать XOR`ом? Да и троирование само по себе ненадёжно, если делать его через (_|_) Например, некоторые размещают все три копии в одном секторе - koyodza(23.07.2010 14:57)
- Несовпадение контрольной суммы гарантирует неправильность данных. Но ее совпадение ничего не гарантирует. Если на 7 байт данных держим 1 байт контрольной суммы, то есть в среднем 2^48 вариантов, при которых она совпадет. Во-первых, никто не может testerplus(216 знак., 23.07.2010 14:52 - 14:55)
- Да, у меня не мажоритарное сравнение, а 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)
- почему? Там тоже два бортовых компьютера было, и оба успешно выполнили одни и те же ошибочные действия - 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)
- по пунктам: 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)
- нет, таблицы (константные данные) тут ни при чём. Речь шла о данных, изменяемых в процессе работы - koyodza(26.07.2010 11:39)
- По пунктам 2 и 4 возражения считаю несерьезными. А по первому и третьему я бы поспорил, но уже устал бодаться. (Надеюсь, в п.3 про АВР и местоположение EEPROM - это шутка?) testerplus(3191 знак., 23.07.2010 21:39)
- Пять раз перечитал -- не понял. Чушь. Все "проблемы Flash" свойственны и EEPROM в равной степени... Про троирование тоже чушь. Характеристики сбоев в Flash таковы, что суммы адекватной разрядности (>=32) -- достаточно... - fk0(24.07.2010 02:16)
- расскажите, как Вам поможет троирование, если первый блок переписался корректно, второй сбойный, а третий остался предыдущим? - 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)
- Про сумму -- чушь. Сумма всех битов совпадёт только если равное число битов сбросилось и установилось. Что физически весьма маловероятно (пиздец который не лечится, ага). - 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)
- не обращайте внимания, Виктор, пишите статью. действительно интересно будет почитать. - Snaky(26.07.2010 15:30)
- полностью поддерживаю vitalka(93 знак., 26.07.2010 15:42)
- Рассказы про "невозможно физически" или "вряд ли" оставьте для заказчиков. При записи (не стирании) ошибки могут возниктуть только "0"->"1" ("1" случайно нулем не станет, если мы не рассматриваем произвольное изменения состояния триггера). А testerplus(1716 знак., 26.07.2010 14:13)
- ..как раз физически ничего не маловероятно (было такое). Контрольная сумма также не обнаруживает перестановку байт местами и еще много чего. - blackbit(24.07.2010 11:07)
- Вы физически топологию флеш-памяти представляете? Если она физически организована как, например, 128 битная, то транзисторы каждого 16-го байта побитно будут находиться на одной линии. Так что порча данных в одном и том же разряде - это не миф. Если не testerplus(33 знак., 24.07.2010 11:45)
- "Да, лично я на АРМ использую именно CRC16 даже при хранении данных во флеши. Вас это удивляет?". Если честно, то удивляет. Серьезно. Всегда считал это хорошим тоном, но никогда в чужих исходниках не видел, чтобы для запси в eeprom/flash testerplus(1870 знак., 23.07.2010 22:51 - 22:54)
- Кстати да, большие современные 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)
- При том, что есть приложения, где чтение EEPROM внешним программатором -- недопустимо с т.з. безопасности. Потому, что позволяет потенциально обойти собственно эту безопасность. Ибо пароли хранятся. - fk0(25.07.2010 23:55)
- Это еще что и о чем? Вы о какой безопасности говорите? При чем тут утчека информации? - testerplus(24.07.2010 11:46)
- 0. Мы в 1998 году освоили i2c eeprom совместно с pic16c86 и до конца света в 2013 году будем его ставить. - fk0(23.07.2010 18:03)
- данные во внутренней флеши удобны хотя бы тем, что не нужно дополнительное время на их чтение. Внешняя EEPROM фактически будет требовать держать всё что часто нужно в ОЗУ. Кроме того, это дополнительное место на плате (критично для девайсов мелких koyodza(80 знак., 23.07.2010 19:35)
- И убедительный аргумент. Солнце всходит - не трогай. - Vladimir Ljaschko(23.07.2010 18:18)
- Вы до сих пор используете 8748? - koyodza(23.07.2010 19:30)
- Вы уже передергивать начали - Alex B.(23.07.2010 17:03)
- "Да и туда, где находится программа, никто не пишет, страницы выделяются отдельные." Я так понял, что если в программе используются таблицы, то их, грубо говоря, записывать подальше от программного кода? Чтобы в другие страницы mazur(106 знак., 26.07.2010 11:18)
- Вы уж сначала определитесь - что вы считаете некорректными данными и какие возможные причины их появления. Ибо бороться можно только с известными явлениями, но не с вторжением инопланетян. - Shura(23.07.2010 16:47)
- ничем ;=) - koyodza(23.07.2010 16:11)
- 2 копии хуже 3х, т.к. только по трем можно восстановить данные (или принять решение о их некорректности). А EEPROM лучше флеш по объему (не надо по странице выделять на каждую копию), по безопасности (не нужно писать что-то туда, где есть прорамма) и по testerplus(69 знак., 23.07.2010 16:15)
- Ничем. А чем здесь EEPROM лучше Flash? :-) - Shura(23.07.2010 16:05)
- Вопрос ещё проще. Если, как тут рассказывали, помехи такие сильные, что повреждают данные при записи во флеш, то кто им мешает повредить данные в ОЗУ, которые потом будут успешно 3 раза переписаны в EEPROM :-) - Shura(23.07.2010 15:55)
- "контрольная сумма все еще будет сходиться, а данные уже будут битыми" - поясните - koyodza(23.07.2010 14:17)
- Немного странная реализация. Конечно, надо видеть, что там дальше делается (и что внутри РестореОллСетап'а), но это все же дублирование (даже если 5 копий сделать), а не троирование. testerplus(514 знак., 23.07.2010 09:31)
- По работе в основном занимаюсь выискиванием ошибок в программах. Есть постоянные клиенты. А насчет осмеяния: этого боятся, наверное, только в России, тут прогаммисты поамбициознее в плане иллюзий по поводу своей ведущей роли в проектах, а просветления testerplus(777 знак., 23.07.2010 09:22 - 09:33)
- проще предложить не смогу, это факт. Насчёт среднего уровня коммерческих разработок моя статистика примерно та же - koyodza(22.07.2010 17:13)
- Как удалось увидеть столько чужих исходников? Все же их скрывают, так как боятся, что будут осмеяны. - Леонид Иванович(23.07.2010 02:03)
- А что тут смешного? Есть вариант проще? Я как раз готовлю материал по теме отказоустойчивости ПО в МК, там затрону тему сохранения данных в энергонезависимую память. С радостью опишу более простой и надежный вариант, чем троирование. И к слову: testerplus(315 знак., 22.07.2010 16:45)
- Поддерживаю. Всегда считал дополнительным риском запись в программную флеш в процессе работы. Хорошо, когда в МК есть аппаратная защита отдельных блоков флеш, которая не снимается просто программой. - 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)
- зашита есть в стм32 и стр91 например. В силабсах есть, но там чуть другое. Насчёт мсп подробностей не помню, давненько на них ничего не делал - koyodza(22.07.2010 18:04 - 18:07)
- Не, у меня точно не от AVR, ибо его-то EEPROM не использовал:) Видимо с тех времен, когда ни AVR, ни встроенной еще флеш не было. sbb(533 знак., 22.07.2010 17:21)
- эти предрассудки происходят видимо от тех же АВР, на которых многие обходят ячейку EEPROM с адресом 0, и не нужно проецировать эту проблему на всех. Что касается аппаратной защиты отдельных блоков, то она у современных МК есть - koyodza(22.07.2010 16:29)
- ну у Вас то вообще троирование Ж=Р - koyodza(22.07.2010 16:20)
- Пардон, прочитал как "их же для дублирования" :) Но тогда ведь уже ощущается потеря памяти? testerplus(322 знак., 22.07.2010 13:56)
- кто сказал про один блок? Чукча не читатель? "столько же для их дублирования" - koyodza(22.07.2010 13:30)
- Все должно тестироваться контрольными суммами. Но в Вашей схеме с одним блоком есть слабое место: когда-то его придется стереть для перезаписи. Понятно, что пропадание питания или мега-нано-помеха в этом случае редкость (хотя, смотря в каких условиях testerplus(161 знак., 22.07.2010 12:55)
- это с какой радости память программ контрольной суммой тестируется, а память данных нет? Ну а 2кБ я указывал как пример, мне обычно хватает 1кБ для настроек и столько же для их дублирования. Для защиты применяется СRC, запись копии не начинается до koyodza(268 знак., 22.07.2010 12:41)
- Он остается не с мусором, а с данными, которые будут нестабильно читаться. Тут и контрольная сумма может не спасти (тем более на практике видел, как некоторые ее вычисляют простым XOR-ом). А насчет "кого волнует больше памяти": в контроллере LPC1102 32 testerplus(635 знак., 22.07.2010 12:30)
- нет никаких проблем при стирании, просто стираемый сектор остаётся с мусором. Хранить по одному параметру в одном секторе тоже не нужно, есть несколько способов решения. То, что памяти тратится больше - пусть, кого это волнует? Ну выделил я два участка koyodza(123 знак., 22.07.2010 12:14)
- Да с источником проблем все понятно. А какой из аргументов не выдерживает критики? Я привел два: требуется большой объем памяти для хранения малого объема данных (это когда пытаемся стирать пореже) и проблемы с содержимым flash при потере питания во testerplus(16 знак., 22.07.2010 11:55)
- Проблема была не в исчерпанном "цикло"-ресурсе flash а в мозгах у разработчика. "Грамотным" долбежом можно и EEPROM замучить и даже FRAM - Shura(22.07.2010 11:36)
- Я так понимаю, это в защиту одного безъеепромного семейства? ;-) 100000 циклов всегда лучше, чем 10000, хоть без мозгов, хоть с мозгами =) - she_(22.07.2010 11:53, )
- не всегда. Видел, как внешняя EEPROM убивается за неделю, потому что программист решил текущее время писать туда постоянно, причём даже не раз в секунду, а сколько получилось - koyodza(22.07.2010 12:09)
- А флешь убьется меньше, чем за сутки. И? - she_(22.07.2010 12:10, )
- что "И"? Алгоритм работы надо менять, а не искать другую память - koyodza(22.07.2010 12:16)
- Ого. Партия сказала "надо" - комсомол ответил "есть!" =) Знаете, периодически приходится конечно использовать черезжопные алгоритмы. Но ИМХО лучше выбрать подходящую для задачи платформу, чтобы по возможности этого избежать. Как-то разумнее, не she_(10 знак., 22.07.2010 12:22, )
- согласен. Только в контексте обсуждения это означает "нужно выбирать атмел и лучше него ничего нет" - koyodza(22.07.2010 12:33)
- Ну почему. Пики еще есть. Правда у них основной минус - дистрибьютор в РФ единственный и очень непрозрачный, но может для Украины все иначе... - she_(22.07.2010 12:47, )
- ну а АРМы вообще непригодны 8=) - koyodza(22.07.2010 12:52)
- Ну почему. Пики еще есть. Правда у них основной минус - дистрибьютор в РФ единственный и очень непрозрачный, но может для Украины все иначе... - she_(22.07.2010 12:47,
- согласен. Только в контексте обсуждения это означает "нужно выбирать атмел и лучше него ничего нет" - koyodza(22.07.2010 12:33)
- Ого. Партия сказала "надо" - комсомол ответил "есть!" =) Знаете, периодически приходится конечно использовать черезжопные алгоритмы. Но ИМХО лучше выбрать подходящую для задачи платформу, чтобы по возможности этого избежать. Как-то разумнее, не she_(10 знак., 22.07.2010 12:22,
- что "И"? Алгоритм работы надо менять, а не искать другую память - koyodza(22.07.2010 12:16)
- А флешь убьется меньше, чем за сутки. И? - she_(22.07.2010 12:10,
- не всегда. Видел, как внешняя EEPROM убивается за неделю, потому что программист решил текущее время писать туда постоянно, причём даже не раз в секунду, а сколько получилось - koyodza(22.07.2010 12:09)
- Так а тут о чем спор? Речь о том, что в общем случае (не говорю, что во всех) флеш использовать для хранения изменяющихся данных небезопасно. И с EEPROM'ом-то умудряются напортачить (тут и без "долбежа" можно без данных остаться), а с флеш - и подавно. - testerplus(22.07.2010 11:46)
- настойчивый дятел задалбывает небольшого слона :> имхо, наличие возможности у МК писать в свою флэш в самую первую очередь нужна для бутлоадеров. - Snaky(22.07.2010 11:42)
- Я так понимаю, это в защиту одного безъеепромного семейства? ;-) 100000 циклов всегда лучше, чем 10000, хоть без мозгов, хоть с мозгами =) - she_(22.07.2010 11:53,
- ни один из приведенных аргументов не выдерживает критики. Shura верно указал на источник проблем - koyodza(22.07.2010 11:47)
- Не стоит так категорично. Я жалуюсь :) В проект с MSP430 добавлял внешнюю EEPROM. - Vladimir Ljaschko(22.07.2010 10:04)
- причина? - koyodza(22.07.2010 10:17)
- После того, как прибор залил больницу, перестраховался везде, где можно. Согласен на паранойю :) Да, кстати, после этого было выпущено 2К приборов. - Vladimir Ljaschko(22.07.2010 10:45)
- "Доктор, пациента, которого мы вылечили от паранойи, убили, когда он выходил из клиники" - Vladimir Ljaschko(22.07.2010 10:48)
- После того, как прибор залил больницу, перестраховался везде, где можно. Согласен на паранойю :) Да, кстати, после этого было выпущено 2К приборов. - Vladimir Ljaschko(22.07.2010 10:45)
- причина? - koyodza(22.07.2010 10:17)
- Много нюансов в которые вдаваться неохота. Тема вообщето про дешевый и простой проц.Для использования флеша нужно приличный источник питания что по цене дороже доп еепрома и приличная программа , чтоб точно писать куда надо когда надо.Все это с PlainUser(41 знак., 22.07.2010 12:08,
- не понимаю ваших проблем - Alex B.(21.07.2010 14:13)Shura
- Потенциально опасное действие - писать в свою флэш. Тем более в условиях, когда нужно сохраниться после выключения питания. - Vladimir Ljaschko(21.07.2010 15:16)
- почему опасное, объясните? какие могут быть проблемы? - Alex B.(21.07.2010 15:21)
- 1) Помеха сбивает контроллер и он влетает в функцию IAP с неправильными параметрами. 2)В АВР побайтная запись EEPROM, а в IAP LPC - мин 256 байт. - Vladimir Ljaschko(21.07.2010 15:57)
- видел, как искуственно созданная помеха портит флеш программы, при том что записи в проекте нет вообще. Что прикажете делать? koyodza(109 знак., 22.07.2010 11:44)
- Проблема в том, что в нашем споре любой пример мало что доказывает. - Vladimir Ljaschko(22.07.2010 19:04)
- согласен. Предлагаю перимирие ;=) - koyodza(22.07.2010 19:24)
- Проблема в том, что в нашем споре любой пример мало что доказывает. - Vladimir Ljaschko(22.07.2010 19:04)
- 1) микрочипу в этом случае поможет только внешняя епром, потому как куда писать (флеш/епром) в нем определяется либо одним битом, либо 16-битной командой. Но, правда, я никогда не слышал про порчу флеши при работе с еепром. 2) какая разница, испортится Alex B.(68 знак., 21.07.2010 16:09)
- видел, как искуственно созданная помеха портит флеш программы, при том что записи в проекте нет вообще. Что прикажете делать? koyodza(109 знак., 22.07.2010 11:44)
- Ну например под воздействием помехи в процессе записи бьется флешь в произвольном месте. У мну бывало на стенде такое. - she_(21.07.2010 15:32, )
- а что за помеха? процесс повторяемый? какой контроллер? писали в чистую страницу, или стирали предварительно? интересно же... - Alex B.(21.07.2010 15:45)
- Пример. Контроллер - атмельный арм, пачки наносекундных помех 1КВ по питанию 220В (импульсный ИП, плата ИМХО пристойная, я хуже развожу). Запись с предварительным стиранием. Насчеть повторяемости - постоянно же не будешь писать, никакого ресурса не she_(396 знак., 21.07.2010 16:24, )
- При пропадании питания (или при помехе) во время стирания или записи во Flash в памяти окажется или недостертая информация или недозаписанная. С EEPROM те же проблемы, но там размер блока меньше, легче выкрутиться с тройным резервированием. - testerplus(21.07.2010 15:53)
- Пример. Контроллер - атмельный арм, пачки наносекундных помех 1КВ по питанию 220В (импульсный ИП, плата ИМХО пристойная, я хуже развожу). Запись с предварительным стиранием. Насчеть повторяемости - постоянно же не будешь писать, никакого ресурса не she_(396 знак., 21.07.2010 16:24,
- а что за помеха? процесс повторяемый? какой контроллер? писали в чистую страницу, или стирали предварительно? интересно же... - Alex B.(21.07.2010 15:45)
- 1) Помеха сбивает контроллер и он влетает в функцию IAP с неправильными параметрами. 2)В АВР побайтная запись EEPROM, а в IAP LPC - мин 256 байт. - Vladimir Ljaschko(21.07.2010 15:57)
- почему опасное, объясните? какие могут быть проблемы? - Alex B.(21.07.2010 15:21)
- Потенциально опасное действие - писать в свою флэш. Тем более в условиях, когда нужно сохраниться после выключения питания. - Vladimir Ljaschko(21.07.2010 15:16)
- Уточняю , отдельную страницу флеши для доступа в которую необходимо ВРУЧНУЮ чего-нибудь попереключать в регистрах можно приравнять к ЕЕПРОМ в контексте данного топика.Речь именно о возможной порче исполняемого кода при корявой записи каких-нибудь PlainUser(12 знак., 26.07.2010 12:31,