bmf

Варианты: - на сайте с uclinux народ использует простой JTAG через параллелльный порт ПК, правда пока только для программирования EEPROM для BF - если делаете на BF533, то можно (ссылки на схему где-то здесь пробегали) на одном корпусе CYPRES собрать эквивалент JTAG ezkit533 через USB, соответственно все фунции кита для отладки вам доступны (но наверно будет работать только с BF533 и BF537, т.к. китов 532 и 531 нет) - самый простой, по старинке, вывод дампа в реале через RS232, иногда только так и можно отладить реальную программу, работающую с переферией, которую нельзя останавливать Еще варианты для программирования EEPROM: - панелька - внутрисхемное подсоединение программатора (если зделать развязку от BF) Выбирайте. Посмотрите схемы (доступны в инет) - ezkit533, STAMP BF533 UCLINUX вот еще простенькая одна, хотя и ее можно тоже уростить egz_bf533_v1.pdf

Если хотите економить, то всего-то и нужно BF532, кварц, два стабилизатора на 3.3 и 1.2, и SPI EEPROM для начального загрузчика или монитора (здесь творчество для экспериментов) ну и буфер на RS-232. Так киты для 2181 и были сделаны. В 30$ может и уложитесь. А лучше пробуйте BF537, у нее есть аппаратная загрузка через UART, только это BGA корпус, правда не очень страшный - для вашей задачи и в 2-х слоях разведется, если ничего к шине не цеплять.

Хоть и VDSP++ GNU совместимый но: 1. Сначала портируйте всю библитеку glib или newlib, родная в ADSP сильно упрощенная (это тоже большой кусок работы) 2. Размер байта. Если не хотите проблем он должен быть 8 бит или придется весь код пересматривать полностью заново. Думаю в BlackFin из-из этого она и была введена. 3. Если это Linuх, а не ucLinux no необходим MMU т.к. любая задача работает в виртуальном пространстве и думает что ей доступна вся память. ИМХО легче сразу проц правильный выбрать или все затянится на годы.

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

а может уважаемый подскажет как перевести попроще комменты из того файла дос (например обычный C текст), такая комбинация уже не работает, буду благодарен ;)

Вот здесь по распостраненности по конкретней - с характеристиками ядра и графиками: http://www.tron.org/cld/events/ohp/J.pdf (208кВ) В любом японском продукте - ж.диск, плейер, часы, PDA , автромобили ... - TRON

Каждая ОС будет отличаться по сжираемым ресурсам и предоставляемым ею возможностями. И для разных проектов, под конкретную задачу и выбранный проц, оптимальный выбор не очевиден. На вырост и для более мощных чипов, если не хватает возможностей uCOS, mUTRON будет в самый раз, сам попробовал для ADSP-BF533 и полностью доволен. Сравнимать FreeRTOS и mUTRON неуместо - это разные весовые категории. Я бы сказал что FreeRTOS что то типа uCOS, но на заметно любительском уровне, хороших RTOS c открытым кодом не так уж и много. Затем по возможностям ядро mUTRON, ну а дальше VxWorks, RTEMS, uCLinux - это их наиболее распространенных и доступных. У японцев вся линейка на базе единой спецификации TRON на любой вкус (ITRON, JTRON, BTRON, CTRON,..) Заголовок темы - так это они так утверждают, к сожалению они языково отрезаны от мира и много делают только для своего рынка, так что проверить не могу.

жди в upload\DOC\standards\ZigBee-Specification 6.7M

Насчет выигрыша с ФАПЧ не знаю, но сам метод и алгоритм декодировани FSK (теория) хорошо описан в http://focus.ti.com/docs/mcu/catalog/resou...actName=slaa037 посмотри, может пригодится

так посмотрите что свободно в инете, или чем-то неустраивает? LwIP uC/OS-II port http://www.geocities.com/michaelanburaj/ http://geocities.com/michaelanburaj/downlo..._ucos_1.011.zip

Да все уже получилось не так, как вначале задумавылось :( Время реакции на прерывание (имеется ввиду задержка начала выполнения первых полезных инструкций кода прерывания) в preemtive RTOS типа AvrX или smcRTOS слишком большое (теоретически если процессор уже находится в состоянии переключения на какую любо задачу то 2*время_полн_сохр_контекста + время_полн_вост_контекста) и это вместо того чтобы просто сделать какой либо ответ на прерывании в самом теле процедуры и выставить семафор, и лучше счетный, что бы знать сколько надо еще потом пропущенных прерываний обслужить. Недостаток в этом случае в том, что процедура прерывания будет выполнятся в контексте текущей задачи, и если задач несколько , то в preemtive RTOS надо еще в каждой из них отдельно зарезервировать добавочную оперативную память. Простые быстрообслуживаемые прерывания без вызова функций RTOS тоже выполняются в контексте любой текущей задачи, для них тоже надо память. В итоге альтернативе простой cooperative RTOS не нашел, все преимущества preemtive при большом колличестве задач или недостатке памяти и требовании скоростного обслуживания прерываний испарились. Да и лишние 300 байт кода на поддержку preemtive по сравнению cooperative, когда все и так еле лезет, не лишние.

Придется его такой и использовать. Просто в оригинальной проге, которая написана под другую ОС, он часто использовался с таймаутом, а мне хотелось обойтись малой кровью, видно не судьба.

Теперь о позитиве. Учитывая лицензионную политику micrium, шансы очень даже не плохи. Только ориентация нужна на немногим более жирные процы, тогда и c++ заиграет на всю катушку, а то получается, что жалуемся на нехвату ресурсов, а отказываем себе так сказать в необходимом, и сами используем ЯВУ. Сделать всего 8 или 16 только не задач, а приоритетов, а остальное по Round-Robin, хотя бы опционно. И конечно же расширить API, более привычно к той же ucos. О разделении переключения контекста через прерывания и софтверно уже писалось. Для конечного пользователя код вырастет не намного больше чем был ранее или останется таким же, учитывая опционность компиляции. Больная тема порты. В некоммерческом проекте все охватить не реально. Но при таком более широком подходе и количество желающих портануть для себя возрастет. Имея опыт работы с AD, к слову неплохо ляжет на 2191 и Blackfin, и сам бы прикрутил их для своих задач, вот и новые порты. А возможно что это все бред, учитывая что все движется на чистом энтузиазме его создателя, а ему это просто не нужно.

На каждый ваш лист, я смогу аргументированно ответить своими тремя, на которые я не сомневаюсь вы ответите уже 9. И т.д. Дискуссия грозит превратиться в бесконечную, и в дальнейшем наверно теряет всякий смысл. Мы просто немного смотрим на одно и тоже с разных позиций или говорим о разном. Чем продолжать ее дальше - лучше по вашему же совету заняться делом. и ИМХО иногда Вы не логичны, перевираете, недоговариваете или говорите совсем о другом. а зачем? разве в тойже smcRTOS используется наследование? А попробуйте использовать глубокое наследование в коде прерывания, что из этого выйдет ..., а еще лучше наверно виртульные функции в микроконтроллере. а скрыть внутренне представление оно в C легко скрывается. А шаблоны, то вообще на любителя, и кто то советовал из совсем не использовать. И вся эта концепция красота vs. эффективность. под большим вопросом. И такая простота больше нужна студентам первых курсов, чем для промышленных решений. и ничего в этом крутого нет, это под силу среднему программисту и даже хорошему студенту. Как то напал на японский сайт, так там неисчислимое море этих rtos - написанных ихними обычными студентами, для них это в порядке вещей. Ведь основа всей этой карусели, когда разберешься, одна и та же, как раз важна принятая концепция. И основная трудоемкость - учитывание особенностей конкретных компиляторов и чипов. ха, это свойство порта для той же ucos, где переключения через прерывание и софтверные разделены, я давно уже использую для DSP под конкретный компилятор - вот там это действительно актуально, размер сохраняемой области уменьшается в разы. а насчет, другой ОС для меги8- повторяю , для данной задачи мне более подойдет avrX на ассемблере - полный preemptive и Round-Robin в одном флаконе и мои любимые семафоры и 500 байт footprint. вот вся и арифметика. Или что мешает переписать ту же ucos, выкинув инверсию приоритетов и оставив 8 или 16 задач и иметь в распоряжении все типовое API. При существующих портах это сразу накроет большинство микроконтроллеров. Лично мне это не нужно, каждый занимается тем что ему интересно или за что платят деньги. smcRTOS на своем текущем этапе более интересна в академических целях, если вам будет легче, то это моя частная точка зрения, не более. и как Вы ее яросно защищаете, говорит что она еще может не остановилась в своем развитии. И если вы считаете что то иначе, то это ваша точка зрения. И кроме нас с вами, все о чем мы говорили здесь никого не интересует(к сожалению) и все что я высказал как сторонний и незаинтерисованный наблюдатель в плане улучшения (больше концептуального развития), то только из лучших побуждений, и для достижения успеха - маркетинг в россии для продвижения не причем, у нас используют то, что действительно лучше и удобней, а не самое рекламируемое и продаваемое там на западе, и когда долго работаешь над одним проектом часто затуманивается взгляд на очевидные вещи (чтобы не было обидно, и я тоже не исключение). И я признаю что smcRTOS несомненно задумана как красивая, элегантная и простая, и посмотреть как внутри все устроено стоит того, чего и всем желаю.

Знаю что не влезет на мегу8, поэтому и ищу вариант для уже написанного кода в jacOS, и в силу некоторых причин надо на preemptive OS. Напомню, что основный вопрос разногласий "а чем smсRTOS хуже ucos (по концепции построения)" Вы все прекрасно понимаете. Возмите API, посмотрите возможности ядра количество поддерживаемых задач - сколько вы будете делать bitmapsearch (поиск приоритета) для всех? Уснуть можно. EventFlag в 1 bit - и это полноценный флаг?, вы их наплодите ровно в 8 или 16 раз больше, и соответсвенно займете память. семафоры коды возврата вcех функций обращения по именам таймауты различные состояния задачи еще много чего .... Принципы построения ядра, когда все задачи и очереди укладываются в байт или нужно орнанизовавать их список и по нему лазить - различаются существенно, и то что не надо для одной необходимо для другой. Вы скажете что вам всего этого и не нужно, и правильно. Если покупаете запорожец, то вы знаете зачем и для чего он вам нужен, а вы пытаетесь впарить его как мерс. Как smcRTOS запорожец по отношению ucos, так и оная тоже самое по отношению скажем mITRON. Просто надо в документации нормально объяснить эти моменты, что все только ради максимального уменьшения и простоты кода, и в результате вы получите сильно обрезанное API, всем понятно, все юзают и довольны. Сам юзер должен решать что ему нужно, подставляя небходимые ему опции компиляции, и получая ядро с теми возможностями, которые ему нужны и желательно из всего типового API. А так получается что даже для целей обучения, несмотря на ясность и элегантность кода, полноценно нельзя использовать, ввиду отсутствия стандартных элементов синхронизации. Назовите хотя бы одну OC без семафора - элементарного элемента синхронизации, и полноценно поддержать который можно только на уровне ядра. Или "Такое планирование несколько сложнее простого приоритетного, а преимущества как-то не особенно заметны." А что плохово в том, что задачи одного приоритета крутятся по Round-Robin, не хочешь - не используй, а равноправных задач в проекте тоже может быть достаточно. Вот после устранения указанных недочетов (и конечно портируемости) она действительна станет серьезным конкурентом ucos. И проблем переписать ее на простом C для улучшения портируемости нет никаких, только вся целостность как ОС сразу пропадет. Кстати bitmapserch в нормальных процессорах эта одна ассемблерная команда за один такт, здесь в том же ucos прощелкали, эту возможность, чтобы вынесте ее в порт. Насчет макроса, здесь я ошибся, использую свой порт, а там от оригинального ucos мало чего осталось, но такая возможность принципиально есть. Про прерывание я имел ввиду случай, когда не надо будет переключать контекст при ввходе/выходе, в smcRTOS это обязательно, независимо от будет ли выполняться само переключение, таких ситуаций в жизни предостаточно. Воспринимайте сказанное как стороннюю оценку, насколько объективную вы сами решите, мне по большому счету побарабану, я просто высказываю свое мнение. И кстати почему то все солидные фирмы скромно называют свою embedded RTOS - или кернелом или биосом и только новоиспеченные кричат о свох продуктах как о OS, до которой в полном смысле этого слова им ... . smcKernel отражало внутренности гораздо вернее. Даже в ucos потом дописали "Real-Time kernel".

uITRON - прекрасный пример как правительство Японии на деле думает о своем развитии, без создания каких то сомнительных фондов будующих поколений. Финансируется государством, открытые спецификации и free код, свободная лицензия. Единый стандарт для государства. Не надо каждому тратить и время на деньги на изобретение велосипедов, бери и пользуйся. Не намного более требовательная, чем широко распространенная у нас uCos, которая кстати не бесплатная. Параметры еще какие. Гляжу, многие западные компании просто беруют и после косметических добавлений толкают за килобаксы как свою. Кстати код, можно скачать из инета, только комменты там все на японском, ну не любят они европейцев, или создают искусственную преграду для другого мира, благо что язык программирования интернационален. Когда же нашим правители с селянским или с имперским мышлением будут также думать? А то все погрязли в междупартийных разборках и поисками врагов или интеллектуальных измышлениях куда тратить нефтедоллары. Кому интересно, последняя спецификация здесь: http://www.assoc.tron.org/spec/itron/mitron-400e.pdf Эта полная, но минимальное обязательное ядро намного меньше, API для нее описано в дополнениях Automotive Contorl Profile. А код и порты здесь: http://www.toppers.jp/fi4-kernel.html минимальное ядро - это проект TOPPERS/FI4, там есть и полный проект и еще много чего интересного. Японское правительство уже подумало о вашем будующем (имею в виду ембеддеров).

А если реализовывать по честному семафоры (как в той же uCos) - то придется уже вести их дополнительный список и просматривать его при каждом изменеии состояния задачи. Размер и сложность OC вырастет раза в два. После этогo smcRTOS - более правильно называть просто диспетчер с некоторыми фунциями API, пригодный для академических целях или когда уже деваться некуда из-за скудности ресурсов, но здесь уже как правило есть и другие альтернативы.

И еще, посмотрите как в uCos ищется самая приоритетная задача, и как в smcRTOS или freeRTOS и увидите что время поска при любом переключении (через swithtask или при установке семафора) будет в 10 раз меньше.

В качестве примера (данные не мои,а из англоязычной конфы), приведу пример: ucLinux на ADSP-BF533 дает 600 MIPS или 1200 MMAC - так вот реализация TCP/IP стека на нем дает, смешно сказать, максимальную скорость 1МБайт/сек, а на томже железе на обычной RTOS - по полной, 10МБайт/сек. Если вы посмотрите исходники Linux, то там почти все сплошное копирование памяти из одного буфер в другой, наверно часто бестолковое. И без кэша L2, а это настольная архитектура, быстродействие всей системы будет всегда плачевной. uCLinux фактически это обычный десктопный Linux с минимальными иправлениями и громадным бесполезным объемом кода.

Ну например, для тойже uCos - реакция на прерывание - только установка семафора из макроса(не из функции!, с целью уменьшения загрузки) и вызов IntExit(). А здесь сколько пройдет времени для вызова системной функции, полная перезагрузка стека, потом C++ хрен знает что наворочает, потом восстановление стека. Раз в 10 набежит. Опятьже в uCos полный базисный набор функций для взаимодействия, и вообще то набор этих функций берется не от балды а в соответствии с индустриальнымы стандартом. Чем он шире, тем естесвенно и более тежеловеснее будет OC, но пользователь все их может не использовать. Почитайте например спецификацию uTRON, это то что японцы требуют для ОС ембеддед систем (например для использования обычном автомобиле), даже uCos не потянет. Инвесия приоритетов, тоже согласитесь, чтобы передать управление другому равнозначному процессу, а приоритет нельзя использовать тот же, приходится как-то изголятся. А чтоб объективно полность сравнить, набо провести тест, и замерить реакцию на прерывание, время переключения задач, занимаемая память и др, возможности API.

Не знаю, впринципе всего десяток функций, там и собственно скрывать нечего. А C++ можно натянуть на любую реализацию, как например ADSP VDK Kernel -хочеш юзай ассемблер, хочешь С или классы C++, а под низом ассемблерный код без потери эффективности. Это я в тему изначальной красивости (но с реальной потерей производительности и ресурсов). Всетаки ниша этой ОС слабые микроконтроллеры, ниже работают кооперативные OC, а ваше уже можно использовать и посолидней типа uCos. Прослойка очень тонка. У меня например использование для ATMEGА8.

Спасибо за идеи. В принципе если есть исходники, то реализация семафора по аналогии с флагом и мютекс вроде не сложна. У меня вопрос только почему этого нет в базовом наборе? В моем коде и то что я видел как раз 99% занимают обычные и счетные семафоры. Например возмите любой TCP порт для RTOS, как пример функционального применения мзаимодействия между процессами. Заменять где возможно это на мютекс и на использование несколько флагов - извращение. Растет память, мютекс вообще не имееет состоятия "сигнал" и таймаутов. Флаг уже не используешь в теле функции, которую могут вызывать несколько процессов. Вообщето для сябя я решил лучше попробовать avrx - там как раз та концепция, которою я придерживаюсь. Дя и сомнения в эффективности языка C++ кода для этого и в частности в обработке прерываний, хотя идея его использования безусловно красивая. Насчет недоделонности AVR - в принципе да, но на каждый Ваш довод можно привести и противоположный. И спор будет бесконечный, а мне не хотелось бы тратить на это время. Свое ИМХНО я сказал, еще раз спасибо за уделенное время, успехов.

Вообще то чаще нужен простой бинарный. А Мутекс и Флаг события - работают здесь по другому, обратите внимание в обычном семафоре после "сигнал" только событие с большим приоритетом переведется в состояние работы, а у флага - все события которые имеют этот флаг, сначала естественно с вышим преоритетом, затем и все остальные. Совсем другая функциональность. Я не знаю никакой другой RTOS, гдебы не было этих обычных семафоров как базовый элемент взаимодействия. По поводу безапелляционности высказываний автора, меня больше задело не содержание(хотя здесь можно поспорить), а форма и категоричность высказываний: "убогий", "два норвега" "о чем думали" - для официальной документации в русском языке есть более мягкие выражения, а то создается впечатление, что все кто юзает ATMEL тоже убогие и недалекие. По архитектуре: - я в основною юзаю DSP - там тоже применяют два стека (реально даже больше - еще для аппаратных циклов)- только это преимущество - быстрее реакция на прерывание А что медленно работает с памятью - так это за один так пре тех частотах не зделаешь, у микрочипа любая команда 4 такта. И большое колличество регистров наверно как раз и должно компенсировать. Так что все дело с какой стороны смотреть. И все вышесказонное естественно ИМХНО.

В доке к версии 2.0 такого обзаца нет. Думаю что как раз реализация семафора будет по коду гораздо меньше и эффективней чем TChannel и MemoryManager, а не наоборот, делать элементарный семафор из них. Ведь мы работаем при недостатке памяти и ресурсов. К автору OS, я конечно же отношусь с уважением, без него и небыло что обсуждать, но хочется выбрать для себя верное и правильное решение. А убогость архитектуры с одной стороны, может выливаться преимуществом в другой. Это вопрос сложный. И с одной колокольни об этом судить не стоит, надо учитывать доводы всех сторон. Но это совсем другая история. В общем, теперь ясно что имеем. Thanks.

Что? Все от балды что ли все ставят? У микрочипа есть appnote на свои чипы, и никаких вопросов и двоякостей не возникает. У Atmela я такого не нашел.