Замок на iButton DS1990

[realid]

По 0xFF удобно свободную область искать, а забивание чем попало не спасёт от проблемы...

+100
____________

[nonamedov]

И что толку??? А если фрагментация???

Ключи будут искаться только среди записанных, где никаких 0xFF нет и о какой фрагментации Вы говорите, длина ключа 8 байт?! Записал новый ключ, увеличил число ключей на единицу и все.

[Bar_boss]

+100
____________

А если там будет псевдослучайный набор значений (т.е как раз то "что попало")?
Господа теоретики, не ищите чёрную кошку в тёмной комнате ....

[realid]

А если там будет псевдослучайный набор значений (т.е как раз то "что попало")?

Откуда?

Господа теоретики

Уверены? Самые что ни на есть практики

[realid]

Записал новый ключ, увеличил число ключей на единицу и все.

А если удалил один ключ в середине списка?

[Bar_boss]

Откуда?

Уверены? Самые что ни на есть практики

Как откуда? А что мешает ввести не просто режим стирания памяти (0XFF), а заполнение её псевдослучайными значениями? Кстати, этот алгоритм реализован мной уже лет пять назад на одной GSM сигналке с ключами ibutton.

Насчёт теоретиков - ну извиняйте, если обидел

[nonamedov]

Испортить CRC байт (изменить один байт), и будешь точно уверен, что никакой универсальный ключ не подойдет.

[realid]

Как откуда? А что мешает ввести не просто режим стирания памяти (0XFF), а заполнение её псевдослучайными значениями?

А смысл этого заполнения?

[st_1]

А что мешает ввести не просто режим стирания памяти (0XFF), а заполнение её псевдослучайными значениями?

У вас ресурс циклов безграничен???
"Flash over!"
"Start new Flash."

[Bar_boss]

А смысл этого заполнения?

Я же описывал ситуацию - если в области памяти, где хранятся коды ключей записаны 0xFF (нули) это чревато тем, что многократном замыкании/размыкании входа ключа возможен вариант, что этот "дребезг" будет воспринят как "правильный" ключ. С заполненой разной "шелухой" EEPROM такого не произойдёт никогда (ну или вероятность почти равна нулю).