Каковы по вашему мнению критерии перехода от "голой" программы к использованию RTOS?
Я вижу следующие:
необходимость работы с tcp/ip и т.д.
IPC (может легче что-то свое прикрутить?)

Всегда :-)
Кроме вырожденных случаев экономии "последнего байта" и "последнего такта".
Причем это тоже не факт, ибо за счет правильно посторенной системы можно и на объеме съэконогмить и
наиболее безболезненно разделить недостающие ресурсы между страждующими.
Вышенаписанное результат личного ~20-летнего движения от "сейчас сам быстренько напишу
маленькую и шустую" к системным вещам. Естественно "движение" сопровождалось возрастающей сложностью программ и мощностью контроллеров.


:-) Ну а это к RTOS ни при чем. Обычно такая причина выдвигается теми, кто по жизни пишет очень небольшие простенькие программы и при необходимости поднять нечто более сложное готов "поступиться с принципами" и взять хоть RTOS, хоть что угодно, лишь-бы там "было то, что нужно".
Собственно в такой подход и такая мотивация совершенно НОРМАЛЬНА, просто иногда на таком пути
человеков заносит куда-нибудь в "другую канаву" типа - "Как поставить Linux на ARM7" :-(

Отсутствие свободного времени :-)) Ну некогда мне писать scheduler, file system и networking stack - надо аппликацию разрабатывать, за которую деньги и платят. Хотя вырожденные случаи, когда из дохлого надо выжать всё, тоже встречаются.

Есть алтернатива и firmware и RTOS - real time kernel.
К привмеру FreeRTOS (GNU,портирована на многие CPU), VDS kernel (для BlakFin, потдерживается analog device).
Такия ядра, как правило, дают возмодность динамически выделять память, и синхронизировать tasks.
Так, например VDS kernel можно сконфигурировать в 4k.

На мной взгляд, значительно упрощает процес разработки SW.

Применять или не применять RTOS прежде всего зависит от конкретной задачи. Во-первых если необходимо реализовать режим многозадачности, во-вторых если это поможет уменьшить время работы над проектом. А сувать операционку для крутости или полностью переходить на нее это бред. Многие задачи гораздо быстрее и легче решить не заморачиваясь на этом вопросе.

Позволю себе заметить, что зачастую (пусть далеко не всегда, но в последнее время - особенно) привычки программиста и time-to-market играют более важную роль, нежели требования задачи.
А кстати, что есть такое - требования задачи? Кому-то задача ставила требования? По-моему и в этом случае всё достаточно субьективно.

Критерий простой- если в системе крутиться более трех задач то надо переходить на RTOS. Имеется ввиду логические задачи, которые потом станут отдельными процессами под RTOS. Считать ли обработчик прерываний отдельной задачей- зависит от монструазности обработчика. Иногда да, иногда нет.

Ой, извините пожалуйста! А вот у моей задачи такие требования:

сделать БПФ для вектора длинной в 2048 точек, если новый отсчет сигнала появляется каждые 4000 тактов процессора.

БПФ у меня получается минимум за 40000 тактов.

Следовательно, пока у меня наберется полный вектор проходит 2048*4000= 8096000 тактов.

Первое впечатление - я успеваю! Ведь мое БПФ делается всего за 40000 тактов.

Впечатление второе: нет... не успеваю... Ведь пока я БПФ делаю (функция естественно библиотечная, переписать нельзя), кто-то должен принять 10 отсчетов входного сигнала. Значит, библиотечную ф-цию нужно как-то прервать, принять очередной отсчет и запустить снова с прерванного места?

Не считаете ли Вы, что моя задача требует написания планировщика?

Сообщение отредактировал st256 - Nov 30 2006, 18:08

Бога ради, принимайте по прерываниям или DMA. А вот если параллельно к этому надо еще и парсить IP пакеты, считать часы реального времени, писать лог во флешку, ждать нажатия клавиши пользователем и рисовать на экране результаты- вот тут RTOS просто незаменима.

IP - это уже не real-time. Это раз.

считать часы реального времени? Ну не знаю, вроде тоже не real-time, многие инструментальные оси имеют эту приблуду... хотя сильно настаивать не буду.

писать лог во флешку, ждать нажатия клавиши пользователем и рисовать на экране результаты? Ну знаете, к real-time это имеет уже совсем отдаленное отношение.

Другими словами - Real-Time Operating System (RTOS) для Ваших задач не нужна. Справится и банальный порт LINUX для ARM. Это из собственного опыта говорю. А вот, как без ртосины решить мою задачу, если к примеру, когда я принимал участие в разработке одного DSP мы для уменьшения площади кристалла и облегчения собственной жизни выкинули всякие DMA и т.п. посчитав, что это себя просто не оправдывает?

>> Не считаете ли Вы, что моя задача требует написания планировщика
Речь идет не о _написании_ а об _использовании_
Отсчеты у вас что, не по прерываниям принимаются?

Написание планировщика вещь не сложная - пару недель всего вместе с отладкой. Использовать чужую ось (типа microC) - часто означает потерять теже пару недель, но для получения гораздо худшего результата.



Если у Вас real-time, то использовать прерывания и приоритеты строго не рекомендуется. Работают, обычно, по опросу - так надежнее.

real-time это абстрактное условие реакции на внешние события в заданный интервал времени.
Про прерывания и приоритеты - мне ваш анекдот очень понравилсо.

>> Написание планировщика вещь не сложная - пару
>> недель всего вместе с отладкой
OS это не только шедуллер, но еще и сервисы синхронизации между задачами.

Не, это вовсе не обстрактное условие выполнения некой задачи в отведенное время. Хотя и с Вашим определением я почти согласен. Остается понять, что такое "реакция".




Если это для Вас - анекдот, то для меня совершенно понятно, что к real-time Вы отношения не имели.



Добавьте еще две недели на флаги, мьютексы, семафоры и API-функции.

Если время выполнения задачи ограничено (имеется в виду астрономическое время) то это Real Time. Например, подсчёт зарплаты в конце месяца :-))

Почти всегда, наряду с hard real time CPU должен выполнять какие-нибудь совершенно не Real Time функции. И для этих целей off the shelf OS весьма хороша.