Хочу еще добавить, что 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 ключей, которые в любое время могут отпереть двери.