impuls-v 0 5 июня, 2007 Опубликовано 5 июня, 2007 · Жалоба Попался тут на глаза сломанный прибор от СКД, вот и подумал считыватель вигант есть, даллосовские ключи тоже, память на и2сишную на 10кБайт щас вытащу из прибора. С ключами и считывателями в принцепе не трудно разобраться, а вот сам вопрос состоит в том что не работал никогда с памятью, а соответственно и с массивом данных, ведь здесь не 10 ключей как в домофоне, а хочется ,чтобы научится работать с такими вещами, забить всю память т.е 1000 ключей. Подскажите пожалуйста, если ктонибудь реализовывал плдобное, как лучше осушествлять поиск, сортировку, хранение, а еще лучше помогите примером,если не жалко конечно. Принцып я так понимаю такой в памяти хранится 7 байт ключа ( КС 1байт -доп ко кода далласа 3байта-серия 1байт -номер 2байта, 8-мой можно выкинуть - код ключа=01, и 3 байта параметров ключа - ну например срок действия, временное окно и др. После добавлени ключей таблица сортируется по номеру серии и по номеру ключа, а далее стоит вопрос как будет быстрее если в ЕЕПРОМ сохранить номера серии ключей и соответствующие им диапазон ячеек в памяти и осуществлять поиск по номеру ключа уже внутри этого диапазона адресов памяти т.е. чтото типо хэширования , или просто при считывание ключа сначало ищем в памяти номер серии а потом в найденном диапазоне значений код ключа. Подскажите как все это решить. П.С. Помощь в этом вопросе очень сильна нужна в связи с весенней депресией, или творческий застой - как хотите это называйте, просто какаято апатия ко всему, даже купленнае месяц назад АТ90ЮСБ валяются без дела, сам я просто наврятли в ближайшее время начну проект, а так если будет пример хоть поковыряюсь и дипрессия спадет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
DogPawlowa 0 5 июня, 2007 Опубликовано 5 июня, 2007 · Жалоба П.С. Помощь в этом вопросе очень сильна нужна в связи с весенней депресией, или творческий застой - как хотите это называйте, просто какаято апатия ко всему, даже купленнае месяц назад АТ90ЮСБ валяются без дела, сам я просто наврятли в ближайшее время начну проект, а так если будет пример хоть поковыряюсь и дипрессия спадет. А оттого, что Вы напряжете других людей в деле алгоритмизации, депрессия у Вас пройдет? Лучше 200 грамм водки выпить и лечь спать. Или пива :beer: Или к медикам - депрессию должны лечить профессионалы. Книжку умную про С почитайте - там написано, что к массивам можно обращаться по индексу или по указателю. И тема сортировки там раскрыта полностью. Успехов Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
vesago 0 7 июня, 2007 Опубликовано 7 июня, 2007 · Жалоба Если ключей мало можно тупым перебором. Можно конечно 1000 штук сортировать и потом бинарным поиском, но боюсь долго будет длиться добавление/удаление ключей. Если много ключей - хэш + поисковая таблица. Но это требует прилично срам. 4-х байт достаточно использовать из кода ключа. Если это таблетки, то берутся младшие 4 байта. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rumit2000 0 7 июня, 2007 Опубликовано 7 июня, 2007 · Жалоба Что бы поиск осуществлялся быстрее - можно память побыстрее выбрать, я использую атмеловскую SPI-ную. Ещё такой совет, например, применяя далосовские таблеточки, можно заметить, что первые байты у большинства одинаковые, а отличаются они последними, т.е. когда клиент покупает СКУД, он, как правило, в довесок берёт кучу таблеточек, обычно они из одной партии, в которой номера идут по порядку, т.е. инкрементируются. Записываем их в память в любом порядке, без сортировки. Когда появляется необходимость поиска ключа (приложили к контактеру и надо проверить пускать или нет) , запускаем такой алгоритм. Мы знаем длинну ключа (например 6 байт), знаем что младшие разряды меняются чаще, чем старшие (легко увидеть, если набрать некоторое кол-во таблеточек и поглядеть какими разрядами они отличаются), значит считываем из первого записанного ключа в память младший байт, сравниваем, совпадает - качаем оставшиеся 5, сравниваем, если не совпали - поворяем операцию для следующего ключа. При такой реализации для МК MSP430, 4МГЦ и SPI-ной памяти, 1000-ный ключик ищется 0,5 сек. вполне приемлимое время... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
GDI 0 7 июня, 2007 Опубликовано 7 июня, 2007 · Жалоба почему бы не сортировать ключи во время операции добавленя нового ключа, т.е. при добавлении нового ключа производить сортировку всех и перезаписывать новый массив в память, зато потом по отсортированному массиву быстро искать, а добавление ключа не так часто производится. при удалении тоже проводить пересортировку. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rumit2000 0 8 июня, 2007 Опубликовано 8 июня, 2007 (изменено) · Жалоба ... а добавление ключа не так часто производится.... Вынужден внести некоторые поправочки :) Действительно, в процессе работы добавление ключей происходит довольно редко, если не сказать, что практически никогда, однако в процессе установки, монтажник записывает сразу много ключей, обычно с многократным запасом. Например если рассмотреть домофон - посчитайте сколько ключей надо сразу записать... И если ключ будет записыватся значительное время (даже если 2-3 сек.), считаю что это жутко не удобно для монтажника... Кроме того, зачем производить сортировку, если и так 1000-ный ключ ищется меньше секунды..... Конечно если ключей несколько десятков тысяч, то можно задуматся о сортировке, но как правило такие системы заполняются не вручную, а через PC, где произвести сортировку быстрее... а то "руки отвалятся" 10000 ключей прикладывать :) Однако конечно бывают исключения, у моих родителей поставили домофон, думаю ключей в нём несколько сотен.. и ключек отзывается только через 1-2 секунды, что производит жутко неприятное очучение - лучше бы сделали сортировку :( Думаю они либо жутко медленно с памятью работают, либо алгоритм поиска жутко неоптимальный... Марку щас не вспомню - какой-то не ходовой... первый раз такой увидел... P.S. конечно если в системе будет 100 ключей, то можно и сортировку организовать и что угодно... на время записи и поиска это не сильно повлияет Изменено 8 июня, 2007 пользователем rumit2000 Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
GDI 0 8 июня, 2007 Опубликовано 8 июня, 2007 · Жалоба И если ключ будет записыватся значительное время (даже если 2-3 сек.), считаю что это жутко не удобно для монтажника... Не знаю как работают монтажники, но имхо, чаще раза в 2 секунды он тоже не сможет прикладывать, а для массового ручного ввода ключей можно предусмотреть и сортировку по требованию или по окончании процедуры добавления ключей. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rumit2000 0 8 июня, 2007 Опубликовано 8 июня, 2007 · Жалоба ...для массового ручного ввода ключей можно предусмотреть и сортировку по требованию или по окончании процедуры добавления ключей... Согласен, тоже вариант... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
adnega 11 8 июня, 2007 Опубликовано 8 июня, 2007 · Жалоба Во время записи: - оператор начинает сеанс записи; - последовательно добавляет 1000 ключей в несортированный массив; - заканчивает сеанс записи, что приводит к сортировке массива. Во время чтения: - таблеточный протокол последовательный, поэтому с приходом нового бита мона уже начинать поиск, а не ждать когда все биту зальюца... Вот. ;) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться