Перейти к содержанию
    

AVR+SEEPROM+1WIRE+Wegand

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

 

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

Простой поиск ключа в таком обьеме, учитывая что номера будут не подряд к примеру от 1 до 5000, а в разнобой, может занять секунд 15, если кто нибудь делал такое подскажите как лучше реализовать поиск ключа в памяти.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 варе и память исходники есть в верху страницы. Делал я скуд на 30000 пользователей. Для ускорения поиска применил хэшированную поисковую таблицу. Заняла она у меня правда во внешней раме прилично. Зато время поиска 15 мкс. Правда на LPC. Думаю также быстро получится половинным делением. Но все это работает к сожалению только при упорядоченном списке.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

Простой поиск ключа в таком обьеме, учитывая что номера будут не подряд к примеру от 1 до 5000, а в разнобой, может занять секунд 15, если кто нибудь делал такое подскажите как лучше реализовать поиск ключа в памяти.

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

Приветствую Вас уважаемый impuls-v. Сразу извиняюсь за off top.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2 Семён.

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

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

2 vesago

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Смысл в том, чтобы при считывании ключа система расчитывала 2-х байтный хэш ключа, который являлся индексом поисковой таблицы. Попадаем в нужную точку, а там может лежать или развернутый код ключа ну или точка входа в учетную запись дабы проверить ключ и права доступа + ссылка на следующую запись с аналогичным хэшем. Хэшем может служить даже ксор. Скорость такая, что при 30000 пользователях замок быстрее открывается, чем заканчивается короткий писк считывателя. Но повторяю, что это потребует рамы, так как таблица формируется именно в ней. В этом форуме я вел обсуждение этого вопроса некоторое время назад.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

2 vesago

извините, но не очень вериться, что время поиска у Вас всего объема 15 мкс.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2 vesago

извините, но не очень вериться, что время поиска у Вас всего объема 15 мкс.

 

почему-же? насколько я знаю использование хэширования один из самых производительных методов поиска.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2 vesago

извините, но не очень вериться, что время поиска у Вас всего объема 15 мкс.

 

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...