Глупый вопрос - какие плюсы от RTOS (ucos) Опции

[Andr2I]

Вопрос действительно глупый, но к сожалению при просмотре форума четкого понимания не получил. Возможно подобный "глупый" вопрос стоит и перед другими людьми.

Итак есть контроллер LPC2138, к нему LCD экран 128*64, клавиатура на прерывании, пищик, EEPROM, использован канал АЦП и ЦАП, SPI. Система однозадачная. Файловой системы нет.

Понятно, что использование RTOS (в данном случае ucos) несколько затормозит систему. А какая будет от нее польза, кроме возможности перехода на другой кристалл? Есть ли существенное ускорение в написании программы (и за счет чего)?

С уважением, Андрей

[haker_fox]

Вопрос действительно глупый, но к сожалению при просмотре форума четкого понимания не получил. Возможно подобный "глупый" вопрос стоит и перед другими людьми.

Итак есть контроллер LPC2138, к нему LCD экран 128*64, клавиатура на прерывании, пищик, EEPROM, использован канал АЦП и ЦАП, SPI. Система однозадачная. Файловой системы нет.

Понятно, что использование RTOS (в данном случае ucos) несколько затормозит систему. А какая будет от нее польза, кроме возможности перехода на другой кристалл? Есть ли существенное ускорение в написании программы (и за счет чего)?

С уважением, Андрей

ARM'ами не занимаюсь, но позволю себе ответить от лица человека, который применил ОС scmRTOS на МК AVR. На мой взгляд ваш вопрос не имеет смысла, ибо не указано, какими вычислительными задачами занимается ваша система. А в таком случае посмотрите ветки по AVR, операционным системам и по ARM. Преимущества применения RTOS обсуждались не один раз...

[spf]

ARM'ами не занимаюсь, но позволю себе ответить от лица человека, который применил ОС scmRTOS на МК AVR.

Позволю себе заметить что scmRTOS переехала -- scmRTOS on SF.net.

[IgorKossak]

ARM'ами не занимаюсь, но позволю себе ответить от лица человека, который применил ОС scmRTOS на МК AVR.

Позволю себе заметить что scmRTOS переехала -- scmRTOS on SF.net.

По прежнему адресу она пока ещё тоже наблюдается.

[spf]

По прежнему адресу она пока ещё тоже наблюдается.

Но там и тут свежих версий не появится.
"
Version 3.00beta has been released. scmRTOS v3 project is resided on sourceforge.net/projects/scmrtos. The RTOS v3 sources can be obtained from SourceForge Subversion (SVN) repository or from downloads page.

If you are interesting in scmRTOS v2 you can get it from scmrtos.narod.ru or from scmrtos.igpss.com.

"
" scmRTOS v2 project is frozen.

"

[beer_warrior]

Понятно, что использование RTOS (в данном случае ucos) несколько затормозит систему. А какая будет от нее польза, кроме возможности перехода на другой кристалл? Есть ли существенное ускорение в написании программы (и за счет чего)?

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

Например printf() не самая легкая функция, часто съедает место сравнимое с остальным кодом, но.... Правильно, никаких проблем с формированием строк любого вида и возможность изменить формат представления заменой двух-трех форматных флагов. Более того, копая этот код много времени спустя, легко понять, что идет на вывод, что не всегда возможно в случае супероптимальных самописных функций.

RTOS можно с некоторой натяжкой интерпретировать, как библиотеку, которая предоставляет функции разруливания приоритетов задач и арбитража доступа к аппаратным ресурам.

Обычно любой сложный код обязательно содержит флаги, которые говорят о занятости какой-либо периферии, определяют последовательность выполнения задач и их приоритет.

RTOS предоставляет все это хозяйство в удобном для работы виде,
с возможностью эти приоритеты менять быстро и без побочных последствий.

Если контроллер крутится на одной задаче (контроллер клавиатуры-индикации, опрос датчика), то RTOS скорее всего излишня. Если надо работать с двумя УАРТами, сканить клавиатуру, выводить на дисплей текущее время, писать лог в датафлэш и при этом успевать дергать ногами, RTOS позволит легко структурировать эти задачи по отдельным процессам. С возможностью легко добавлять и изымать оные из общей программы.

[Andr2I]

2beer_warrior

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

Спасибо за ответ.
Рискну еще немного продолжить эту тему. Общался с несколькими знакомыми программистами (сам я в основном "железом" интересуюсь). Я им приводил точно такой же довод, но они в один голос утверждали, что "особенности программирования идущие от программиста (творческое начало) приведут к тому, что написанное одним другому будет также чуждо как и в случае отсутствия операционной системы. Более того ОС только усложнит программу". Мне кажется это дико, поскольку ОС (как правило) стоит денег и есть умственно здоровые люди которые эти деньги тратят (аналогию с игровыми автоматами приводить не надо). Но убедить их я пока не могу.

С уважением, Андрей

[makc]

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

[Прохожий]

Рискую вызвать эмоциональные возражения в свой адрес, но тем не менее, скажу следующее - для ответственных встроенных систем RTOS не нужна. На это есть ряд причин:
1. Использование чужого софта, каковым является любая RTOS, - это бомба замедленного действия, поскольку до конца не известно какие глюки будет иметь дядино сочетание RTOS+порт.
2. Повторное использование кода - задача вполне решаемая с помощью сочетания кнопок Ctrl+C и Ctrl+V, при условии, конечно, что Вы хорошо структурируете и документируете свои тексты.
3. Реализация пвсевдопараллельности вычислительных процессов (т. е. многозадачности) и обмен данными при правильном подходе - дело достаточно простое даже при значительном количестве этих самых процессов.
4. Время, потраченное на изучение RTOS, можно смело считать выкинутым на ветер. Нового, с познавательной точки зрения, там ничего нет. Лучше потратить это время на что-то более стоящее, вот к примеру ...
5. Весь Ваш проект целиком будет работать медленнее под RTOS, чем без оной. Ну это очевидно и без меня...

В защиту своего подхода сошлюсь на методики, принятые в промавтоматике.
1. Использование де-факто LD или FBD в качестве основных языков программирования для PLC (стандарт МЭК 61131-3).
2. Полное отсутствие каких либо внешних ОС.
3. Жесткие требования к структуре программы и данных, реализуемые на уровне среды проектирования.
4. Жесткие требования к платформе, на которой реализуется проект. Она должна быть абсолютно надежной и испытанной.

Иное дело системы HMI, документирование больших объемов данных и другие задачи с большими массивами информации. Но там используются достаточно дорогостоящие методы резервирования и защиты от потери данных.

[rvk]

Ага, полностью поддерживаю, самая главная дыра это надежность RTOS. И самый прикол в том, что в каждом новом релизе новые глюки и это от тебя не зависит.
Сам был свидетелем такой истории : спроектировали ребята устройство, сделали, работает, но плохо. Начали искать глюки, нашли, много, платы перезаказывать не стали, наделали соплей
фторопластовых. Сдали.
Теперь, вместо того, чтобы переразвести плату и просто добить устройство, это ж неинтересно, надо МОДИФИЦИРОВАТЬ, мысль то инженерная не дремлет. Модифицировали, круто. Заказали. Работает, но плохо. Стали искать глюки, появилось новых, много.
И так по кругу уже четвертый раз. В итоге есть плата, красивая,
работает, но плохо...
Так вот с операционкой та же песня. Глюки будут сажать буржуи.
Наоборот, самая песня это замороженный проект. Можно смело
браться за тестирование и быть уверенным, что никто и никогда не влезет в твою операционку...

[beer_warrior]

1. Использование чужого софта, каковым является любая RTOS, - это бомба замедленного действия, поскольку до конца не известно какие глюки будет иметь дядино сочетание RTOS+порт.

Рискну задать вопрос:
А стандартную библиотеку С использовать тоже некошерно?
И все эти memcpy()/strcmp() использовать только домашнего приготовления?

[Andrew2000]

...На это есть ряд причин: ...

Пункты 2..5 - мысль понятна. А вот п.1 - так можно договириться до написания своего компилятора.

В защиту своего подхода сошлюсь на методики, принятые в промавтоматике.
1. Использование де-факто LD или FBD в качестве основных языков программирования для PLC (стандарт МЭК 61131-3).
2. Полное отсутствие каких либо внешних ОС.
...

А как, простите, LD или FBD связаны с ОС в контроллере? Если Вы не взаимодействуете с сервисами ОС - это не значит, что ОС в контроллере нет. Просто Вы (программист-технолог) про нее не знаете.
Пункты 3 и 4 вполне понятны (не понятно только какое отношение они имеют к ОС).

[makc]

1. Использование чужого софта, каковым является любая RTOS, - это бомба замедленного действия, поскольку до конца не известно какие глюки будет иметь дядино сочетание RTOS+порт.

Рискну задать вопрос:
А стандартную библиотеку С использовать тоже некошерно?
И все эти memcpy()/strcmp() использовать только домашнего приготовления?

Я видел такой пример. Человек написал свою библиотеку, в общем-то похожую на libc, но отличающуюся в некоторых существенных моментах. В частности, у memcpy в этой библиотеке был другой порядок параметров (сначала указатель на источник, потом на приемник). Долго мы ошибку искали, прежде чем добрались до этого memcpy.
Так что изобретать велосипеды с квадратными колесами это всегда очень занятно. Может занять на долго.

[haker_fox]

2Прохожий: из ваших мыслей у меня сложилось представление, что нужно разрабатывать все самому с нуля, включая железо) Просто не понятно, а откуда такая уверенность, что ОС - дыра и скопление глюков? Скорее всего, Вы с ней никогда не работали. В конце концов, ОС-обычная программа. Конечно в ней есть баги и ошибки. Но они есть и в любой (ИМХО) программе. Просто не всегда их видно) Также скорей всего доступны исходники и хорошая документация к ОС, как пример выше упомянутая мной scmRTOS. Все это позволяет сделать выводы о надежности применения операционной системы.

[Andr2I]

2Прохожий

для ответственных встроенных систем RTOS не нужна

Абсолютно согласен, более того рискну вызвать всенародное освистывание - лучше вообще отказаться от программы и реализовать на "железном" уровне (например, программируемой логике).

Использование чужого софта, каковым является любая RTOS, - это бомба замедленного действия, поскольку до конца не известно какие глюки будет иметь дядино сочетание RTOS+порт.

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

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

Без сомнения. Аналогия переход от DOS к Windows - каждая новая операционка "тормознее" старой. К сожалению (искреннему) другого пути нет.

2rvk

И так по кругу уже четвертый раз. В итоге есть плата, красивая,
работает, но плохо...

Следуя Вашему примеру, любая плата - источник потенциальной опасности.

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