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

[Andr2I]

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

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

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

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

[Andr2I]

2Прохожий

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

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

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

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

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

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

2rvk

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

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

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

[Прохожий]

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

Многие так и поступают.

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

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

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

И еще забыли. С каждой новой ОС требуется все больше ресурсов.
Другой путь есть. А то, что творится в области программирования и ОС, в том числе и встроенных систем, на мой взгляд, напоминает театр абсурда. Лично я в этом стараюсь участия не принимать. В принципе - это дело вкуса.

2Прохожий: из ваших мыслей у меня сложилось представление, что нужно разрабатывать все самому с нуля, включая железо)

Про "железо" немного не понял. Если речь идет о МК, то нет - разрабатывать его не надо, а вот изучать матчасть строго необходимо, тщательнейшим образом, начиная с программной модели и заканчивая временными параметрами. Ассемблер выбранного вычислителя просто обязательно. Если же подразумевается обвязка МК, то да - ИМХО, тот, кто пишет программу должен делать обвязку.

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

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

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

Компиляторы с ЯВУ, по возможности, просто не использовать. Вот и все. Средства должны быть соразмерны со сложностью задачи. А если взял грех на душу, то проверять нещадно...

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

Я прекрасно осведомлен о наличии ОС в ПЛК. Но в отличие от всяких новомодных RTOS эта штука прошла проверку временем, хотя иногда и с ней случаются сбои. Результаты этих сбоев, к стати, выглядят не очень... Речь, однако, была не об этом.
Технологу-программисту тоже нужны все прелести, якобы предоставляемые RTOS - переносимость, скорость программирования и т. д. Однако, разработчики ПЛК имея внутри достаточно мощный вычислитель, почему-то отказались не только от внешнего ЯВУ, но и от внешней оболочки и предпочли примитивнейшие языки типа Ассемблера, совместимые исключительно внутри линейки ПЛК одного типа. Почему, как Вы думаете?

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

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

[Andy Mozzhevilov]

И еще забыли. С каждой новой ОС требуется все больше ресурсов.
Другой путь есть. А то, что творится в области программирования и ОС, в том числе и встроенных систем, на мой взгляд, напоминает театр абсурда. Лично я в этом стараюсь участия не принимать.

Известная позиция. Посмотреть со стороны и покидать камней, не особо разбираясь в сути.
Французы вот лягушек едят, фу какая гадость? Как же это можно? Я пробовал - на вкус та же курица.
Но зато я хоть могу сейчас аргументировать. Это аналогия.

Уверенность по поводу ОС проистекает из просмотра кода от УКОС, как ее самой, так и портов к ней. Все решения достаточно тривиальные и громоздкие. Не говоря о явных проколах.

Может просветите нас как о громоздких решениях, так и о явных проколах?
С примерами, чтоб не быть голословным?

[Прохожий]

Известная позиция. Посмотреть со стороны и покидать камней, не особо разбираясь в сути.
Французы вот лягушек едят, фу какая гадость? Как же это можно? Я пробовал - на вкус та же курица.
Но зато я хоть могу сейчас аргументировать. Это аналогия.

По поводу лягушки...Ну, Вы молодец. Я в этом плане более консервативен.
А насчет камней и сути все очень просто. Я ни разу не видел ни одного сотового телефона, который бы не "глючил". Купил эту гадость ребенку, теперь жалею. Ребенок, когда вырастет будет считать, что так и положено, когда девайс вроде бы в общих чертах работает, но слегка "глючит". По моему, такие устройства просто не должны иметь места.

Может просветите нас как о громоздких решениях, так и о явных проколах?
С примерами, чтоб не быть голословным?

Первое, что бросается в глаза это обилие макросов OS_ENTER_CRITICAL() и ответной части OS_EXIT_CRITICAL(). Похоже нормальной системе прерываний капец, поскольку между этими макросами вставлены достаточно большие куски текста.
Об остальном чуть позже, если можно. Нужно собраться с мыслями, чтобы действительно не быть голословным.

[Andy Mozzhevilov]

А насчет камней и сути все очень просто. Я ни разу не видел ни одного сотового телефона, который бы не "глючил". Купил эту гадость ребенку, теперь жалею. Ребенок, когда вырастет будет считать, что так и положено, когда девайс вроде бы в общих чертах работает, но слегка "глючит". По моему, такие устройства просто не должны иметь места.

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

Первое, что бросается в глаза это обилие макросов OS_ENTER_CRITICAL() и ответной части OS_EXIT_CRITICAL(). Похоже нормальной системе прерываний капец, поскольку между этими макросами вставлены достаточно большие куски текста.

А как вы еще обеспечите атомарные операции, которые не поддерживаются непосредстенно ядром
процессора? Потом критические секции там сделаны таким образом, чтобы закрывать минимально
необходимый набор действий. То есть надолго прерывания запрещены не бывают.
Действительно большие критические секции есть в функциях создания и удаления задач.
Но эти действия происходят при инициализации или переконфигурации системы.
В остальных случаех секция закрывает несколько ассемблерных команд.

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

Да уж соберитесь. И побыстрее, пока у меня настроение располагает _аргументированно_ поспорить.