Проектирую устройство на атмеге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.