[kichkine 0]

Каковы по вашему мнению критерии перехода от "голой" программы к использованию RTOS?

Я вижу следующие:

необходимость работы с tcp/ip и т.д.

IPC (может легче что-то свое прикрутить?)

[zltigo 1]

Каковы по вашему мнению критерии перехода от "голой" программы к использованию RTOS?

Всегда :-)

Кроме вырожденных случаев экономии "последнего байта" и "последнего такта".

Причем это тоже не факт, ибо за счет правильно посторенной системы можно и на объеме съэконогмить и

наиболее безболезненно разделить недостающие ресурсы между страждующими.

Вышенаписанное результат личного ~20-летнего движения от "сейчас сам быстренько напишу

маленькую и шустую" к системным вещам. Естественно "движение" сопровождалось возрастающей сложностью программ и мощностью контроллеров.

 

необходимость работы с tcp/ip

:-) Ну а это к RTOS ни при чем. Обычно такая причина выдвигается теми, кто по жизни пишет очень небольшие простенькие программы и при необходимости поднять нечто более сложное готов "поступиться с принципами" и взять хоть RTOS, хоть что угодно, лишь-бы там "было то, что нужно".

Собственно в такой подход и такая мотивация совершенно НОРМАЛЬНА, просто иногда на таком пути

человеков заносит куда-нибудь в "другую канаву" типа - "Как поставить Linux на ARM7" :-(

[akivas 0]

Каковы по вашему мнению критерии перехода от "голой" программы к использованию RTOS?

Я вижу следующие:

необходимость работы с tcp/ip и т.д.

IPC (может легче что-то свое прикрутить?)

 

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

[surge 0]

Есть алтернатива и firmware и RTOS - real time kernel.

К привмеру FreeRTOS (GNU,портирована на многие CPU), VDS kernel (для BlakFin, потдерживается analog device).

Такия ядра, как правило, дают возмодность динамически выделять память, и синхронизировать tasks.

Так, например VDS kernel можно сконфигурировать в 4k.

 

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

[Kilio 0]

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

[IgorKossak 0]

Применять или не применять RTOS прежде всего зависит от конкретной задачи...

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

А кстати, что есть такое - требования задачи? :w00t: Кому-то задача ставила требования? ;) По-моему и в этом случае всё достаточно субьективно.

[khach 40]

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

[st256 0]

Применять или не применять RTOS прежде всего зависит от конкретной задачи...

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

А кстати, что есть такое - требования задачи? :w00t: Кому-то задача ставила требования? ;) По-моему и в этом случае всё достаточно субьективно.

 

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

 

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

 

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

 

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

 

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

 

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

 

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

Изменено 30 ноября, 2006 пользователем st256

[khach 40]

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

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

[st256 0]

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

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

 

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

 

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

 

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

 

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

[Alex B._ 0]

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

Речь идет не о _написании_ а об _использовании_

Отсчеты у вас что, не по прерываниям принимаются?

[st256 0]

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

Речь идет не о _написании_ а об _использовании_

 

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

 

Отсчеты у вас что, не по прерываниям принимаются?

 

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

[Alex B._ 0]

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

Про прерывания и приоритеты - мне ваш анекдот очень понравилсо.

 

>> Написание планировщика вещь не сложная - пару

>> недель всего вместе с отладкой

OS это не только шедуллер, но еще и сервисы синхронизации между задачами.

[st256 0]

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

 

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

 

Про прерывания и приоритеты - мне ваш анекдот очень понравилсо.

 

 

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

 

>> Написание планировщика вещь не сложная - пару

>> недель всего вместе с отладкой

OS это не только шедуллер, но еще и сервисы синхронизации между задачами.

 

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

[akivas 0]

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

 

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

 

Про прерывания и приоритеты - мне ваш анекдот очень понравилсо.

 

 

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

 

>> Написание планировщика вещь не сложная - пару

>> недель всего вместе с отладкой

OS это не только шедуллер, но еще и сервисы синхронизации между задачами.

 

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

 

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

 

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