Получили ответ от Express Logic по поводу стоимости ThreadX
Мда, хочется спросить как в известном анекдоте - "А что, ваша Сонечка такая уж красавица?"
Embos от сеггера недалеко ушел ~$5k.

В основном выбор RTOS шел от функционала и удобства отладки (читай наличие поддержки в IAR'е). По первому вопросу вполне можно найти приемлемое решение и среди бесплатных систем, а вот по второму выбор ограничен (FreeRTOS не устроил по первому).

Возникает резоный вопрос - существует ли какой SDK по написанию плагинов к IAR'у под произвольную RTOS?

Существует C-SPY SDK, а вот можно ли плагины в нем ваять - вопрос.
****://caxapa.ru/279903.html

Имхо более правильный путь - использовать uC/Probe. Можно построить более объемную систему отладки, трассировки, мониторинга. Причем возможна удаленная работа по юдп. Сравнительно легко прикручивается к любой целевой ОС и траспорту (я использовал uIP). Недостатков два - uC/Probe хостится на вин машине и стоит денег.

uC/Probe разве может отлаживать RTOS?

Я так понял что речь об отладке работы самой RTOS.
Т.е. просмотр в реальном времени событий, состояний задач, состояний всех объектов синхронизации, движков памяти и проч.
В коммерческих RTOS есть обычно такой отладчик встроенный в саму RTOS и работающий в режиме эмуляции терминала типа VT100
Конечно не GUI но вполне годится чтобы грубые просчеты с ресурсами обнаружить.
А главное таким способом можно ось отлаживать дистанционно через очень медленные каналы типа GSM/GPRS.

Возможно вы и правы, хотя мне кажется, что купить коммерческую РТОС и потом её отлаживать - это немного необычно. Что касается просмотра событий, состояний задач и т.д. то это все есть в uC/Probe для юкос. Но это хозяйство написано профи, хорошо документировано и есть в исходниках, то есть легко пишется для любой другой ОС (начиная с суперлупа). Впрочем, вы намного лучше меня знаете, как обстоят дела с микриумными исходниками
Если же под просмотром понимать точную трассировку приложения, то здесь uC/Probe (как и его прародитель uCView) предоставляет интерфейс терминала, те инкапсулирует терминальные сообщения на таргете в свои пакеты и отображают их окне терминала. Иными словами, особых удобств по сравнению с обычным терминалом никаких, за исключением скорости при работе по сети.

А в чем преимущество коммерческой ThreadX перед бесплатными RTOS того же уровня ?

Юрий, TNKernel мы рассматривали в первую очередь. Отсутствие некоторых механизмов в ней (я не хочу спорить о вариантах решения, например, проблем критических секций и т.п) в принципе еще приемлемо, руки растут из нужного места и допилить под собственные требования можно. Но! Вопрос стоит в нехватке времени, желании получить все готовое и наличии средств (разумных!!!) под эти желания.
Кроме того, желание иметь отладчик именно OS перевешивает многие достоинства TNKernel. Да и наличие технической поддержки не последний аргумент.

За внимание к TNKernel - спасибо, но в настоящее время существуют и другие бесплатные RTOS, достойные внимания.
Главным аргументом, видимо, является "отладчик именно OS"©.
Я просто пытаюсь понять, что именно Вы ожидаете от такого отладчика, в чем конкретно он может Вам помочь ( просто я никогда такого рода инструментом не пользовался) ?

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

Смотря что Вы ожидаете от отладчика. Тут в топике рассказывали про отладочный терминал в консольном режиме - такой под TNKernel в одиночку написался за несколько дней - можно смотреть списки объектов, список задач - где чего (в каком файле и в какой строке исходника) ждет и чего именно ждет. По синхрообъектам видно какие задачи ждут (очередь ожидающих задач), есть профайлер - точный (до тика процессора) и грубый быстрый (до мс) - видно какая задача сколько времени забрала. Там всего несколько сотен строк кода - вполне подъемно, причем не только для TNKernel - все системы такого уровня более-менее одинаковой сложности.


А можете рассказать подробнее какими именно экстрафичами инструмента пользовались, хотя бы в общих словах?

Хотел бы я вообще понять что такое "отладчик именно OS" .... может это по другому называется ?



Может вы работали с VxWorks под Торнадо ? Но если я правильно помню там это называется не "отладчик"....

ИМХО: ThreadX - такой должна быть RTOS. Если есть бесплатные решения с таким же, иниуитивно понятным, компактным, но достаточным для работы, интерфейсом (набор вызовов ОС) и документацией - хотелось бы увидеть список.

Конечно, можно взять и любое другое решение, и даже попытаться самому написать, но где будет применяться данная ОС ?
Лично мне обычно хватает багов и в приложении, нехватало еще в ОС проблем.
Если срабатывание WatchDog, примерно, так раз в сутки, считать нормальным делом, то ОС вообще можно не выбирать - берем что по-ближе лежит.

А насчет отладки через терминал - я все таки считаю, что речь идет об отладке приложения, а не ОС - то JTAG, а в большей степени Unit/Integration тестирование закрывают этот вопрос. Ибо наблюдать на экране за тем как приложение ведет себя в Nominal case еще не гарантирует его безотказную работу. Например, писаный нашей командой bootloader "застрял" на объекте когда не смог соединиться с сервером в течении суток (сервер тупо был выключен), и такой баг выловить глядя в терминал - "...что то мешает мне поверить в этот аристократизм...".

ЗЫ:
Конечно каждый для себя сам решает. Для меня, (хорошая ОС == надежная ОС).

Естественно что ось такую как ThreadX никто и не собирается отлаживать.
Ее надежность в тестовой конфигурации проверена сверху до низу.
Но... как только вы туда добавили хоть строчку своего приложения и скомпилировали конкретным компилятором ее надежность летит ко всем чертям.
Вы просто и тривиально можете сделать некорректный ретаргетинг, что кстати постоянно многие и делают, после чего слышны возгласы о неправильном функционировании printf и проч. Можете неправильно выделить стеки. Выбрать неправильные опции компиляции.
Можете не знать сколько нужно ресурсов памяти мидлваре поставляемому с RTOS.
Можете неправильно расставить приоритеты задачам и затормозить тот же TCP/IP стек или файловую систему до предела.
И как вы назовете процесс отладки такого приложения?
Ваше приложение может быть всего из одной строчки и невинно как дитя, а при этом нифига работать не будет.
Это просто надо знать с насколько сложным мидлваре идут RTOS.

Раз уж разговор коснулся ThreadX, хотела бы спросить: есть ли какой-нибудь прок от демо-версий, выложенных на сайте компании IAR?
Download ThreadX demos
Можно ли их применить в своих разработках (мирясь с ограничениями) или необходима только полная версия?

Заинтересованные лица могут ознакомиться со всеми этими архивами, минуя регистрацию, т.к. я выложила всю эту коллекцию на наше ftp, вот сюда:
/pub/OS/ThreadX/Demo/

каким контактным адресом пользовались для запроса цен?
я в своё время связывался с одним из представительств - тишина.
а контора в России больше эту ос не поддерживает.

Коллеги, а кто-нить интересовался стоимостью лицензий на RL-ARM от Keil? В частности на RTX?