Скоростной доступ к SRAM Опции

[vesago]

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

[Evgeny_CD]

Я прошу прощения, что лезу в чужой монастырь со своим уставом. Но при чем тут 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 чип, и адресовать его по странично будете через пины какого-либо порта).