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

Понял..


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

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

Спасибо, сильно вы меня обнадежили. Весь инструментарий я уже приготовил - слил кейл, тулзу, литературу. Засяду изучать. Как понял кейл с виглером не работает поэтому как появятся лишние 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 несущественны в данном случае. А первые два большей частью решаются применением винчестера от ноутбуков.