Jump to content

    

si21

Свой
  • Content Count

    53
  • Joined

  • Last visited

Community Reputation

0 Обычный

About si21

  • Rank
    Участник

Контакты

  • Сайт
    http://
  • ICQ
    0

Информация

  • Город
    г. Минск
  1. Цитата(AlexandrY @ May 9 2008, 20:52) Сами то пробовали? Там просто мусор лежит. Точнее нечто невменяемое и абсолютно без всяких драйверов. А самому внимательно посмотреть лень? - ФС активно используется уже 3 года без нареканий в 4-х видах изделий, релизы конца 2006 г. вполне работоспособны и надежны (у меня работает под АРМом). - Там не мусор лежит, а полный комплект нормальных исходников с тестовыми примерами, в т.ч. и в режиме эмуляции флеша, с небольшими изменениями за 1-3 часа запускается под MSVS - для отладки/изучения. - Примеры написания драйверов есть, тем более если без ОС или под ОС типа uCOS достаточно написать пару примитивных аппаратно-зависимых подпрограмм записи сектора/чтения сектора/стирание блока флеш-памяти и вперед .
  2. Цитата(Alex11 @ May 8 2008, 21:46) Господа, нет ли у кого SDK от TrueFFS или каких-то соображений как правильно делать блочное устройство на NAND Flash, чтобы равномерно использовать ресурс NAND и можно было реализовать на микроконтроллере с небольшим объемом RAM. Посмотрите в сторону YAFFS2 (http://www.yaffs.net/), как раз разрабатывалась для NAND с учетом использования ресурса, если только удовлетворит требованиям по RAM. Там так же есть вариант интерфейса Direct позволяющий использовать эту ФС без ОС.
  3. По поводу Intel PXAxxx

    Блин, невезуха, а я собрался в новой разработке использовать PXA27x
  4. Евгений, в отношении uCOS полностью с Вами согласен. Компактная, достаточно легко портируемая, шустрая при межзадачном переключении, с минимальными накладными расходами в прерываниях и т.п. 16-18 параллельных задач с поддержкой LCD-графики (своя полнооконная система со всеми наваротами) и бешеной нагрузкой в режиме прерываний (более 20 разнотипных каналов ввода-вывода: SPI/RS232/LPT/ETHERNET/Порты на ПЛИС, большая часть из них достаточно тупые и слабо буферизированы) с таймером 1 миллисекунда (OS_TICKS_PER_SEC = 1000) на 90 мГц ARM CPU отрабатываются со свистом (кратковременная пиковая загрузка до 90% - средняя 30-40%, средняя частота межзадачного переключения мониторится в диапазоне 1200-700). >>>> ***************** YAFFS (Сейчас, конечно, имеет смысл юзать YAFFS2) si21 (Электроникс) успешно использует ее для простых ARM устройств. >>>> Простыми я бы назвал условная, т.к. работает полноценная СУБД с индексными файлами (всего ~ 40-60 файлов минимум) + непрерывное (поточное) пополенение журналов и различных логов, позволяет легко как отдельные каталоги подключить отдельные чипы флеш и части одного флеш-чипа ....Много можно писать, но получится что хвалюсь
  5. Плата обработки сигнала

    На вскидку: CIRRUS Logic - EP9312/EP9315, Intel - PXA26x/PXA27x
  6. Компилятор Microsoft для ARM

    Может не совсем в тему, но я лично уже давно отказался от __interrupt и т.п. Небольшой эпилог/пролог на ассемблере при входе/выходе в прерывание и нет проблем. Например, для irq (ARM720): IRQHandler: ; Fix the return address sub lr,lr,#4 stmfd sp!,{r0-r3,r12,lr} bl IRQ_ISR_Handler -> моя п/п-обработчик, написанная как обычная (рядовая) ф-ция ; выход из пр-ия ldmfd sp!,{r0-r3,r12,pc}^
  7. Возможно, будет интересно - полазил по папкам инсталлированного subj и нашел ответ на вопрос - вывод в IDE размера кода/данных файлов отрицательными числами. В документе subj\RVDS\Product\2.2\169\readme.html, раздел "CodeWarrior for RVDS Release Notes (Windows only)" указано: "By default code and data sizes are not shown beside the source files in the project window to speed up build times (they appear as -1). To re-enable this feature, go to the RealView Target panel and select Show Object Sizes." Т.е., по умолчанию это сделано специально с целью увеличения скорости компиляции, и если эти данные требуются - залазим в закладку проекта RealView Target и устанавливаем "птичку" на опцию "Show object sizes"- после перекомпиляции файлов все нормально показывается.
  8. Цитата(zltigo @ Nov 30 2005, 22:53) В свое время у меня это все закончилось значительным переписыванием и портированием Waterloo TCP. При этом железный уровень писался и для NE2000 и для RS232/SLIP полностью с нуля, ввиду полной непригодности существующей поддержки железа для обслуживания сколь-нибудь напряженой работы даже одиинокого человека-клиента. Если предполагается, что какой-нибудь 8bit NE2000 совместимый чип будет прицеплен на порты ARMа да и еще по поллингу работать... то наверное стоит прежде всего подумать о железе. Для своего чернового варианта делал аналогично - на базе Waterloo TCP (правда, полность не завершил). Многозадачность обеспечил за счет семафоров на доступ и связных списков под буфера посылок
  9. Цитата(TMX @ Sep 9 2005, 14:08)Вернулся к разработке РТОС для ARM на досуге... Основной проблемой остается выбор протокола захвата/освобождения ресурсов для исключения инверсии приоритетов и, в конечном счете, достижению предсказуемости. Может, у кого-нибудь есть какие-либо соображения по этому поводу? Любые предложения приветствуются. Постановка проблемы: 1. В системе существуют множественные ресурсы (т.е. не единичное количество ресурсов одного вида, типа блоки памяти, слоты для сообщений и т.п.) 2. В системе существует множество задач с различными неуникальными приоритетами (т.е. задачи могут иметь одинаковый приоритет). 3. В каждый момент в системе исполняется задача с самым высоким приоритетом. Есть раунд-робин, т.е. задачи с одинаковыми приоритетами периодически переключаются. 4. Если задача обратилась к ресурсу, то она либо получает его (если есть свободный), либо становится в очередь на ожидание. 5. Если задача освободила ресурс, то из очереди ожидания ставится на выполнение задача с самым высоким приоритетом. ---Все это уже готово. Задача: по какому протоколу управлять приоритетами задач при захвате/освобождении ресурсов? Может для Вас Америку я не открою , но сам бы поступил так - проштудировал описания/исходники открытых текстов существующих RTOS - часто т.о. находишь "изюминки", которые не упоминаются. Сам, когда начинал программировать (а это уже более 25 лет), т.о. получил хорошую школу.
  10. Цитата(bmf @ Sep 9 2005, 14:01)Так у вас проц нехилый и видно NAND маленкая. А в других (не 32-x разрядных) работа с выделяемой heap памятью (а вся YAFFS интенсивно использует malloc), будет проблематична. И если heap > 64K ? При использовании YAFFS это так. Например 128M/2048= 64.536 секторов, на каждый сетор надо хранить как минимум link 4 байта + еще флаги. Хотя конечно в перспективе, нужно просто переходить на более мощные процы и не заморачиваться с этим. Процессор по нынешним понятиям - середнячек и загружен при работе до 70% (больше не даю, т.к. должен обязательно быть запас на обработку пиковых ситуаций), а в отношении более мощных - Вы правы, ведь сейчас это уже стоит "копейки" и новые МК по энергетике хороши. P.S. Просто я достаточно долго выбирал ФС, прошел и jffs, и jffs2 (были и другие в течение 5 лет) - в результате с точки зрения ресурсов/надежности/удобства - для меня это лучший выбор
  11. Цитата(bmf @ Sep 9 2005, 10:08)Особо не наконфигурируешь - на каждый сектор NADN надо как минимум 30 байт (точно не помню)  RAM для хранения служебной информации. Проще сказать так, если у вас OS типа Linux (и соответственно камень), то и эта файловая система для вас. Для себя я выход нашел в следующем. Информация всегда пишется по кольцу и cтарая просто замещается новой. Логическая целостность обеспечивается link, прописанными  в spare. При таком допущении требования к дополнительной памяти,  сложности и объема кода, быстродействие всей системы получается более чем на порядок!  Время старта - доли секунды. И все эти навороты полноценной файловой системы мне не к чему, т.к. задача архивирования актуальной информации решена, при полном использовании специфики NAND (одноктартное программирование, исправление однобитовых ошибок, учет битых блоков, стирание целым блоком). Да нет, как раз Linux и не пользую - слишком много гробится времени в переключателе задач/обработке пр-ий и относительно много RAM жрет. Здесь меня пока выручает uCOS (минимальные накладные расходы и время отклика). В YAFFS1/2 как раз и нет "наворотов полноценной файловой системы" - т.к. собственно сам интерфейс файловой системы (для direct-mode) реализован буквально в одном примитивном файле с набором вызовов к ядру ФС, но тем не менее, реализовано все, что требуется - например, я работаю с полнофункциональной СУБД собственной разработки ("минималистская" реализация) и не испытываю никаких ограничений. Но, естественно, это мой опыт и мое мнение
  12. ARM with External Memory Interface

    Цитата(Evgeny_CD @ Sep 9 2005, 10:23)Вероятно, это уже не актуально, но все же S3F441FX от самсунга! На складе в КТЦ-МК лежит. LQFP-64. http://www.samsung.com/Products/Semiconduc...FX/S3F441FX.htm ИМНО, не стоит закладываться на Samsung - я к ним тоже раньше присматривался (МК вроде не плохие), но они как-то не стабильны в плане гарантированности того, что чип можно будет купить через год - часто у них он очень быстро снимается с производства (в течении года).
  13. Цитата(Evgeny_CD @ Sep 8 2005, 19:13)А что это за проц такой? На 90 Мгц... Cir Logic - EP7312-90 - 74/90 Мгц
  14. RTOS

    Цитата(Гвоздик @ Sep 8 2005, 10:27)ОС думаю, больше для процессоров подходит, для микроконтроллеров же - это лишнее, не доросли они еще до супервычислений пока. Не хочу начинать бессмысленный спор, но интересно, чем же микроконтроллер отличается от процессора в вашем представлении? По большому счету, только набором развитой периферии! Современные МК переплевывают CPU 7-5-летней давности. Кроме того, ОС НЕ СНИЖАЕТ НАДЕЖНОСТИ ИСХОДНОЙ ПРОГРАММЫ/КОДА, все зависит от умений/опыта/рук/настроения/состояния - выберите нужное - программирующего
  15. Цитата(bmf @ Sep 8 2005, 10:07)c YAFFS работал скажу про недостатки: она не доделана (по тексту много замечаний) и больше не развивается (замещена пользу YAFFS2) сразу расчитайте сколько надо RAM - для 128M NAND при кластере в 8KB - 128K, а в оригинале кажется для 2K нужно - 512K это минимум Время запуска (ускоренная вычитка всех областей) для 128M - около 4sec Непредсказуемые задержки в процессе выполнения (при накоплении данных в gabrage collection происходит их длительная очистка и перемещение) для YAFFS2 структуры в памяти и требовательность к ресурсам еще больше соответствнно для 512M NAND - все в 4 раза больше и дольше единственное преимущество это нечувствительность к пропаданию питания как по мне - она (что YAFFS, что YAFFS2) только для ресурсоемких систем, а по времени старта вообще сомнительна для embedded Принцип работы - просто загрузить всю информацию о всех секторах и блоках в RAM и работать с ней, поэтому и такая ресурсоемкость и монстровитость. С YAFFS2 (direct-mode, ARM CPU 90 Mhz) работаю и сейчас (раньше использовал портированную jffs - это небо и земля) и не совсем с Вами согласен. 1. Расход памяти (RAM) - зависит от конфигурирования (исходных параметров). 2. Gabrage collection - медленноват для NOR-flash, для NAND - очистка сектора (страницы) достаточно быстра (~ 2 ms) и тормозов практически нет 3. перемещение - в этом же суть ФС для флеш-памяти! Благодаря этому, сохраняется ресурс секторов на запись - нет их быстрого "убивания" (идет равномерное использование)! 4. Для обеспечения быстродействия - разумный компромис между RAM и Flash диском (используя все ту же YAFFS2). 5. Приблизительно - у меня в embedde-system - 3 раздела/диска (1 RAM, и 2 - на разных чипах - flash) темп поступления инфо - не менее 500-800 байт в 20-100 мс, все прекрасно (размер конечного файла - не менее 6-8 МБ + 30-40 статичных БД/ИФ файлов, из к-рых читается инфа) 6. Небольшую чистку исх. файлов YAFFS2 можно сделать - с точки зрения оптимизации. Нормальный расход флеш (мой опыт): максим. использование объема - не более 60-70% (т.е., если, например, файлы совокупно будут использовать до 1 МБ, желательна флеш объемом не менее 1.6 МБ) P.S. 1. Для NAND - приведено время очистки блока, а не страницы. Например, если размер страницы 2К, то размер блока м.б. 128К - т.е. 64 страницы, и время очистки блока - порядка 2 миллисекунд 2. YAFFS работает с NAND со страницами в 512 байт (+ 16), YAFFS2 - с NAND со страницами в 2К