реклама на сайте
подробности

 
 
> AVR+SEEPROM+1WIRE+Wegand, Подмогните алгоритмом
impuls-v
сообщение Nov 12 2006, 22:50
Сообщение #1


Частый гость
**

Группа: Свой
Сообщений: 130
Регистрация: 15-01-06
Пользователь №: 13 190



Поделитесь пожалуйста рабочими примерами работы с iButton по интерфейсу 1WIRE, с проксимити картами по интерфейсу Wegand и работой с памятью по интерфейсу I2c типа 24LCxxx или AT24Cxxx.

В памяти будут хранится коды ключей, вообщето наврятли количество ключей будет больше 200, но память будет на 512к, нужно использовать ее по полной т.е. можно записать до 10000 ключей.
Простой поиск ключа в таком обьеме, учитывая что номера будут не подряд к примеру от 1 до 5000, а в разнобой, может занять секунд 15, если кто нибудь делал такое подскажите как лучше реализовать поиск ключа в памяти.
Мне кажется что после формирования списка ключей лучше всего сделать сортировку, к примеру пузырьковым методом, а поиск осуществлять методом последовательного приближения.
Go to the top of the page
 
+Quote Post
 
Start new topic
Ответов (1 - 9)
vesago
сообщение Nov 13 2006, 07:24
Сообщение #2


Тутэйшы
****

Группа: Свой
Сообщений: 708
Регистрация: 30-11-04
Пользователь №: 1 263



1 варе и память исходники есть в верху страницы. Делал я скуд на 30000 пользователей. Для ускорения поиска применил хэшированную поисковую таблицу. Заняла она у меня правда во внешней раме прилично. Зато время поиска 15 мкс. Правда на LPC. Думаю также быстро получится половинным делением. Но все это работает к сожалению только при упорядоченном списке.
Go to the top of the page
 
+Quote Post
Семён
сообщение Nov 13 2006, 07:37
Сообщение #3


Частый гость
**

Группа: Свой
Сообщений: 196
Регистрация: 19-07-06
Из: Москва
Пользователь №: 18 922



Цитата(impuls-v @ Nov 13 2006, 01:50) *
Поделитесь пожалуйста рабочими примерами работы с iButton по интерфейсу 1WIRE, с проксимити картами по интерфейсу Wegand и работой с памятью по интерфейсу I2c типа 24LCxxx или AT24Cxxx.

В памяти будут хранится коды ключей, вообщето наврятли количество ключей будет больше 200, но память будет на 512к, нужно использовать ее по полной т.е. можно записать до 10000 ключей.
Простой поиск ключа в таком обьеме, учитывая что номера будут не подряд к примеру от 1 до 5000, а в разнобой, может занять секунд 15, если кто нибудь делал такое подскажите как лучше реализовать поиск ключа в памяти.
Мне кажется что после формирования списка ключей лучше всего сделать сортировку, к примеру пузырьковым методом, а поиск осуществлять методом последовательного приближения.

Приветствую Вас уважаемый impuls-v. Сразу извиняюсь за off top.
Вы будете смеяться, но я делаю проект, который полностью подходит под Ваше описание. Самое интересное, что проект не на основной работе, а так сказать левый. Интересно мой удаленный работодатель ищет альтернативы или кто то хочет сделать, что то похожие? Кодом поделиться не могу. Хотя на более общие вопросы могу попробовать ответить.


--------------------
Тяжелое детство - 8-битные игрушки на 8-дюемовых дискетах
Go to the top of the page
 
+Quote Post
impuls-v
сообщение Nov 13 2006, 22:20
Сообщение #4


Частый гость
**

Группа: Свой
Сообщений: 130
Регистрация: 15-01-06
Пользователь №: 13 190



2 Семён.
Да нет просто делаю схему для себя. Делать всякие мелочи уже не интересно, хочется чего то по сложнее и объемнее, а так как работаю сейчас на обслуживании сигнализаций и СКД то соответственно знаком с несколькими, и скажем так ни одна система мне ненравится.
Кроме того проблема в нашем городе в том что невозможно найти работу связанную с микроконтроллерами, да и вообще с разработкой электроники, а этот проект займет на значительное время и вслучае удачной реализации может получится зацепится куданибудь на удаленную разработку.
2 vesago
А как сделать хэшированную поисковую таблицу, я к сожалению с подобным методом не знаком, поделитесь опытом.
Go to the top of the page
 
+Quote Post
vesago
сообщение Nov 14 2006, 08:45
Сообщение #5


Тутэйшы
****

Группа: Свой
Сообщений: 708
Регистрация: 30-11-04
Пользователь №: 1 263



Смысл в том, чтобы при считывании ключа система расчитывала 2-х байтный хэш ключа, который являлся индексом поисковой таблицы. Попадаем в нужную точку, а там может лежать или развернутый код ключа ну или точка входа в учетную запись дабы проверить ключ и права доступа + ссылка на следующую запись с аналогичным хэшем. Хэшем может служить даже ксор. Скорость такая, что при 30000 пользователях замок быстрее открывается, чем заканчивается короткий писк считывателя. Но повторяю, что это потребует рамы, так как таблица формируется именно в ней. В этом форуме я вел обсуждение этого вопроса некоторое время назад.
Go to the top of the page
 
+Quote Post
Семён
сообщение Nov 14 2006, 12:02
Сообщение #6


Частый гость
**

Группа: Свой
Сообщений: 196
Регистрация: 19-07-06
Из: Москва
Пользователь №: 18 922



Здравствуйте impuls-v. Нехочу навязывать своё мнениё, но всеже хочу высказать свой взгляд по этому вопросу. Вы говорите «скажем, так ни одна система мне ненравится». Ваш ответ чисто субъективной, в производстве нельзя создать систему удолитворяющего каждого потребителя, поэтому разработчику всегда приходиться идти на компромисс, что он хочет сделать и что он сможет сделать из ходя из бюджета. Конкретно на Вашем примере можно сказать следующие, что память серии 24CXX хороша исключительно для устройств начального уровня с максимальном хранением кодов до 2000 штук, при более высоком количестве хранимой информации, что бы не испортить другие характеристики устройства нужно использовать другую элементную базу. До 15000 можно использовать память работающею по SPI. Свыше 20000 нужно использовать память с параллельным доступом.
2 vesago
извините, но не очень вериться, что время поиска у Вас всего объема 15 мкс.


--------------------
Тяжелое детство - 8-битные игрушки на 8-дюемовых дискетах
Go to the top of the page
 
+Quote Post
Petka
сообщение Nov 14 2006, 12:27
Сообщение #7


Профессионал
*****

Группа: Свой
Сообщений: 1 453
Регистрация: 23-08-05
Пользователь №: 7 886



Цитата(Семён @ Nov 14 2006, 15:02) *
2 vesago
извините, но не очень вериться, что время поиска у Вас всего объема 15 мкс.


почему-же? насколько я знаю использование хэширования один из самых производительных методов поиска.
Go to the top of the page
 
+Quote Post
vesago
сообщение Nov 14 2006, 12:28
Сообщение #8


Тутэйшы
****

Группа: Свой
Сообщений: 708
Регистрация: 30-11-04
Пользователь №: 1 263



Цитата(Семён @ Nov 14 2006, 16:02) *
2 vesago
извините, но не очень вериться, что время поиска у Вас всего объема 15 мкс.


Я слукавил - 19 smile.gif Сложно сказать - забивал базу всяким мусором, потом через JTAG в отладчике проверял скорость. Более 2-х итераций поиска не встречал. Все зависит, сколько повторяющихся хэшей будет - это зависит от ключей, от алгоритма хэширования. Реально может конечно увеличится, но не принципиально. Честно скажу - у меня заправляет всем LPC2214 60mhz. К нему прикручена праллельно флешка по 32 битной шине и рама тоже параллельно. Чтением занимается периферийная мега, которая толкает код cpu на 115200. Но в любом случае сам метод очень быстрый и не зависит от числа записей. Я его не придумывал - это классика.
Go to the top of the page
 
+Quote Post
Семён
сообщение Nov 14 2006, 12:44
Сообщение #9


Частый гость
**

Группа: Свой
Сообщений: 196
Регистрация: 19-07-06
Из: Москва
Пользователь №: 18 922



Цитата(vesago @ Nov 14 2006, 15:28) *
Я слукавил - 19 smile.gif Сложно сказать - забивал базу всяким мусором, потом через JTAG в отладчике проверял скорость. Более 2-х итераций поиска не встречал. Все зависит, сколько повторяющихся хэшей будет - это зависит от ключей, от алгоритма хэширования. Реально может конечно увеличится, но не принципиально. Честно скажу - у меня заправляет всем LPC2214 60mhz. К нему прикручена праллельно флешка по 32 битной шине и рама тоже параллельно. Чтением занимается периферийная мега, которая толкает код cpu на 115200. Но в любом случае сам метод очень быстрый и не зависит от числа записей. Я его не придумывал - это классика.

Вопрос конечно не корректный, но всеже, сколько вся эта «музыка» в конечном варианте стоит. Хотя я и понимаю, что 30000 уже не маленькая СКД


--------------------
Тяжелое детство - 8-битные игрушки на 8-дюемовых дискетах
Go to the top of the page
 
+Quote Post
vesago
сообщение Nov 14 2006, 14:24
Сообщение #10


Тутэйшы
****

Группа: Свой
Сообщений: 708
Регистрация: 30-11-04
Пользователь №: 1 263



Недешево она по себестоимости выходит, хотя несравнимо дешевле буржуинских. Потянул арм и память. Но что поделать, редко, но иногда надо стока народу обрабатывать. Но в общем работой я доволен. Изюминка - единая база данных во всех контроллерах. Если что, из любого выкачивай. Даже сигнатуры все лежат в базе. Событий как минимум 300000. Правда на закачку всей базы - а она 4 метра, минут 20 надо. В перспективе хочу забацать головной контроллер, который синхронизировать базу будет. В общем среди систем до тысченки другой народу, конкуренции не выдержит.
Go to the top of the page
 
+Quote Post

Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 28th July 2025 - 09:03
Рейтинг@Mail.ru


Страница сгенерированна за 0.01431 секунд с 7
ELECTRONIX ©2004-2016