[impuls-v 0]

Попался тут на глаза сломанный прибор от СКД, вот и подумал считыватель вигант есть, даллосовские ключи тоже, память на и2сишную на 10кБайт щас вытащу из прибора.

С ключами и считывателями в принцепе не трудно разобраться, а вот сам вопрос состоит в том что не работал никогда с памятью, а соответственно и с массивом данных, ведь здесь не 10 ключей как в домофоне, а хочется ,чтобы научится работать с такими вещами, забить всю память т.е 1000 ключей.

 

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

 

Принцып я так понимаю такой в памяти хранится 7 байт ключа ( КС 1байт -доп ко кода далласа 3байта-серия 1байт -номер 2байта, 8-мой можно выкинуть - код ключа=01, и 3 байта параметров ключа - ну например срок действия, временное окно и др.

После добавлени ключей таблица сортируется по номеру серии и по номеру ключа, а далее стоит вопрос как будет быстрее если в ЕЕПРОМ сохранить номера серии ключей и соответствующие им диапазон ячеек в памяти и осуществлять поиск по номеру ключа уже внутри этого диапазона адресов памяти т.е. чтото типо хэширования , или просто при считывание ключа сначало ищем в памяти номер серии а потом в найденном диапазоне значений код ключа. Подскажите как все это решить.

 

П.С. Помощь в этом вопросе очень сильна нужна в связи с весенней депресией, или творческий застой - как хотите это называйте, просто какаято апатия ко всему, даже купленнае месяц назад АТ90ЮСБ валяются без дела, сам я просто наврятли в ближайшее время начну проект, а так если будет пример хоть поковыряюсь и дипрессия спадет.

[DogPawlowa 0]

П.С. Помощь в этом вопросе очень сильна нужна в связи с весенней депресией, или творческий застой - как хотите это называйте, просто какаято апатия ко всему, даже купленнае месяц назад АТ90ЮСБ валяются без дела, сам я просто наврятли в ближайшее время начну проект, а так если будет пример хоть поковыряюсь и дипрессия спадет.

А оттого, что Вы напряжете других людей в деле алгоритмизации, депрессия у Вас пройдет? Лучше 200 грамм водки выпить и лечь спать. Или пива :beer: Или к медикам - депрессию должны лечить профессионалы.

Книжку умную про С почитайте - там написано, что к массивам можно обращаться по индексу или по указателю. И тема сортировки там раскрыта полностью.

Успехов

[vesago 0]

Если ключей мало можно тупым перебором. Можно конечно 1000 штук сортировать и потом бинарным поиском, но боюсь долго будет длиться добавление/удаление ключей. Если много ключей - хэш + поисковая таблица. Но это требует прилично срам. 4-х байт достаточно использовать из кода ключа. Если это таблетки, то берутся младшие 4 байта.

[rumit2000 0]

Что бы поиск осуществлялся быстрее - можно память побыстрее выбрать, я использую атмеловскую SPI-ную.

Ещё такой совет, например, применяя далосовские таблеточки, можно заметить, что первые байты у большинства одинаковые, а отличаются они последними, т.е. когда клиент покупает СКУД, он, как правило, в довесок берёт кучу таблеточек, обычно они из одной партии, в которой номера идут по порядку, т.е. инкрементируются. Записываем их в память в любом порядке, без сортировки. Когда появляется необходимость поиска ключа (приложили к контактеру и надо проверить пускать или нет) , запускаем такой алгоритм.

Мы знаем длинну ключа (например 6 байт), знаем что младшие разряды меняются чаще, чем старшие (легко увидеть, если набрать некоторое кол-во таблеточек и поглядеть какими разрядами они отличаются), значит считываем из первого записанного ключа в память младший байт, сравниваем, совпадает - качаем оставшиеся 5, сравниваем, если не совпали - поворяем операцию для следующего ключа. При такой реализации для МК MSP430, 4МГЦ и SPI-ной памяти, 1000-ный ключик ищется 0,5 сек. вполне приемлимое время...

[GDI 0]

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

[rumit2000 0]

... а добавление ключа не так часто производится....

Вынужден внести некоторые поправочки :) Действительно, в процессе работы добавление ключей происходит довольно редко, если не сказать, что практически никогда, однако в процессе установки, монтажник записывает сразу много ключей, обычно с многократным запасом. Например если рассмотреть домофон - посчитайте сколько ключей надо сразу записать... И если ключ будет записыватся значительное время (даже если 2-3 сек.), считаю что это жутко не удобно для монтажника... Кроме того, зачем производить сортировку, если и так 1000-ный ключ ищется меньше секунды..... Конечно если ключей несколько десятков тысяч, то можно задуматся о сортировке, но как правило такие системы заполняются не вручную, а через PC, где произвести сортировку быстрее... а то "руки отвалятся" 10000 ключей прикладывать :)

Однако конечно бывают исключения, у моих родителей поставили домофон, думаю ключей в нём несколько сотен.. и ключек отзывается только через 1-2 секунды, что производит жутко неприятное очучение - лучше бы сделали сортировку :( Думаю они либо жутко медленно с памятью работают, либо алгоритм поиска жутко неоптимальный... Марку щас не вспомню - какой-то не ходовой... первый раз такой увидел...

 

P.S. конечно если в системе будет 100 ключей, то можно и сортировку организовать и что угодно... на время записи и поиска это не сильно повлияет

Изменено 8 июня, 2007 пользователем rumit2000

[GDI 0]

И если ключ будет записыватся значительное время (даже если 2-3 сек.), считаю что это жутко не удобно для монтажника...

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

[rumit2000 0]

...для массового ручного ввода ключей можно предусмотреть и сортировку по требованию или по окончании процедуры добавления ключей...

 

Согласен, тоже вариант...

[adnega 11]

Во время записи:

- оператор начинает сеанс записи;

- последовательно добавляет 1000 ключей в несортированный массив;

- заканчивает сеанс записи, что приводит к сортировке массива.

 

Во время чтения:

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

 

Вот. ;)