Перейти к содержанию
    

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для любого семейства кодов с обнаружением/исправлением ошибок сначала задаются длина блока данных и требуемое число обнаруживаемых/исправляемых битов, а по этим данным рассчитываются требуемая длина блока коррекции и функции свертки/проверки.
Хм...если мне память не изменяет, Хэмминг предполагает защиту одного n-разрядного слова...

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для любого семейства кодов с обнаружением/исправлением ошибок сначала задаются длина блока данных и требуемое число обнаруживаемых/исправляемых битов, а по этим данным рассчитываются требуемая длина блока коррекции и функции свертки/проверки.
Хм...если мне память не изменяет, Хэмминг предполагает защиту одного n-разрядного слова...

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

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

Посмотрите AT45DB041B Reliability Qualification Report (http://www.atmel.com/dyn/resources/prod_documents/45DB041B.pdf), но как-то оно там слишком шоколадно.

А выполнять проверку целостности при чтении блока Вы не предполагаете? Хозяин - барин:).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Для любого семейства кодов с обнаружением/исправлением ошибок сначала задаются длина блока данных и требуемое число обнаруживаемых/исправляемых битов, а по этим данным рассчитываются требуемая длина блока коррекции и функции свертки/проверки.
Хм...если мне память не изменяет, Хэмминг предполагает защиту одного n-разрядного слова...

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

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

Посмотрите AT45DB041B Reliability Qualification Report (http://www.atmel.com/dyn/resources/prod_documents/45DB041B.pdf), но как-то оно там слишком шоколадно.

А выполнять проверку целостности при чтении блока Вы не предполагаете? Хозяин - барин :) .

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

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

UCHAR удобнее, т.к. используемый Вами контроллер скорее всего работает с 1-байтовыми данными.

Любой алгоритм контроля целостности предполагает неудобную (скрытую) операцию вычисления номера бита. Использование таблиц делает ее скрытой. Но для блока данных в 12 байт таблица получится немерянной.

Т.к. у Вас частота записи во флеш невысока, то вычисление контрольного кода можно вести в фоне.

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Так, вдогонку ...

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Так, вдогонку ...

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

Алгоритм Хемминга - частный случай алгоритма 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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...