Когда не нужна ОС РВ?, навеяно постом "Я написал RTOS" Опции

[Виктория]

Так как автор поста http://electronix.ru/forum/index.php?showtopic=12972
загубил на корню возможность обсуждения, я и открыла новую тему.

Вопрос может быть поставлен так - автору скорее всего и не нужна ОС РВ. Кругу задач его предметной области (ЦОС) свойственна - цикличность (каждый такт - ввод+обработка+вывод), жесткое РВ, работа с аппаратурой возможна на уровне конфигуривания специализированной библиотеки. Намерено так написала . Чем тогда это не "IsaGraf" (или любой другой пакет языков программирования ПЛК), скажем так "IsaGraf для жесткого реального времени"? Или по другому - нельзя ли применить подход МЭК к АСУТП для другой предметной области (которые также трудоемки, также требуют высокой надежности ПО и у которых уже виден базис свойств). Например, к таким задачам - ЦОС, алгоритмы функционирования информационно-измерительных систем, ...
Будет ли при этом этот новый case-инструмент альтернативой ОС РВ? Это возможно только на базе ОС РВ или самостоятельный путь развития программных технологий?

Приглашаю всех к дискуссии.

[zltigo]

Пытаюсь ответить на вопрос "Когда не нужна ОС РВ?":
- когда не знаешь, что это такое (долго изучать "новые рельсы", ...)
- когда знаешь, но не хочешь её использовать (упрусь и сделаю всё сам, ...)
- когда знаешь, но не можешь её использовать (не хватает ресурсов, ...)

Абсолютно согласен с вышеизложенным. Других причин дейстительно нет. При этом
ОБЬЕКТИВНАЯ только одна-единственная - третья.

[Evgeny_CD]

Пытаюсь ответить на вопрос "Когда не нужна ОС РВ?":
- когда не знаешь, что это такое (долго изучать "новые рельсы", ...)
- когда знаешь, но не хочешь её использовать (упрусь и сделаю всё сам, ...)
- когда знаешь, но не можешь её использовать (не хватает ресурсов, ...)

Абсолютно согласен с вышеизложенным. Других причин дейстительно нет. При этом
ОБЬЕКТИВНАЯ только одна-единственная - третья.

Я бы переформулировал так:

если после подсчета совокупной стоимости проекта стало ясно, что имеет смысл использовать более слабый (и дешевый) процессор (память) ценой

* усложнения поддержки кода (вот уволится программер, который все это написал - кто ковыряться будет?)
* отказа от использования кода этого проекта в других проектах
* отказа от использования готовых модулей сторонних разработчиков в проекте

то да, тогда имеет смысл отказаться от OS (или RTOS как разновидности OS). Но перед этим надо крепко подумать.

[SM]

если после подсчета совокупной стоимости проекта стало ясно, что имеет смысл использовать более слабый (и дешевый) процессор (память) ценой

* усложнения поддержки кода (вот уволится программер, который все это написал - кто ковыряться будет?)
* отказа от использования кода этого проекта в других проектах
* отказа от использования готовых модулей сторонних разработчиков в проекте

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

Отказ от использования в других проектах - с какого бодуна? Я как пользовалься одними и теми же подпрограммами для разных проектов на совместимых процах, так и буду.

Готовые модули - так они обычно к конкретной ОС не привязаны. Если сделаны корректно. И никто не мешает их подключить к проекту без ОС (но, конечно, 100 раз подумав, можно ли доверять разработчикам, как там с поддержкой, на сколько оптимальное решение, и т.п.)

P.S. Для AlexanderY - И что, что визнет? Ну понадобился бы еще один уровень - TCP/IP - но это все равно бы не послужило причиной поставить OS в том конкретном девайсе Для добавления задачи мне достаточно врезать еще один (или несколько) конечных автоматов в цепочку. Тем более, что единственной RTOS была бы DSP/Bios, от которой толку, как от козла молока для решения этих задач.
Про мобилы и аналогичное - согласен - там OS нужна (в первую очередь пользовательский интерфейс, запуск приложений сторонних производителей). Но вот RT вовсе не обязательно. За RT там отвечает не тот, кто за юзерскую шнягу.

[Olej]

И вот в этой области RTOS уж точно не нужна. На нее только время терять.

Я так и не пойму: из-за чего же вы так копья то ломаете?
Понятно же: для определённого класса задач вполне может быть даже оптимальным никакую OS среду. И как ничто под этот класс попадают все задачи циклического "перелопачивания" потока данных, и задачи PLC и задачи ЦОС, которые здесь упоминались - лучшие образцы того.
Второй критерий: число и разнородность подзадач, составляющих систему - как только или число или разнородность превышает некоторый предел ... всё, сосуществование их в среде OS становится оптимальнее (да вы это и сами говорите, далее, когда об "мобиле" говорите).

Готовые модули - так они обычно к конкретной ОС не привязаны. Если сделаны корректно. И никто не мешает их подключить к проекту без ОС (но, конечно, 100 раз подумав, можно ли доверять разработчикам, как там с поддержкой, на сколько оптимальное решение, и т.п.)

А что тогда "готовые модули" и что тогда OS, и где между ними проходит такой радикальный водораздел? Т.е. если вы статически компонуете задачу с ... модулем шедулера, стеком сетевых протоколов, ... и т.д. и т.п - то это "готовые модули", а если ... (что?) ... они связываются динамически, DLL или что? - так это OS?
Вон в realtime продуктах фирмы OneTarget (я их наблюдаю больше 10-ти лет) - целевая система всегда и во всех компонуется статически со всеми нужными причандалами, и только после этого только загружается на целевую платформу... (хотя OneTarget и избегает тщательно термина RTOS). Или тот жк pSOS, где всё происходит примерно так же.

P.S. Для AlexanderY - И что, что визнет? Ну понадобился бы еще один уровень - TCP/IP - но это все равно бы не послужило причиной поставить OS в том конкретном девайсе Для добавления задачи мне достаточно врезать еще один (или несколько) конечных автоматов в цепочку.

Вах-вах-вах... вот TCP/IP в качестве примера вы выбрали напрасно...
Тем более, это действительно актуально, здесь кто-то уже говорил "... я сначала посмотрю есть ли там TCP/IP..." (прошу прощения за неупоминание автора и со своих слов - чтоб долго не искать).
И какой же это вы стек TCP/IP писать станете в конечных автоматах? (я не о том, как вы его станете писать, я вам поверю, что вы его напишите - а о функциональности, о том что вы туда станете включать-писать)... Ведь единственным легитимным "законом" для IP есть RFC, их на сегодня больше 3000, некоторые до нескольких сот страниц... и написаны все так: "... в этой части настоящий RFC отменяет действие RFC XXX, YYY, ZZZ ...". Давайте посмотрим:
- разрешение адресов ARP - будем писать? или статически привяжем соответствие MAC - IP?
- протокол ICMP - будем писать? или уведомление об ошибках будем делать "своим способом"...
- а если "да" - то какие запросы ICMP будем реализовывать? - всех их там очень дохрена, вплоть до диагностики состояния физического канала - оно нам нужно?
- а маскирование IP и бесклассовую маршрутизацию - будем делать? или ну её...
- а в TCP поверх IP - алгоритм Нэйгла станем прописывать? а отсроченные подтверждения ACK? а ведь алгоритм Нэйгла с и без отсроченных подтверждений ... это, как говорят в Одессе "две большие разницы"(с), и работает совсем по-разному - можем что-то не то получить, что хотели...
- вам UDP больше люб для потоковых передач? а что, UDP будем сегментировать под размер пакета MAC? а что ARP разрешение будем запрашивать для каждого IP сегмента (что создаст проблемы, см.У.Стивенса) или на весь UDP один раз запросим ARP (так это смешение функций уровней, и дальше породит ещё многократ больше проблем, чем в 1-м случае)...
- а бродкастинг? а мультикастинг? ...
Это я так, "слегка пожонглировал" ... а в 3000 RFC x ~100 стр. (на самом деле больше) - представьте сколько там ... миллионв вопросов? и не зря RFC - >3000, потому что за более 25 лет ошибок новые RFC исправляли старые, и дополняли механизмами, закрывавшими слабые места...

Так что писать будем?

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

С RT вообще нужно поаккуратнее быть...
Почитайте вот здесь одно из мнений:
http://qnxclub.net/files/articles/RemarksO...TheMargins.html
- о том, что realtime применительно к OS - это вообще скорее рекламно-рыночный термин, чем какой другой (от себя добавлю для справки, что пишет это человек, в своё время работавший в "ядре" разработчиков систем безопасности АЭС xUSSR, а сейчас представляющий не последнее место в славной инженерной мысли города Монреаля).
Не путать с realtime целевой системой, а вот realtime OS ... ?
В гораздо большей мере OS может быть хорошо или плохо сделанной (и ещё есть самый широкоизвестный класс OS "очень плохо сделанный" - распространённость которого и дало возможность рекламно педалировать "риэлтаймовость" OS) - и это хорошо/плохо в гораздо большей мере определяет вот ту степень "риэлтаймовости".

[SM]

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

Скорее не число и разнородность, а требование к запуску задачи пользователем и добавлении новых (и возможно) сторонней разработки приложений. Если количество задач определено, и все они собраны статически, то РТОС в большинстве случаев жесткого реалтайма только жрет ресурсы, а пользы не несет. (про асутп я ничего не знаю, не был там)

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

Готовые модули - это модули, решающие какую-то реалтайм (контексте вопроса) - задачу. Например аудио-кодек G.723.1. ОС - это совокопнусть из какого-то API (может быть очень и очень разным), якобы упрощающего жизнь программистам, и диспетчера задач и прерываний. А как связывать готовые модули с программой - личное дело программиста. Но динамически думаю излишне.

P.S. Для AlexanderY - И что, что визнет? Ну понадобился бы еще один уровень - TCP/IP - но это все равно бы не послужило причиной поставить OS в том конкретном девайсе Для добавления задачи мне достаточно врезать еще один (или несколько) конечных автоматов в цепочку.

Вах-вах-вах... вот TCP/IP в качестве примера вы выбрали напрасно...
....
Так что писать будем?

Вот не надо мне тут объяснять, из чего TCP/IP состоит и что такое RFC. Я все равно остаюсь того-же мнения, что принцип программирования на КА эффективнее, чем шедулер с сохранением контекстов (если оно, конечно, не аппаратное). Писать я буду тот минимум, который необходим задаче. ARP, ICMP, броадкастинг,... короче функциональный аналог визнета, чтобы оно просто подключилось к имеющимся работающим с визнетом dhcp и собственным протоколом обмена данными. И совершенно ни на грамм не сложнее писать TCP/IP под какую-то ОС, чем сделать то же на КА.

С RT вообще нужно поаккуратнее быть...
Почитайте вот здесь одно из мнений:
http://qnxclub.net/files/articles/RemarksO...TheMargins.html
- о том, что realtime применительно к OS - это вообще скорее рекламно-рыночный термин, чем какой другой (от себя добавлю для справки, что пишет это человек, в своё время работавший в "ядре" разработчиков систем безопасности АЭС xUSSR, а сейчас представляющий не последнее место в славной инженерной мысли города Монреаля).
Не путать с realtime целевой системой, а вот realtime OS ... ?

Вот именно, что одно из мнений. Я же придерживаюсь исключительно определения, отталкиваясь от реалтайм целевой системы. Что RTOS обязана обеспечивать отклик системы за заданное время. И, кстати, та RTOS, с котороя я изредка имею дело (это DSP/Bios от TI) полностью соответствует этому.

Малость : а что, в современных АОН TCP/IP есть? Я как-то давно не отслеживаю "мир АОНов". И второй нескромный вопрос: а что за процессор, для которого Вы так тщательно байты считаете - если это не секрет, конечно?

Процессор у нас самодельный. http://www.venus.ru/news.php?id=67&arc=0&sct=1
TCP/IP в АОНах нет. Не одними АОНами

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

Да не совсем она там нормальная. Всего два человека делают. И я только ЦОС-куски. И никто более точно в коде не разберется, хотя бы потому, что процессор имеет модифицированную систему команд.

[Olej]

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

Готовые модули - это модули, решающие какую-то реалтайм (контексте вопроса) - задачу. Например аудио-кодек G.723.1. ОС - это совокопнусть из какого-то API (может быть очень и очень разным), якобы упрощающего жизнь программистам, и диспетчера задач и прерываний. А как связывать готовые модули с программой - личное дело программиста. Но динамически думаю излишне.

Я не о том говорил: а чем тогда RTOS (не-RT-OS) отличается от большого набора готовых модулей (планировщик, стек сети, файловые системы, ... много-много) - из которых в целевую систему мы можем выбрать только те ... готовые модули , которые требуются в этой системе.
Чем принципиально отличается одно от другого?

Вот не надо мне тут объяснять, из чего TCP/IP состоит и что такое RFC.
...
Писать я буду тот минимум, который необходим задаче. ARP, ICMP, броадкастинг,... короче функциональный аналог визнета, чтобы оно просто подключилось к имеющимся работающим с визнетом dhcp и собственным протоколом обмена данными. И совершенно ни на грамм не сложнее писать TCP/IP под какую-то ОС, чем сделать то же на КА.

Я и не собирался вам ничего объяснять... тем более что обстоятельно это "объяснять" заняло бы несколько тысяч страниц, и явно не для форума занятие ...
И вовсе не высказывал сомнения, что вы напишете стек протоколов...
Я как-раз и хотел услышать, что "писать я буду тот минимум," - а это значит, что в этом неполном (логически неполном!) минимуме всегда вылезут внутренние противоречия, и если сегодня "оно просто подключилось к имеющимся работающим" ... то это ни на грамм не увеличивает гарантии, что завтра в других условиях оно тоже подключится...
Именно поэтому, во многих TROS есть несколько стеков TCP/IP: tinny (без транзитного форвардинга, например), IPv4, IPv6, ... - и потребитель уже из компромисса требуемых ресурсов и возможностей в целевую систему скомпонует тот, который его устраивает ... но что самое интересное: если через 1 год окажется, что функциональности не хватает всё-таки - то перекомпоновать с другим стеком можно целевую систему за 10 минут.

Сообщение отредактировал Olej - Mar 13 2006, 08:44

[SM]

Я не о том говорил: а чем тогда RTOS (не-RT-OS) отличается от большого набора готовых модулей (планировщик, стек сети, файловые системы, ... много-много) - из которых в целевую систему мы можем выбрать только те ... готовые модули , которые требуются в этой системе.
Чем принципиально отличается одно от другого?

Тем, что файловые системы, стеки сетей, и т.п. - это не есть часть RTOS. Это системные задачи, которые под ней крутятся. Другое дело, что они могут быть либо встроены в ОС (худший случай), либо идти дополнительным пакетом (как например NDK для TI DSP). А к самой ОС относится только ядро и сервисы вокруг него - синхронизация, доступ к I/O, интерфейс к драйверам, и т.п. То есть собственно ядро.

Вот не надо мне тут объяснять, из чего TCP/IP состоит и что такое RFC.
...
Писать я буду тот минимум, который необходим задаче. ARP, ICMP, броадкастинг,... короче функциональный аналог визнета, чтобы оно просто подключилось к имеющимся работающим с визнетом dhcp и собственным протоколом обмена данными. И совершенно ни на грамм не сложнее писать TCP/IP под какую-то ОС, чем сделать то же на КА.

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

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