Проектирую устройство на атмеге128 - контроллер доступа на 30000 пользователей. Требуется прицепить к ней 4 мегабайта рамы для хранения базы данных и журнала. База данных представляет разделы с однородной информацией - учетные записи, настройки. Хочу спросить совета как прицепить срам, чтоб доступ побыстрее был. Мне понравилась мысль через плис. Одой командой записи можно загрузить базовый адрес (по але 2 байта старших по вр младший), а далее по каждому обращению плис будет инкрементировать адрес. Или еще лучьше - пожертвовать несколькими ногами для загрузки предустановленного в плисине базового адреса. Или все это фигня и атмега на 16 мгц и без плисы - оперируя банками шустро будет с памятью работать. С памятью в основном надо будет поиск осуществлять. Мне важно, чтоб человек приложил ключ и система отработала не более чем за 1 сек.

Хм, "Исскуство программирования" том, который "Сортировка и поиск", "Бинарный поиск" -> log2(30000)=15 обращений к базе для сравнения? О какой плисине может идти речь????

Я прошу прощения, что лезу в чужой монастырь со своим уставом. Но при чем тут mega128? Не проще ли LPC22xx поставить? И взять для отладки вот эту плату, например
http://www.olimex.com/dev/lpc-h2214.html - стоит баксов 80
http://www.olimex.com/dev/lpc-e2214.html - баксов 150.

Коме того, какое у Вас заложено время транзакции? 100мс? Так не проще ли весь массив данных в DATA FLASH хранить? Взять 642 (8 мбайт - и записями фисированой длины, как раз 256 байт на юзера получится). А в другом дата флеше - журнал.

4 мбайта статики - они и денег будут стоить, и данные как-то надо хранить при пропадании питания.

А что касается индекса - сделать из номера ключа хеш на 2 байта
(об этом хорошо написано здесь)
http://www.gnu.org/software/gperf/
http://electronix.ru/forum/index.php?showt...=11216&hl=gperf

Для совпадающих хешей - хранить несколько одинаковых записей подряд, и по очереди просматривать их. Ну и бинарное дерево какое-нибудь сгородить для поиска. Тогда, если постараться, 128 или 256 к памяти хватит (а это 1 чип, и адресовать его по странично будете через пины какого-либо порта).

IMHO для такой задачи в идеале лучше подойдет ARM, а еще лучше промышленный 386 (потому что сейчас у Вас 30000 пользователей, а завтра может быть 1млн).
Я бы прилепил память банково, так как выигрыш от плиса будет мизерным. Доступ к банкам вел бы через окно в адресном пространстве МК 8000h-FFFFh, а младшие 32k (0..7FFF) сделал бы всегда постоянными окном для размещения стека, хранения всевозможных флагов и т.п. Операцию смены банка старался бы минимизировать, в худшем случае получил бы 8-10 тактов на считывание/запись произвольной ячейки SRAM. В лучшем случае - стандартных 3.

Спаибо за ответы! Есть над чем подумать. Сегодня на Телесистемах тоже обсуждал сию проблему. Кстати там также упоминалось бинарное дерево и формула с логарифмом. Все бы отлично, но у меня не только ключи, но еще уровни доступа, расписания и прочее. Учетная запись занимает 100 байт. Допустим ключи можно держать отдельно. При поиске местоположение ключа является индексом учетной записи. Переходим туда, тама маска уровней доступа. Их 256. Проверяем каждый уровень доступа. В нем расписания - когда можно ходить когда нет. Короче по раме надо лазить. Пришел я к неутешительному выводу, что на АРМ + SDRAM делать надо. Дешевше выйдет и скорость приличная. Я конечно попытаюсь соптимизировать данные, но видно это приговор. Вся беда в том, что мощнее 8252 не пользовал. Пишу правда на си, но 32 бита и 8 бит как пропасть. Посомтрел в соседнем разделе про армы обсуждается проектец. Там AT91RM9200. С виду понравилась машинка. Стоит у нас 18$ + 4$ SDRAM (сам еще не смотрел - говорят). Вот тока может сложная неподъемно.

Это хороший выбор!

1. Если есть такая возможность, купите
http://www.ucrouter.ru/hardware.html EVM9200
350, зато готовый Linux стоит. Это избавит Вас на первых порах от необходимости заниматься драйверами делеза, и Вы с можете написать свою софтину, работая только с файловой системой и СОМ портом (полагаю, продавцы при необходимости Вас проконсультируют). С Вы знаете, книжек по программированию под Линух полно - Вам ведь особой крутизны не надо - памяти много, считали все в память по старту - и тусуетесь по массиву. Кайф варианта в том, что включил - и работает!

2. Потом переползете на самопальную плату типа
http://electronix.ru/forum/index.php?showtopic=11272
http://electronix.ru/forum/index.php?showtopic=11654

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

Это не беда, уверен что Вы быстро освоитесь. 32-х битная архитектура на самом деле как для программиста гораздо более прозрачная и удобная. AT91RM9200 хороший камень, только сложно найти starter kit под него, а так в кустарных условиях его не запаяешь.. доступен чаще в 256-ball BGA, реже в 208-lead PQFP корпусах... Потренеруйтесь на AT91SAM7Sxx либо LPC21xx.



надо же, пока писал предыдущий пост, уже и плату нашли.. ;>

Кит к сожалению в данный момент не куплю. Буду сразу схему рисовать и отлаживать на готовом устройстве. Погано, а делать нечего. Дайте совет - без линукса и других осей можно пользовать эту машинку или неподъемно? И еще в соем любимом кейле не нашел этот камень. IAR или Кроссворкс? акой из них?

Так купите плату за 600р!
http://electronix.ru/forum/index.php?showtopic=11654
Хоть немного экономьте свои силы!!!

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

Посмотрите на AT91M40800 - адресует до 64Mb, паять проще, стоит дешевле, поддерживается keil'ом.

PS: Если самому собирать, то я бы все-таки рекомендовал ARM7 с бортовым флешем, вместо ARM9 без оного.

Я вообше то не ратую за аваризацию всей электронной промышленности , но то что вы собираетесь сделать можно споокойно разместитьна авр-е причем операция поиска учетной записи будет намного быстрее чем одна секунда . Конечно микро с линейным адресом больше чем 300к* 100 ~ 30 мегабайтов даст вам преимушество оперировать напрямую со структурами данных в языке С.

Есть неясности такие как - где вы собираетесь хранить даннные ? То есть должна быть энергонезависимая память . На флеше ? На хардиске ? На хост ПС ? Все это собираетесь переписывать в память при начальной загрузке ? Или конструируемое устройство должно перманентно содержать эти данные? Будет ли список обновляться (стирание и добавление новых учетных записей)? Если да то , то какое устройство за это в ответе (хост или микрокотроллер )?

Возможные реализации этого дела :
а. Большая статическая или динамическая память с 32 битным процессором позволяюшая напрямую оперировать с данными с использованием С, которая избавит вас от некоторых трудностей
б. любой микро со страничной ОЗУ или флешем или харддиском , где данные размешены в соответствии с вашей реализацией
в. любой микро со страничной ОЗУ или флшем или харддиском где данные размешены на основе готового протокола или стандарта . Допустм фат32.

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

Для варианта б есть несколько ухишрений чтобы облегчить вам жизнь :
Основной алгоритм сортировки и поиска должен оперировать с линейным виртуальным указателем или указателями учетных записей базы данных. А для доступа будете делать
отдельную API работаюшую с этими указателями так что основной алгоритм поиска выбора учетной записи и оперирование с ней на логическом уровне не будет вдаваться в то как хранение данных реализовано.
Для варианта в хранение будет в виде файла или файлов где за работу упорядочения данных будет отвечать драйвер fat32 или какой либо другой стандарт.

Если бюджет проекта позволяет - то вперед за готовой платой арм с линуксом или что то подобное . Для вас там все почти что готово .
Если же нет то варианты б и в не очень трудны . Требования вашего проекта неизвестны мне (вопросы наверху) поэтому могу быть и неправ. Думаю что лучше использовать флеш . С подключением трудностей нет . Предполагаю что скорость работы при правильном выборе алгоритма намного меньше чем секунда . Энергонезависимая память. Емкость памяти увеличивается легким движением руки) 128 МБ не должен стоить много . А если использовать еше MMC или SD карту варианты то в инете уже почти все есть .

Удачи

Я сам перешел с АВР на АРМ, использовал именно AT91RM9200. Есть, конечно, непривычные моменты - совершенно другая архитектура, обилие регистров периферии и немного другое принцип работы с ними и т.п. Но неопдъемно - это млишком пессимистично . Вполне можно разобраться, почитав про архитектуру АРМов и изучив даташит на контроллер (плюс ерата). В конечном счете начинает казаться, что это не на много сложнее АВР, но по возможностям, конечно, на две головы выше.


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

Абсолютно согласен .

Вполне подъемно, хотя придется повозиться с железом на низком уровне - инициализация камня и периферии, загрузка прошивки и т.д. Из сред могу посоветовать CrossWorks. IAR, может быть, лучше (по крайней мере я бы пользовался им), но он не работает с дешевым JTAG-адаптером Wiggler. Если будет нужно - могу скинуть для CrossWorks шаблон проекта, так как в родной поставке шаблонов для этого камня тоже, увы, нет.

Ну почему же? Главное - разобраться с загрузчиком, а после этого процесс написания и отладки приложения пойдет даже проще, чем на АВР.

Скинте, пожалуйста шаблончик проекта на vesago(at)ramble.ru. Посмотрев, что в кейле нет этого камня (странно) я качнул Кроссворкс. Я правда еще не решил точно какой камень брать. Нравится LPC2214, но хотелось бы SDRAM прикрутить, тогда придется на плисине контроллер делать - тоже не есть гуд. А плата ваша обалденная, жаль под мой проект не подходит.

Ок, сегодня или завтра (вечером) скину.

Мда,... диспут немного кривовато пошел, так что попробуем внести коррекцию. Прежде всего надо считать. Считать временные характеристики проектируемой системы в зависимости от поставленной задачи. SRAM всегда являлось статической памятью (http://www.citforum.ru/book/optimize/sdram.shtml) быстродействие работы с которой определяется ее техническими характеристиками (время доступа к кристаллу). Как правило большинство микроконтроллеров и микропроцессоров обладают большим (много большим) быстродействием работы шины для чтения/записи SRAM. Отсюда делаем вывод, что необходимо учитывать для реализации максимально 'скоростного доступа к SRAM'. Но необходимо помнить еще одно обстоятельство, что SRAM на предельно допустимых скоростях будет работать нестабильно (давать сбои), как и другие электронные компаненты. Если выполнять программные поиска (по базе) атмеге128 будет вполне достаточно. Но если процессор параллельно задействован для выполнения сложных и рутинных алгоритмов необходимо конечно обратить свой взор на ARM.

Хочу еще добавить, что SRAM стоит намного дороже SDRAM.

Вообще, я согласен с одним из вариантов, предложенных _artem_:
Взаимодействовать с винтом несложно, уже реализована разбивка по секторам (даже избыточного размера - пригодится если структура записей расширится). А можно взять CompactFlash - интерфейс практически такой же, как у винта, но размеры и энергопотребление намного приятнее. Скорость считывания при этом будет достаточно высокой, что бы не было визуальных тормозов.

Флэш боюсь долго не проживет. Надо журнал писать - несколько тысяч событий ежедневно.

Ну и что из этого? Большой кольцевой буфер. Чем он больше - тем реже перезапись. 100к циклов любой флеш держит. Пусть 128к в день - при 8Мбайт это 64 дня длина буфера * 100к - у Вы сами столько проживете?

Только не надо делать FAT!!! Ссылочную структуру. В конце каждого блока - указатель на следующий.

При старте сканируем все блоки и находим последний (ну и пусть загрузка займет 1 минуту - это страшно?)
Или это смотрим
http://www.caxapa.ru/echo/arm.html?id=48631

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

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

Таким образом, мы от AVR дружно пришли к промПЫсюку.
А что? (хоть я и терпеть не могу x86)

1. Берем
http://www.ipc2u.ru/catalog/U/U2/20603.html - 171$

2. Берем к нему IDE FLASH модуль мегов на 16 - он всего ничего стоит. Можно и на винче со свалки поработать.

3. Качаем Линух
http://www.dmp.com.tw/tech/os-xlinux/

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

4. Быстренько пишем апликуху.

Ндя... вот поэтому и живут x86, чтоб их...

Человек сейчас скажет, что мол не по бюджету все это, я лучше сам проводками спаяю. На этот случай можно взять на той же свалке, где и винч, 386 борду, и ISA Ethernet карточку на RTL8019 (что я пишу ). А когда устройство заработает, его можно перенести на промПЫсю. Если к тому моменту не найдется 200$ - это уже клиника. (производство своих плат в малых тиражах будет дороже.)

MMC, CompactFlash - 100k записей на сектор. Правильно говорит Evgeny_CD 64 дня * 100k. Ведь каждый день можно работать (записывать) с новыми секторами. По чтению ресурс этих носителей - 40 лет.

> vesago

Как вам такой вариант (ядро 386sx):
http://www.gensw.com/pages/prod/bios/chipsets/m6117.htm
есть много готовых плат на этом чипе...



Вы всегда меня опережаете на 1 шаг!
Respect!

http://www.m6117.com/ - тут лучше описано!


Не ставил свой целью. Все равно с этого форума я знаний беру гораздо больше, чем отдаю.

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

А разве все 3000 операций будут приходится на одну и ту же ячейку ? Если вы собираетесь делать систему допуска интегрированную с бесконтактными датчиками и регистрацией входов выходов то навряд ли вам придется делать несколько тысяч записей на ячейку памяти в карте . Для логирования входов выходов отведите место в ОЗУ и записывайте данные туда, а два раза в день перепишите все это на карту . Учетные же записи можно оперировать через карту памяти напрямую .

Или же для регистрации событий можно использовать подход Евгения . Кстати у атмела есть аппликуха на это применительная для еепрома, но можете этот принцип и для флеша использовать.

Сама запись наверно будет типа - номер пользователя , номер датчика , время, день и еше чтото . Но длина записи будет постоянна . Для обрашения к записи напрямую вам будет надобен указатель , который и будет под большой нагрузкой . Так его можно и в ОЗУ держать . А если в устройстве будет баг то для восстановления можно -
установите адрес этого указателя фиксированно в памяти ОЗУ. Затем в low level init до того как инициализация будет делаться считайте этот адрес напрямую (если внешнее ОЗУ прицепите то можно батарейку использовать для сохранения этих данных). Ну а в случае если значение этой ячейки нарушилось - то пройдитесь по всем записям и сверяйте день и время чтобы выявить самую свежую запись лога .

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

defunct
Нормальное решение с ПЛИС.
Нечто подобное реализовали, именно на (128Mega или AT91RM9200) + FPGA + SRAM.
В такой конфигурации Mega + FPGA + SRAM оказалась симпотичней.
В SRAM структура, которую туда грузит Mega. Mega общается с SRAM через FPGA через окно.
В FPGA реализован автомат бинарного поиска. Управляет автоматом Mega. Логирование - через SPI Flash.
З.Ы. Можно конечно и SDRAM прикретить - будет дешевле, но понять как работает контроллер SDRAM чуть сложнее.
З.З.Ы В FPGA можно реализовать высокоскоростной автомат логирования в Flash.
З.З.З.Ы А ногами махать (аля 1-Wire) Megа всётаки удобней, чем AT91RM9200 .

А если из ATmega48 сделать "SPI сопроцессор" для махания ногами, который будет управляться от AT91RM9200? У него этих SPI - 4 штуки.

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

Ограничения:
Поскольку изначально планировалось работа с базой в ОП, то мной рассмотрен только случай когда все основные операции над базой select/update/insert/delete выполняются только над отображением базы в ОП, а задачей флеш-носителя будет только хранение базы. При такой постановке задачи возможны два варианта использования всегда "новых" секторов флеш носителя.

Реализация:
1. флеш хранилище организовать в виде линейного или кольцевого буфера в котором хранить данные инициализации и далее все действия произведенные над базой, соответственно "новые" записи просто добавлять в "новые" сектора. При старте устройства, все "непустые" сектора последовательно читать, и производить формирование базы в ОП (т.е. при каждом старте системы, выполнять все модификации всех полей с момента работы системы, получится "долгий старт").

2. Выполнять полное сохранение базы из оперативной памяти в новую область флеш, при этом в начале базы указывать сколько секторов она занимает. Т.о. естественным путем образуется цепочка схожая с MCB-DOS, и при старте очень легко можно будет найти и прочитать базу. флеш использовать лишь только для начальной загрузки данных в случае сброса(включения) устройства. (такой подход требует наличия аккумулятора в устройстве для аварийной записи базы на флеш носитель в случае отключение питания). Зато если сохранение базы выполнять 1 раз в день, то теоретически время работы флеша будет чутли не 100k * (Объем флеша / Объем базы) дней . Наверное, придется выполнять еще и регенерацию флеш, раз в 30 лет. Хехе

Оба варианта имеют жуткие минусы, но зато, надеюсь, отвечают на Ваш вопрос.

PS: всерьез мой утренний маразм не воспринимать, хотя если кто хочет такое сделать - пожалуйста

Ну не знаю, не знаю.. Я бы использовал просто дополнительный порт для адресации выше 64k и добавил бы один элемент 8ИЛИ, данные хеш таблицы хранил бы в фиксированном окне, эффект по скорости думаю был бы сравнимый, зато железо было бы однозначно дешевле (-ПЛИС который стоит как mega128, а то и больше).

Спасибо большое за советы. Много ценных идей - еще буду переваривать. В общем я похоже определился. Задача моя решаема на атмеге128 в основном с флешевой памятью. Однако крайне мне понравился lpc2214. Стоит сей камень не существенно больше атмеги. Зато есть простор мысли. И самое главное можно писать в горячо любимом мной кейле. Пристрастился я к нему при работе с 51. Еще расскажу суть задачи. Сетевой контроллер СКУД на 30000 пользователей 4 двери для учебного заведения. Принимается ключ в формате точмемори и если хватит времени в вейганде. Имеется макс. 256 уровней доступа - структура, которая содержит информацию в какие из 4 дверей можно ходить и расписания. Расписаний может быть макс. 256 - 4 недели 4 задаваемых пользователем интервала в сутки. При считвании ключа он ищется в базе. При нахождении получаем индекс на учетную запись в ней просамтриваем уровни доступа. Проверяем разрешен ли доступ для данного контроллера для данной двери и в данный период времени. Если все ок - разблокируем дверь. Всети максимум 127 контроллеров. В общем базу я буду во флеше хранить. При запуске контроллера он сольет все ключи в небольшую внешнюю срам и отсортирует их для бинарного поиска и добавит к каждому 4х байтному ключу адрес учетной записи. При считывании ключ моментом найдется, а далее дело техники. Можно на атмеге сделать, но что-то понравились мне армы. И проше мне кажется на нем сделать будет. Единственное не могу определится в датафлеше хранить или с параллельным доступом. Датафлеш же 20 мгц не вытянет? Читал вроде дай бог 10. За сколько 1 к с нее сольется в кэш?
Еще не решил с журналом. Толи действительно во флеше хранить, а указатели в часах (FRAM). Или в тойже срам с батарейкой. В общем если можно - прокоментируйте.

Интересная задача!
Хм а как вам такой подход:
Прикручиваем в Mege или к LPC Ethernet (RTL8019 или CS8900 включаем прямо в адресное контроллера), базу храним на обычном PC в какой-нить стандартной СУБД, оснавная обрабатывающая программа на PC. Контроллер считывает ключ, по ethernet отправляет запрос на PC, ему приходит ответ отпереть или не отпирать, и собсно все.. На случай если PC недоступен, то во внутреннем флеше контроллера хранить несколько Master ключей, которые в любое время могут отпереть двери.

Честно говоря мне надо, чтоб в апреле девайс уже функционировал. Поэтому об изернетах я не заикаюсь. Однозначно не разберусь за такое время с подобными высокими технологиями. Я тоже сначала предложил базу и логику держать на компе. Благо опыт создания такого имеется. За 3 недели склепали доступ на автостоянку. Но тут такой вариант решительно был отметен. Мало-ли комп сляжет, база затрется. Не надежно. Вы можете привести кучу аргументов опровержения. Но из опыта автостоянки я однозначно знаяю, что такие системы проблемные. Хотел у народа спросить LPC - дружественные к пользователю? У атмеги и вообще продукции Атмела хорошее свойство - как написано так и работает. Нет неоднозначных моментов. В общем для неискушенного пользователя не страшны.

Понял..


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

Спасибо, сильно вы меня обнадежили. Весь инструментарий я уже приготовил - слил кейл, тулзу, литературу. Засяду изучать. Как понял кейл с виглером не работает поэтому как появятся лишние 70 уев прикуплю мт-линк. Зато у кейла симулятор что надо. Кабы они еще авры прикрутили, цены бы кейлу не было. Хотел еще спросить - сколько раз датафлэш стирать можно и реально ли она на 20 мгц может работать (у lpc ж надеюсь можно по spi такую скорость дать)?

Я не принимаю в серьез, как Вы и просили, но все же хочу указать на один самый существенный недостаток этих вариантов: они предполагают хранение базы в ОП, что выйдет очень дорого при использовании SRAM . К тому же подход "загрузка из флэш - работа - выгрузка во флэш" чревата потерей накопленных в процессе работы данных в случае сбоя.

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


Количество перезаписи - 100 000, на 20 МГц точно не знаю, но на 18 работает прекрасно .

Еще один момент - поставьте на пиатние БОЛЬШОЙ кондер, до стабилизатора. И nPOWER_GOOD организуйте. Чтобы если !POWER_GOOD - то начинать запись во флешак. else - не начинать. Если запас от POWER_GOOD == TRUE до nRESET от ресеттера будет 1 секунду - то у Вас точно не будет проблем с флешаком, и система будет очень "дуракоупорной" - далее все на Вашей программистской совести.

Лучше все-таки DATA FLASH. Тогда на внешней шине будет только SRAM - 1мбайт, при продуманной алгоритмике хватит за глаза (а это 2 чипа, и как раз 32 битный доступ будет, более того, готовые "макетки" от Olimex (тут ими MT-System и Терраэлектроника торгуют) имеют такой же объем памяти). IMHO, начать лучше с этих макеток, а DATA FLASH прикрутить на отдельной платке.

Есть народ, который разводил LPC22xx + SRAM на двухслойной плате. Утверждается, что даже работает на максимальной частоте шины. Хоть я и не любитель подобных решений, но после обсуждения
http://electronix.ru/forum/index.php?showtopic=11272
вынужнен признать, что, возможно, моя точка зрения устарела.

Для того, чтобы не потерять накопленное за день можно поставить небольшую FRAM. Я не предлагаю FRAM вместо FLASH - это наверное будет дороже. Но для фрам можно не считать циклы перезаписи. Там-же можно хранить часть структуры, которая часто меняется.

Хочу еще пояснить - база будет во флеше храниться. Ключи и все остальное. Только при запуске из базы в срам буду переписваться ключи для сортировки - типа код принятого ключа - индекс. Тогда я смогу моментом определять - есть ли подобный ключ в базе или нет и если есть получать адрес учетной записи. Для этих целей хватит 30000*8 = 240000 байт. Сбои могут быть при программировании. Когда по сети шлются блоки данных, которые должны быть записаны во флеш. Я решил не гемориться, а организовать прямой доступ к памяти в отношении верхнего уровня. То есть контроллер не будет разбираться что заданные шлются. Он просто будет ложить данные по указанному адресу. Ну и плевать на сбои. В конце проверится - если контрольная сумма не сошлась - повторим. Хочу посоветоваться - хотел параллельную флешку от амд поставить, но у нее 64к размер сектора. Трудно при изменении небольшого участка базы - придется все 64 к копировать в буфер, менять и закатывать образ назад. Датафлеш в этом отношении удобнее. Однако 18 мгц - это достаточно?

Я указатели и счетчики проходов намерен держать в рамтроновских часах с 32к фрама на борту. Еше - как датафлеш в работе? А то сейчас на телесистемах в одном посту утверждается, что кривовата продукция атмела в этом отношении.

vesago
Интересно моментом - это сколько времени для поиска?
Если база задаётся один раз - то может быть и пройдёт (и то не факт.)
А если пользователди меняются, кто будет базу переупорядочивать?
А времянки по TM кто выдерживать будет?
Я лично упёрся уже на 2000 пользователей и 4 двери с журналированием событий.
Подумайте о структуре ключей, записей журнала - от этого серёзно будет зависеть скорость.

Я посчитал - при 10мгц 1к в кэш будет сливаться за 0.8 млс - это примерно чуть болше одного расписания. Думаю на LPC эти данные обработаются мгновенно. Поиск ключа про отсортированном массиве ключей тоже мгновенный. Ключи читать я думаю действительно атмегой 48. LPC их будет забирать у нее из буфера. Да если и LPC задействовать я все эти дела намерян между считываниями делать. Это конечо все на словах хорошо. На практике может дальше 1000 дело не пойдет. Тогда порежу базу, упрощу как смогу, чтоб подогнать к количеству.

Dlya poiska i vnesenija luchshe podoydet hash encoding. Chto vam nuzno budet :
a. uchetnaja zapis budet lineyno raspolagatsja zanimaja fiksirovannuju pamyat vo flashe
b. Budet massiv s ukazatelyami na lineyniye zapisi v punkte a.
index massiva budet raven rezultatu hash funkcii .
c. Dlja predotvrashenija kollizij ispolzuyte linked list s ukazatelyami vnutri zapisey v punkte a.

Prostoy dostup :

- poluchaete znachenie id bytes rfid'a
- vychilyaete hash funkciyu po etim baytam
- ispolzuete massiv v punkte b dlya poluchenija ukazatelja k pervoy zapisi
- vybiraete etu zapis i proveryaete bayti s RFID'a s baytami v zapisi . Esli
est kolliziya to v zapisi budet ukazatel na sleduyusuyu zapis v liste kolliziy .

Esli hash funkciya normalno podobrana , v bolsinstve sluchaev vy smozete dobratsya k zapisi bez kolliziy (s pervoy popitki) ili so vtoroy ili tretyey .
A na eto bolsogo vremeni ne trebuetsja .

zapis novogo polzovatelya budet proizvoditsya tak :
a. vvodite bayti s RFIDa
b. vichislyaete hash funkciyu
c. ispolzuete ee kak index v massive ukazateley k zapisyam
d. Esli yacheyka massiva ne pustaya to polucvhaete index k pervoy zapisi (kotoraya yavlyaetsya pervym chlenom linked list'a) i proxiodite po vsemu linked listu kolliziy do poslednego ee zvena . Isete pustuyu strukturu zapisi i ispolzuya ee index prikreplyaete ee k poslednemu zvenu linked lista colliziy.
Esli yacheyka massiva pustaya isete pustuyu strukturu zapisi naxodite ee index i zapisivaete v massiv ukazateley .

xotya smotritsya emko na samom dele kod vypolnyayetsya ochen bystro . V inete ochen mnogo gotovogo koda dlya hash. Kstati , v bolsix databazax hash primenyayetsya vovsyu .

Samoe glavnoe pravilniy vibor hyash funkcii s naimensim kolichestvom kolliziy. Rezultatom hash funkcii dolzno bit chilo v predelax ot 0 do 300000 - 1 .privedennyj rezultat mozno vzyat modul ot 32 bitnogo chisla delenniy na 300000.

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

Поясните пожалуйста как избавляться от коллизий. Не совсем понял.

example implementation :
http://burtleburtle.net/bob/c/hashtab.c
http://burtleburtle.net/bob/hash/hashtab.html

glavnaya stranica :
http://burtleburtle.net/bob/hash/

Есть плюсы и есть минусы и при использовании винчестера. Плюсы Вы уже назвали, а минусы:
1. Относительно большие размеры и вес..
2. довольно мощный источник питания.
3. Постоянный шум.
4. Хрупкость носителя.
5. Низкие тепературные пределы.

Мы там где могли заменили винчестеры на DiskOnChip носители из-за вышеприведенных недостатков систем с винчестверами.

Думаю, пункты 3-5 несущественны в данном случае. А первые два большей частью решаются применением винчестера от ноутбуков.