Для любого семейства кодов с обнаружением/исправлением ошибок сначала задаются длина блока данных и требуемое число обнаруживаемых/исправляемых битов, а по этим данным рассчитываются требуемая длина блока коррекции и функции свертки/проверки.
По скорости смотрите сами - имхо, поиск по таблице сбойных байтов и ремап будут ой не быстрыми. А когда предполагается производить поиск сбойных байтов? При записи блока данных с проверкой по факту сбоя (все равно как минимум CRC как предельный случай упомянутых кодов) или предварительно/периодически?

Хм...если мне память не изменяет, Хэмминг предполагает защиту одного n-разрядного слова...

Поиск сбойных байтов произвести очень легко. В данной серии есть команда Main Memory Page to Buffer Compare , что облегчает контроль. Так как размер блока данных, относительно, не большой, можно производить запись только в буфер, а, в случае переполнения буфера, проверять целостность записанных данных. Кроме того, делать то же самое при пропадании питания (в устройстве два питания). Вот только не определился с таблицей сбойных...чего? Толи сбойных страниц, то ли страницу разбить на сектора размерности структуры данных. Смысла контролировать отдельные ячейки я не вижу...

И? Давайте считать Ваш блок данных n-разрядным словом (кста, Вы поминали 12 байтов - блок данных 8-15 байтов требует 8 дополнительных битов для исправления 1-кратных ошибок).

Посмотрите AT45DB041B Reliability Qualification Report (http://www.atmel.com/dyn/resources/prod_documents/45DB041B.pdf), но как-то оно там слишком шоколадно.
А выполнять проверку целостности при чтении блока Вы не предполагаете? Хозяин - барин.

Я не понял сначала Ваш ход мыслей...Счас понял...Но копаться с битами, на первый взгляд, геморно... Хотя, глаза боятся - руки печатают))) Может быть проще вместо UCHAR объявить UINT...?Объем расходуемой памяти, правда увеличится в два раза...

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

UCHAR удобнее, т.к. используемый Вами контроллер скорее всего работает с 1-байтовыми данными.
Любой алгоритм контроля целостности предполагает неудобную (скрытую) операцию вычисления номера бита. Использование таблиц делает ее скрытой. Но для блока данных в 12 байт таблица получится немерянной.
Т.к. у Вас частота записи во флеш невысока, то вычисление контрольного кода можно вести в фоне.

Дык именно это враги и проверяют при всяких endurance test памяти - частоту искажения информации. А чем оно (искажение) вызвано - взрывом ядреной бомбы, отказом ячейки или преждевременной утечкой заряда с затвора транзистора - дело следующее. Я почему и сказал, что результаты тестов ну очень шоколадные - ни одного сбоя ни в одном тесте. Если исходить из этого, то можно вообще ничего не контролировать.

Тгда, может быть проще, добавить к структуре два байта CRC? Расформатировать флэшину на сектора по размерности структуры (к примеру размером, допустим, в степени 2, или чтобы размер точно делился на размер буфера/страницы), да и шут с ним. Пишем - проверяем цеостность данных сравнивая с буфером, читаем - у нас есть CRC...

Если нужно только контролировать целостность данных, то, естесно, достаточно контрольной суммы какого-либо вида. Если же хочется их и восстанавливать, то... Ну Вы сами знаете.

Данные считываются с нескольких датчиков, с некоторых циклически, с некоторых по событию, раз в сутки предполагается эти данные снимать, за тем все повторяется. Так что, ИМХО, защиту восстанавливающими кодами, вводить не стоит, ограничусь CRC на структуру...

Так, вдогонку ...
Когда-то делал контроллер для пейджингового передатчика, пришлось кодировать кодом БЧХ. 20 битов данных защищались 10 битами кода, исправлял пять ошибок и от шести обнаруживал. Кодирование БЧХ очень простое, набор полиномов, Z80 справлялся на лету. Декодирование чуть сложнее. Но, наверное, это для параноиков

если вы читаете данные из флэшины раз в сутки, то видимо за сутки вы сделаете максимум один цикл её записи......... даже если брать минимальный ресурс приведённый в этой теме 10к - то получается 27 лет............ из практики использования флэшин ат45db321 ошибок не было....... правда до 10к дело ещё не дошло........))))) а контроль ошибок в качестве CRC на буфер вводить помойму целесообразно..... ресурсов ест немного, а на душе спокойней))))))

Чего то я не понял... Я собираюсь записывать данные во флэш с интервалом от 1 сек до 1(3) мин. Об этом я написал в первом посте. Пусть я буду кэшировать данные в обоих буферах пока они не заполнятся... Как у меня получится всего один цикл записи, если я сливаю данные круглосуточно?

Алгоритм Хемминга - частный случай алгоритма BCH. В POCSAG'е используется BCH(32,21,5) - 32-бит. блок = 21 бит данных + 11 бит контроля, до 2 ошибок исправляется, до 5 - обнаруживается.

Если писать данные в сектор последовательно то все должно работать OK, никаких сбоев не наблюдалось, по крайней мере у меня работает.
Более подробно можно поммотреть -> http://www.gaw.ru/html.cgi/txt/ic/Atmel/me.../at45/about.htm