ASDFSUSB-гуру (03.10.2017 13:03, просмотров: 392) ответил g6sgf на Стоит ли заморачиваться с кодом Грея для сохранения в EEPROM mAVR некого счетчика как дополнительной меры повышения надежности? Другими словами, является ли часто изменяемый младший бит слабым звеном в ERASE-WRITE памяти-
- Ортогональная идея - (данные + соль) -> шифрование типа TEA. С минимальным числом раундов. Случайность содержимого любого байта будет хорошая даже при одинаковых байтах. - Evgeny_CD(03.10.2017 14:47, ссылка)
- Возможно, есть более простые алгоритмы. Я просто привел пример с готовой реализацией. Важна суть идеи. - Evgeny_CD(03.10.2017 14:48)
- дублирование не катит (если только с подсчётом КС блока) у меня сделана мажоритарная логика (для mega16). Ну да... тройной расход памяти :( Adept(2962 знак., 03.10.2017 14:10 - 14:38)
- В лоб 2 из 3х не катит - средний если запороть при записи то все три будут разными. При всех разных придется принимать за верное первый байт. Или брать более надежный алгоритм - 1111111(03.10.2017 15:05)
- Зачем же? Если хранится один байт, то делается 4 копии. Обычно успешно мажорированное чтение, но, если все разные, то сравнить с четвертым - g6sgf(03.10.2017 15:54,
)
- 3 от 4 отличаешь? Базар за алгоритм с тремя копиями - 1111111(03.10.2017 18:46)
- Ну это же не панацея, просто средство повышения надёжности. Сбой чаще всего происходит на одиночном байте (случай "все три разные" -
неопределённостьошибка, и его нужно обрабатывать как ошибку. и что значит Adept(92 знак., 03.10.2017 15:12)- К примеру имеем 1/1/1. Пишем 2 - 2/1/1, 2/хуяк пропало питание/1. Имеем 2/0/1. Это для счетчиков актуально. Для кучки одноразовых настроек отлично катит две копии с CRC - 1111111(03.10.2017 15:33)
- Почти всегда в счетчике есть лишний (старший) бит по отношению к имеющейся памяти. Можно его использовать для флага и произвести замену мажорированных значений по принципу перевозки через реку волка, козла и капусты, т.е. всегда будет либо 2 из 3, Petrovich(38 знак., 04.10.2017 13:57, )
- Давай конкретнее про козу, интересно - 1111111(04.10.2017 14:02)
- на питании ёмкости, которые позволяют без проблем записать пару десятков байт :) (не говоря уже об одном). Запись массивов данных с CRC - непростительно долго во многих случаях и гарантированно бьёт ВСЕ данные при порче всего двух байт (по одному Adept(36 знак., 03.10.2017 15:42)
- Эээ... зачем перезапись всего массива? Только нужный байт и CRC. Побьется при записи одна копия - останется вторая. Кондерчики надо ставить если для основного функционала надо. А для сохранения настроек городить банки это слишком - 1111111(03.10.2017 15:52)
- Нестрашная страшилка, т.к. счетчики как правило неоднобайтные - g6sgf(03.10.2017 15:42, )
- Почти всегда в счетчике есть лишний (старший) бит по отношению к имеющейся памяти. Можно его использовать для флага и произвести замену мажорированных значений по принципу перевозки через реку волка, козла и капусты, т.е. всегда будет либо 2 из 3, Petrovich(38 знак., 04.10.2017 13:57,
- К примеру имеем 1/1/1. Пишем 2 - 2/1/1, 2/хуяк пропало питание/1. Имеем 2/0/1. Это для счетчиков актуально. Для кучки одноразовых настроек отлично катит две копии с CRC - 1111111(03.10.2017 15:33)
- Зачем же? Если хранится один байт, то делается 4 копии. Обычно успешно мажорированное чтение, но, если все разные, то сравнить с четвертым - g6sgf(03.10.2017 15:54,
- В лоб 2 из 3х не катит - средний если запороть при записи то все три будут разными. При всех разных придется принимать за верное первый байт. Или брать более надежный алгоритм - 1111111(03.10.2017 15:05)
- Я про код Грея - g6sgf(03.10.2017 14:04, )
- Ортогональная идея - (данные + соль) -> шифрование типа TEA. С минимальным числом раундов. Случайность содержимого любого байта будет хорошая даже при одинаковых байтах. - Evgeny_CD(03.10.2017 14:47, ссылка)