Микроконтроллеры

Рассказы про "невозможно физически" или "вряд ли" оставьте для заказчиков. При записи (не стирании) ошибки могут возниктуть только "0"->"1" ("1" случайно нулем не станет, если мы не рассматриваем произвольное изменения состояния триггера). А вот как сойдется CRC (простая сумма), при ошибке "0"->"1": a) Для равноразрядных исходный данных и CRC: A32 + B32 = CRC32. Если оба старших разряда A и B вместо "0" стали "1", то CRC сойдется б) Для неравноразрядных: A16 + B16 = CRC32. При одновременной порче (также из "0" в "1") одинаковых разрядов в A и CRC проверка состоится. в) Ошибки могут появлятся не только на одной линии, так что портиться могут и соседние разряды. И еще пара слов о топологии: у всех транзисторов на подложке имеется разброс значений габаритов затвора, это связано с технологическими ограничениями при производстве (поищите в инете фото под микроскопом, там это хорошо видно). Чем выше степень интеграции, тем больше разброс. Скорость инжекции зарядов (и туннелирования, кстати, тоже) пропорциональна габаритам при прочих равных условиях. Если два затвора, имеющие различия в габаритах в 10%, недополучили заряд при записи, то количество этого заряда в них будет разным, и один будет читаться как "0", а второй нет. (При нормальной записи количество зарядов в обоих затворах будут гарантировано отражать "0", невзирая на разницу габаритов). И заодно подумайте, почему программаторы после программирования (как Flash, так и EEPROM) выполняют затем 2 сравнения: на предельно высоком напряжении и на предельно низком? Наверное, производители программаторов дураки, не знают, что это делать необязательно, да? (Возражения: "Я шью ПониПрогом и все работает" - не принимаются) P.S. Любопытно, в статье хотел всего страницу выделить насчет EEPROM (отметить про метод подсчета контрольной суммы и тройное резервирование) и страницу про выбор эелементной базы в зависимости от типа хранимых данных. А тут такое развели...