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

[vesago]

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

[Rst7]

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

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

[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 чип, и адресовать его по странично будете через пины какого-либо порта).

[defunct]

Проектирую устройство на атмеге128 - контроллер доступа на 30000 пользователей. Требуется прицепить к ней 4 мегабайта рамы для хранения базы данных и журнала. База данных представляет разделы с однородной информацией - учетные записи, настройки. Хочу спросить совета как прицепить срам, чтоб доступ побыстрее был.

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

[vesago]

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

[Evgeny_CD]

...Пришел я к неутешительному выводу, что на АРМ + SDRAM делать надо.........Посомтрел в соседнем разделе про армы обсуждается проектец. Там AT91RM9200....

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

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

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

[defunct]

Вся беда в том, что мощнее 8252 не пользовал. Пишу правда на си, но 32 бита и 8 бит как пропасть. Посомтрел в соседнем разделе про армы обсуждается проектец. Там AT91RM9200. С виду понравилась машинка. Стоит у нас 18$ + 4$ SDRAM (сам еще не смотрел - говорят). Вот тока может сложная неподъемно.

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

1. Если есть такая возможность, купите
http://www.ucrouter.ru/hardware.html EVM9200
350, зато готовый Linux стоит.

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

[vesago]

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

[Evgeny_CD]

...Кит к сожалению в данный момент не куплю. Буду сразу схему рисовать и отлаживать на готовом устройстве...

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

[defunct]

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

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

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

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

[_artem_]

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

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

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

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

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

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

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

Удачи

[AndyBig]

Вот тока может сложная неподъемно.

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

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

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

32-х битная архитектура на самом деле как для программиста гораздо более прозрачная и удобная.

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

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

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

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

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

[vesago]

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

[AndyBig]

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

[BVU]

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

[AndyBig]

SRAM на предельно допустимых скоростях будет работать нестабильно

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

Вообще, я согласен с одним из вариантов, предложенных _artem_:

б. любой микро со страничной ОЗУ или флешем или харддиском , где данные размешены в соответствии с вашей реализацией

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

[vesago]

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

[Evgeny_CD]

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

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

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

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

[AndyBig]

Большой кольцевой буфер.

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

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

[Evgeny_CD]

...Ну что ж, тогда используйте винт...

Таким образом, мы от 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$ - это уже клиника. (производство своих плат в малых тиражах будет дороже.)

[defunct]

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

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

> vesago

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

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

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

[Evgeny_CD]

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

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

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

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

[AndyBig]

Ведь каждый день можно работать (записывать) с новыми секторами

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

[_artem_]

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

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

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

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

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

[ASN]

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 .

[Evgeny_CD]

...З.З.З.Ы А ногами махать (аля 1-Wire) Megа всётаки удобней, чем AT91RM9200 ...

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

[defunct]

Ведь каждый день можно работать (записывать) с новыми секторами

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

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

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

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

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

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

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

[defunct]

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

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

[vesago]

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

[defunct]

Еще расскажу суть задачи....

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

[vesago]

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

[defunct]

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

Понял..

Хотел у народа спросить LPC - дружественные к пользователю?

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

Сообщение отредактировал defunct - Jan 19 2006, 09:46

[vesago]

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

[AndyBig]

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

2. Выполнять полное сохранение базы из оперативной памяти в новую область флеш, ........

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

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

Хотел еще спросить - сколько раз датафлэш стирать можно и реально ли она на 20 мгц может работать

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

[Evgeny_CD]

Еще один момент - поставьте на пиатние БОЛЬШОЙ кондер, до стабилизатора. И 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
вынужнен признать, что, возможно, моя точка зрения устарела.

[iosifk]

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

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

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

[vesago]

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

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

[ASN]

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

[vesago]

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

[_artem_]

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.

[vesago]

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

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

[_artem_]

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

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

[defunct]

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

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

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

[AndyBig]

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

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