Несанкционированная запись в EEPROM PIC16F628a

[realid]

Этого вопроса хватает чтобы уже не давать вам какие-либо советы, а вы, судя по изложению вопроса, плаваете во многих областях. Поэтому, никакие советы вам не помогут, это пустая трата времени, это приговор.

Да ладно вам, так хоть человек про CRC узнает

[Easyrider83]

Я не хочу быть причастным к этому маскараду.

[AndGrig]

Я не хочу быть причастным к этому маскараду.

Вот за это большое спасибо.
Да и всем ответившим - тоже. Обосрали по полной. Помехозащищенное кодирование я изучал, примерно, в году 1973. А под моими контроллерами работает цех машин в 20-ть. Просто там EEPROM не задействован. Тему прошу закрыть.

[nahimovv]

Обосрали по полной.

Это было так же легко, как вам задать вопрос, который, несмотря на свою простоту не имеет простых и однозначных ответов.

Помехозащищенное кодирование я изучал, примерно, в году 1973. А под моими контроллерами работает цех машин в 20-ть. Просто там EEPROM не задействован.

Помехозащищённость и устойчивость программ это целый комплекс мер по разводке, схематике и разработке программного обеспечения, а вы ожидаете простой и понятный ответ? Нонсенс! Вам лень утруждать себя разбираться и экспериментировать? А без этого никак, причин некорректного поведения программ и оборудования может быть уйма, и чтобы получить хоть какой-то внятный ответ нужно приложить усилия по максимальной локализации проблемы. Однако это ещё не факт, что при дальнейшей эксплуатации не выплывет что-нибудь другое. Разработка устройств промышленного применения таит в себе много неочевидного и невероятного.

[AndGrig]

...чтобы получить хоть какой-то внятный ответ ...

Не все так плохо. Ответ я получил - использовать корректирующий код, например - СRC (который при советской власти назывался просто циклическим избыточным). Я полагал, что есть нечто стандартное для таких случаев.
Добрые вы. Хорошо, что я не юнец, а то бы забил на контроллеры. Ведь сложно это и помощи хрен дождешься от грамотных дядек.
Всем - спасибо.

[Easyrider83]

Хотите грамотный ответ - выкладывайте весь проект с фотографиями и пояснениями. Впрочем, это я вам уже говорил. CRC вам особо не поможет. Ну да, поймет станок, что данные в EEPROM не верны и вместо того, чтобы начать крушить железо, просто встанет с ошибкой. И вы побежите его ремонтировать. Отличное решение!

[nahimovv]

Я полагал, что есть нечто стандартное для таких случаев.

А я полагаю, что мой вопрос тоже есть "нечто стандартное для таких случаев", при каких условиях у вас портится EEPROM, что является причиной? Простой такой вопрос, ответьте?

[AndGrig]

...при каких условиях у вас портится EEPROM, что является причиной?

Если бы я знал, то и вопрос бы не задавал. Тысячи циклов станок отработал, а потом... Питание контроллера - автономное, все входы-выходы гальванически развязаны кроме кнопок "больше- меньше", которые находятся в 20 мм от контроллера на той же плате. Силовая часть сварки в 40 см. Ничего не экранировано. Попробую экран, трижды запишу байты а ПЗУ, при чтении буду сравнивать и перезаписывать бракованный байт.

[alvadep]

AndGrig, Вы не ответили на мой вопрос. Каждый раз в цикле чтение EEPROM? Я к тому, что чем меньше обращаешься к EEPROM, тем меньше вероятность повреждения данных. Лучше один раз при старте переписать данные в озу и работать с ним. Ну и то, что предлагали по поводу проверки целостности данных.

[niXto]

Я к тому, что чем меньше обращаешься к EEPROM, тем меньше вероятность повреждения данных.

Это ещё почему? Там же не ФРАМ

Плату показывайте, 99% - кривая земля и экономия на керамике и электролите (если он там вообще есть), контроллер ногами ловит что надо и не надо ("Силовая часть сварки в 40 см" - это как бы очень близко), короче трассировка платы по всем правилам вылечит болезнь навсегда