QNX opensource! Опции

[Nixon]

Сегодня QSSL открыла исходные коды QNX 6 (правда под собственной лицензией, но все равно для всех).
Более подробно -> www.qssl.com

[zltigo]

Явно опоздали.

[Nixon]

и мое мнение в разговоре с товарищем, работающим там, было таким же - опоздание на 5 лет.

[zltigo]

опоздание на 5 лет.

Когда писал пост, написал "опоздали на пять лет". Потом убрал явное указание срока

[vshemm]

А зачем вообще нужны исходники микроядра (кроме как для академических целей), ведь весь "прикладной" функционал реализован не в нем?.

[jorikdima]

а что случилось 5 лет назад?

[zltigo]

а что случилось 5 лет назад?

Была преодолена некоторая грань, когда системы весовой категории QNX шагнули в дешевые массовые устройства. Пошли многочисленные окололинуксовые поделки, системы поддерживаемые производителями камней, системы с более гуманными выплатами.... Да тот-же Windows CE до работоспособного состояния довели.

[avv]

to vshemm: Дойдет и до остального, будем надеяться... CEO QNX Dan Dodge в интервью на OSNews заявил, что откроют всё... со временем. (Ну или почти всё)

[AlexandrY]

Да, если они реально откроют middleware, это будет конец всем конкурентам.

Все таки QNX это операционка настоящего реального времени, а не искусственный гибрид типа RTAI+Linux.
Плюс это сразу движок с интегрированной мультипроцессорностью, а скоро все камни станут такими.
Плюс на уровне ядра механизмы для борьбы с зависаниями.

Опозданием тут и не пахнет.
Самое время. Нормальные ядра с MMU только начинают выходить из тени.
Такого middleware и интегрированных тулсов как в QNX никто предложить не сможет.

to vshemm: Дойдет и до остального, будем надеяться... CEO QNX Dan Dodge в интервью на OSNews заявил, что откроют всё... со временем. (Ну или почти всё)

[zltigo]

..это будет конец всем конкурентам.

Или будет, или нет...

Плюс это сразу движок с интегрированной мультипроцессорностью, а скоро все камни станут такими.

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

[vshemm]

В общем дело весьма темное - получится у них - хорошо, не получится - мир для пользователей тоже не рухнет

У кого? У производителя акустики? Тут шансов больше у гугля со своей "убийцей" Windows CE, имхо.

А опоздание заключается в том, что подобный шаг конкуренты сделали давно и, в результате, очень сильно потеснили QNX. И теперь позиции нужно завоевывать, а не оборонять (как было бы 5-6 лет назад).
К слову, интергированная мультипроцессорность - это не чудо, а давно стандарт де факто. Механизмы борьбы с зависаниями (если я правильно понял) - тоже. Ну а НАСТОЯЩЕЕ реальное время делается в железе

[AlexandrY]

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

У кого? У производителя акустики? Тут шансов больше у гугля со своей "убийцей" Windows CE, имхо.

А опоздание заключается в том, что подобный шаг конкуренты сделали давно и, в результате, очень сильно потеснили QNX. И теперь позиции нужно завоевывать, а не оборонять (как было бы 5-6 лет назад).
К слову, интергированная мультипроцессорность - это не чудо, а давно стандарт де факто. Механизмы борьбы с зависаниями (если я правильно понял) - тоже. Ну а НАСТОЯЩЕЕ реальное время делается в железе

[vshemm]

QNX бесплатен? Мягко говоря, это не так Да, можно получить среду разработки и часть исходников "нахаляву", но, чтобы применить их, нужно покупать лицензии. Причем, несколько сотен долларов за 1 рантайм лицензию - это перебор.
Вот пара конкурентов.
- WindowsCE. Прекрасная документация, реальное время, GUI, стеки и т.п. А для прикладного программиста тут просто рай - редуцированный win32 api, MFC, .NET framework, Mobile3D, широкие мультимедийные возможности и пр. В 6.0 версии появилась возможность создавать драйвера работающие в режиме пользователя (если производительности хватает). Поддержка большого количества устройств, т.к. крупные (и не очень) производители давно предоставляют драйвера. При этом стоимость рантайм лицензии - от 4$ (без GUI) до 24$. Да, поддержки SMP нет, но это не так страшно
- RTOS32 (http://www.on-time.com/rtos-32.htm). Здесь рантайм лицензия бесплатна, есть SMP, но поддерживается только x86 архитектура. А во всем остальном полный порядок - хорошая документация, реальное время, стеки, драйвера, GUI.
Можно еще вспомнить vxWorks, LynxOS и многие другие, более "легковесные" ОС. У всех исходники доступны (причем давно), а характеристики не уступают той же QNX, причем сами ОСи стоят намного дешевле оной. Поэтому, пока QSS не будет драть втридорога с трудящихся, раскрытие сорцов будет представлять скорее академический интерес (или пока не получит соответствующие лицензии и соответствия стандартам для применения в тех областях, где цена не важна). Так что опоздание налицо
З.Ы. Когда я говорил про НАСТОЯЩЕЕ реальное время и железо, я подразумевал реализацию задач в железе (например, в FPGA), а не на уровне софта, ибо никакая самая расчудесная ОС не обеспечит "железные" характеристики, особенно время реакции, детерминизм и надежность.

[Gate]

QNX 6, он же нейтрино, никому особенно не интересен, вот его и открыли. Версию 4.25 они открывать не собираются, а это именно тот продукт, на котором QSSL сделала имя, и она сильно не бесплатна (и вроде как сертифицирована МО России - или я не прав?). Предыдущая версия 2, расчитанная на i286, до сих пор используется в ответственных приложениях.

[AlexandrY]

А чувствую здесь опять сталкиваются разные парадигмы программирования.

Я вижу ситуацию так, что есть слой специалистов выращенных на толстых платформах.
Они всегда писали для платформ с установленным и портированным софтом, никогда не работали с JTAG и думают что ядро нифига не значит для них поскольку никогда ниже уровня данного им API не спускаются, даже схем своих платформ никогда не видели.
Для этой категории ничего не меняется.

И есть армия девелоперов поднявшихся от AVR-ов и PIC-ов, которые прошли через uCOS, freeRTOS и т.д. и которые все писали сами и middleware для них было космосом. Теперь на их рынок лезут 32-х битные чипы с MMU. И люди лихорадочно ищут адекватный этим чипам софт.
Идут попытки портировать Linux то на LPC, то на STR91x , то на SAM7
Ясно, что эти люди вообще не превыкли платить за софт. Ни о каких лицензиях речи быть не может.
На этот контингент QNX и ориентируется. Мало ли что они пишут про лицензирование, скачивать то обещают давать все и middleware в том числе и главное все тулсы самые навороченные.
Каждый себе на уме.
QNX видимо ждет вторичной волны когда дивайсы на его базе поднимутся и начнут легализоваться.

Может для WinCE дают на халяву VС++ для сборки оси?
Полных исходников VxWorks я нигде найти не смог, где вы их видели?
RTOS32 как я понимаю вообще не в контексте.
Доступные варианты на базе линукса не привлекают из-за сильной раздробленности того же middleware, хаоса в дистрибутивах, нериалтаймности и плохой документированности.
LinxOS откровенно слабее QNX. Нет ни аудио ни видео подсистемы, ни GUI, вообщем морально подустаревшая ось.
Т.е. считаю что реальных конкурентов названо не было.

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

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

QNX бесплатен? Мягко говоря, это не так Да, можно получить среду разработки и часть исходников "нахаляву", но, чтобы применить их, нужно покупать лицензии. Причем, несколько сотен долларов за 1 рантайм лицензию - это перебор.
Вот пара конкурентов.
- WindowsCE. Прекрасная документация, реальное время, GUI, стеки и т.п. А для прикладного программиста тут просто рай - редуцированный win32 api, MFC, .NET framework, Mobile3D, широкие мультимедийные возможности и пр. В 6.0 версии появилась возможность создавать драйвера работающие в режиме пользователя (если производительности хватает). Поддержка большого количества устройств, т.к. крупные (и не очень) производители давно предоставляют драйвера. При этом стоимость рантайм лицензии - от 4$ (без GUI) до 24$. Да, поддержки SMP нет, но это не так страшно
- RTOS32 (http://www.on-time.com/rtos-32.htm). Здесь рантайм лицензия бесплатна, есть SMP, но поддерживается только x86 архитектура. А во всем остальном полный порядок - хорошая документация, реальное время, стеки, драйвера, GUI.
Можно еще вспомнить vxWorks, LynxOS и многие другие, более "легковесные" ОС. У всех исходники доступны (причем давно), а характеристики не уступают той же QNX, причем сами ОСи стоят намного дешевле оной. Поэтому, пока QSS не будет драть втридорога с трудящихся, раскрытие сорцов будет представлять скорее академический интерес (или пока не получит соответствующие лицензии и соответствия стандартам для применения в тех областях, где цена не важна). Так что опоздание налицо
З.Ы. Когда я говорил про НАСТОЯЩЕЕ реальное время и железо, я подразумевал реализацию задач в железе (например, в FPGA), а не на уровне софта, ибо никакая самая расчудесная ОС не обеспечит "железные" характеристики, особенно время реакции, детерминизм и надежность.

[Andrew2000]

.... Теперь на их рынок лезут 32-х битные чипы с MMU. И люди лихорадочно ищут адекватный этим чипам софт. ... QNX видимо ждет вторичной волны когда дивайсы на его базе поднимутся и начнут легализоваться. ...

Полностью согласен. Сделали они 6.0 бесплатной для разработки и настольных систем - был всплеск активности. Сейчас, видимо, хотят увидеть то-же во встраиваемых системах - почему нет.
Альтернатив такого уровня, действительно, не так много. А то расплодилось PLC на WinXP
Когда я (года 1,5 назад) приценивался к LynxOS - вышло, что цена одного порядка с QNX была - система разработки + драйвера + лицензии на несколько десятков устройств.
А по исходникам - ну, у QNX были недоступны, а у LynxOS ~$150k - что то-же самое.

[v_shamaev]

QNX 6, он же нейтрино, никому особенно не интересен, вот его и открыли. Версию 4.25 они открывать не собираются, а это именно тот продукт, на котором QSSL сделала имя, и она сильно не бесплатна (и вроде как сертифицирована МО России - или я не прав?). Предыдущая версия 2, расчитанная на i286, до сих пор используется в ответственных приложениях.

Сертифицирована. Готовят и 6-ю, как я понял Зыля. Причем серитфицированна настолько, что вояки хотели и на десктопы ее себе поставить. А насчет "никому" - это вы погорячились.

[?ELF]

Причем серитфицированна настолько, что вояки хотели и на десктопы ее себе поставить.

QNX на российских военных десктопах ― это круто!
Как обычно, «из огня, да в полымя».
Или «если уж любить ― так королеву! Если ... ― так миллион!»

---
P.S. а вообще, «канадец и русский ― братья навек!»
Почему бы и нет?

[v_shamaev]

QNX на российских военных десктопах ― это круто!
Как обычно, «из огня, да в полымя».
Или «если уж любить ― так королеву! Если ... ― так миллион!»

---
P.S. а вообще, «канадец и русский ― братья навек!»
Почему бы и нет?

Закладок в винде они бояться. Винда тоже есть сертифицированная - но там нужно каждый экземпляр проверять, а от QNX в SWD исходники есть, они и проверяли. Я в лет 10 назад пробовал QNX в качестве десктопной операционки, именно 4-ку, но вполне полноценна она только как среда разработки, офисные приложения частью только портированнны были из-под Linux-а, для которого и самого тогда не богато было в этой части. Зато сеть и интернет, а так же эффективное использование железа - все классно.

[zltigo]

Закладок в винде они бояться. Винда тоже есть сертифицированная - но там нужно каждый экземпляр проверять....

Сертифицированный в России Windows передавался на исследование с исходниками и соответственно бинарные копии распространяются не от Microsoft а от "компетентых" органов.

[v_shamaev]

Сертифицированный в России Windows передавался на исследование с исходниками и соответственно бинарные копии распространяются не от Microsoft а от "компетентых" органов.

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

[KirillS]

Мои 2 копейки: исходники VxWorks далеко не бесплатны. Полгода назад мне WindRiver от большой любви ко мне(?) предложила купить исходники VxWorks 5.5 за $100,000 (согласились отдать за $55,000).

GreenHills же продавала свою RTOS Integrity вместе с исходниками... Теперь вот и QNX... Теперь черед WindRiver.

[jorikdima]

Мои 2 копейки: исходники VxWorks далеко не бесплатны. Полгода назад мне WindRiver от большой любви ко мне(?) предложила купить исходники VxWorks 5.5 за $100,000 (согласились отдать за $55,000).

GreenHills же продавала свою RTOS Integrity вместе с исходниками... Теперь вот и QNX... Теперь черед WindRiver.

Чеб такого разработать, чтоб за 100 к$ продать...

[Olej]

А зачем вообще нужны исходники микроядра (кроме как для академических целей), ведь весь "прикладной" функционал реализован не в нем?.

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

- открыты исходники не микроядра - а очень значительной части middleware, чтоб представить объём выложенного - вот:

Код

Размер:    82,9 МБ (86 984 353 байт)
На диске:  195 МБ (205 008 896 байт)
Содержит: Файлов: 34162; папок: 23282

- это размер дерева SVN ... только файлов исходного кода >30 000 файлов, кроме микроядра выложены: менеджер процессов, менеджер памяти, менеджер корневой файловой системы, BSP & startup для x86 BIOS систем, вся стандартная библиотека libc, много системных утилит, и драйверов ... и много чего ещё, даже трудно всё перечислить... и всё из представленного можно собрать.

- что пока не выложено - это всё, что касается графической системы Photon ... но официально обещано, что каждые 3 месяца будет выкладываться примерно такой объём ... главная сложность в задержке - это то, что весь объём перед выкладыванием должен пройти полную ревизию на чистоту, должны быть подчищены неприличные комментарии etc.; обещано, что выложено будет всё.

- кое-что поподробнее можно посмотреть здесь (и рядом ) :
http://qnxclub.net/modules.php?name=Forums...&highlight=
а уж, конечно, совсем по-серьёзному - на сайте QSSL (кстати и на новом сайте открытом специально для community ... все URL в указанной мной теме)
Может кому-то пригодится

[vshemm]

Исходники были скачаны сразу же.
Сорцы довольно часто обновляются, уже 53 ревизии прошло; качество их неплохое - изучать можно.
Кода файловых систем там, к слову, нет. Как и большинства драйверов. Впрочем, некоторые драйвера доступны в отдельных BSP.
В значительная части middleware и libc использовались другие GPL проекты, ай яй яй Много знакомых библиотек: ucl, ncurses и т.д. Часть этого кода была выкуплена (?), часть так и осталась GPL. Ну, их юристам виднее.
Занимательный todo (\services\system\doc\todo), честный. Как и предполагалось, с масштабированием на CPU существуют проблемы, да и сам спорадический шедулер недоделан

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

P.S. Чуть не забыл. Шедулер масштабируется как О(n) не только на CPU, но и на количество тредов. Другими словами, при увеличении работающих тредов в системе время шедулирования увеличивается линейно.

Сообщение отредактировал vshemm - Oct 12 2007, 11:44

[prog_sun]

AlexandrY
А реальное время на FPGA не сделать. Тут подмена терминов.

А подробнее можно? На чем же тогда "реальное" время можно сделать? я не имею в виду операционки я говорю о железе.

[DRUID3]

А чувствую здесь опять сталкиваются разные парадигмы программирования.

Я вижу ситуацию так, что есть слой специалистов выращенных на толстых платформах.
Они всегда писали для платформ с установленным и портированным софтом, никогда не работали с JTAG и думают что ядро нифига не значит для них поскольку никогда ниже уровня данного им API не спускаются, даже схем своих платформ никогда не видели.
Для этой категории ничего не меняется.

И есть армия девелоперов поднявшихся от AVR-ов и PIC-ов, которые прошли через uCOS, freeRTOS и т.д. и которые все писали сами и middleware для них было космосом. Теперь на их рынок лезут 32-х битные чипы с MMU. И люди лихорадочно ищут адекватный этим чипам софт.
Идут попытки портировать Linux то на LPC, то на STR91x , то на SAM7
Ясно, что эти люди вообще не превыкли платить за софт. Ни о каких лицензиях речи быть не может.
На этот контингент QNX и ориентируется. Мало ли что они пишут про лицензирование, скачивать то обещают давать все и middleware в том числе и главное все тулсы самые навороченные.
Каждый себе на уме.
QNX видимо ждет вторичной волны когда дивайсы на его базе поднимутся и начнут легализоваться.

Очень маловероятно, что компания, распространяющая коммерческий продукт собирается привлечь GNU потребителей, которые уже успели убедиться, что бесплатное такое же точно дрянное как и платное . А лично мне, человеку далекому(надеюсь пока ) от вмешивания в код ОС абсолютно не хочется платить за то, что открылась часть исходников (да хоть все). Ну что бы сейчас у меня изменилось открой Билли коды на "висту" но требуя платы за нее все равно?

Может для WinCE дают на халяву VС++ для сборки оси?

Во-первых VС++ "мелкософт" раздает нашару. Во-вторых зачем, собственно, собирать "ось" с закрытым исходным текстом?

Полных исходников VxWorks я нигде найти не смог, где вы их видели?
RTOS32 как я понимаю вообще не в контексте.
Доступные варианты на базе линукса не привлекают из-за сильной раздробленности того же middleware, хаоса в дистрибутивах, нериалтаймности и плохой документированности.
LinxOS откровенно слабее QNX. Нет ни аудио ни видео подсистемы, ни GUI, вообщем морально подустаревшая ось.
Т.е. считаю что реальных конкурентов названо не было.

Ну есть еще такая замечательная ось как MINIX 3, это та, которая поставляеЦЦо с огромным мануалом в виде учебника (или наоборот ). Многие, думаю, начинали изучать ОС по идеям Таненбаума. Кстати довольно таки прогрессивным и до конца не реализованным и на сегодня. Его ОС микроядерная да еще с обозримым кодом (!!!) 30 000 строк исходников ядра (которые все время вычищаются от багов) против 6 миллионов (если не ошибаюсь) в современном варианте детища Линуса Торвальдса (которые уже давно просто тестируются). Мало того, не знаю если честно когда появилась QNX но что-то мне подсказывает, что не без идей этого амстердамского препода (да и линукс то сам на почве Minix и споров с Торвальдса с Таненбаумом родился). Я так посмотрел эту ось, ну для ПК думаю она нафиг не надо, а вот для встроенных систем - просто рай. Правда, сейчас у нее не так много сторонников-волонтеров как у той же Linux, но при правильной пропаганде думаю она стала бы очень популярной платформой для встроенных систем, тем более, что ее создатель стремиться написать ОС которая годами сможет работать без сбоев, что думаю для медицинских, космических и например военных (а почему нет?) систем это было бы просто неоценимо. Единственное что - лицензия Minix - BSD.

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

Может быть, я с QNX не работал никогда, а как это выглядит, я о визуальности, а можно скришоты?

А реальное время на FPGA не сделать. Тут подмена терминов. На FPGA можно сделать пару фиксированых однопоточных DSP задач.
В системе реального времени состав и количество задач всегда меняется. Задачи уничтожаются и создаются в реальном времени! FPGA грузится в реальном времени?

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

Сертифицированный в России Windows передавался на исследование с исходниками и соответственно бинарные копии распространяются не от Microsoft а от "компетентых" органов.

Я только начинаю разбираться в теории ОС, потому может быть мой вопрос будет несколько наивным, но как вообще собственно можно в разумные сроки разобраЦЦо в десятках миллионах строк исходного кода? И что в самом деле есть допустим человек который ответственен за такой-то кусок винды, может отчитаться по всем функциям и переменным и компонентам с которыми они взаимодействуют??? Что-то мне очень слабо вериться. Благо если в самой «мелкософт» есть такая корпоративная организация. И что, даже "пасьянс косынка" был перелопачен? И он точно не взаимодействует с ядром? Гхм... Мне кажется, что это все сродни замораживанию трупов за их деньги при жизни. Ну знаете прикол такой, платишь бабло, умрешь, а тя заморозят, мол де высокоразвитые потомки придумают как оживить... Вот и здесь типо честный бизнес с "0" эффективностью...

[zltigo]

Я только начинаю разбираться в теории ОС, потому может быть мой вопрос будет несколько наивным, но как вообще собственно можно в разумные сроки....

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

[prog_sun]

(AlexandrY @ Sep 15 2007, 16:21) *

А реальное время на FPGA не сделать. Тут подмена терминов. На FPGA можно сделать пару фиксированых однопоточных DSP задач.
В системе реального времени состав и количество задач всегда меняется. Задачи уничтожаются и создаются в реальном времени! FPGA грузится в реальном времени?

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

Так что думаю будущее все-таки за ПЛИС - хорошо сказано, тоже так думаю. Но не могу "понять" почему реальное время на FPGA не сделать, даже на современнос состоянии его развития. Что есть альтернатива? Можно что то другое использовать что будет таким же быстройдействующим?


На FPGA можно сделать пару фиксированых однопоточных DSP задач. я это имел в виду.
В системе реального времени состав и количество задач всегда меняется. Задачи уничтожаются и создаются в реальном времени! FPGA грузится в реальном времени? - а вот с такого рода задачами еще не сталкивался.
Тут подмена терминов а что вы подразумеваеете под системой реального времени?

Для начала бы мне хватило что бы ОС реального времени справлялась с "пару фиксированых однопоточных DSP задач" хотя бы для начала так. А так я систему реального времени представляю себе как "отработка железной логики" затем передача данных в комп.

[vshemm]

Вот ведь привязались в ПЛИСинам Я привел их только как пример. А по факту - больше 2-3 dsp задач обычно и не нужно там, где речь идет о "реальном времени". А иногда эти задачи решаются вообще механически, и потому, что другой альтернативы нет. В общем-то, удел ОС - это HMI. Просто представьте себе, что ЗУР (зенитная управляемая ракета) летит под управлением ОС жесткого реального времени QNX (vxWorks, WinCE и т.п.). Бред. Подобных примеров можно привести множество.

По упомянутым ОСям. vxWorks поставляются с исходниками, стоит это около 50к зеленых (цена очень договорная, может варьироваться от 0 до много). eVC++ поставляется вместе с Platform Builder - системой для сборки WinCE 5.0 и ниже. Для 6.0 версии - это плагин к VS 2005. RTOS - как раз в контексте, оч приятная системка, с кучей драйверов, норм документацией, и код простой и понятный. MINIX3 - это скорее академическая ОС, чем прикладная. Хотя ее автор - Танненбаум - создал еще штук 5 коммерческих ОС, включая распределенные. Так что это не только препод, но и практик Хотя, имхо, для начального изучения принципов операционных систем больше подходит Prex (http://prex.sourceforge.net). Чистейший код на Си, классические алгоритмы прям как из учебника, и небольшой размер.

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

[?ELF]

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

+100%
«Если на небе зажигаются звёзды — значит, это кому-то нужно».
Если бы существовала единственнаям «ось на все времена», давно бы уже «копья ломать перестали».

[CaPpuCcino]

немного в офтоп

А реальное время на FPGA не сделать. Тут подмена терминов. На FPGA можно сделать пару фиксированых однопоточных DSP задач.
В системе реального времени состав и количество задач всегда меняется. Задачи уничтожаются и создаются в реальном времени!

на мой взгляд, система реального времени - система в которой время между приходом возмущения и вырабатываемым ответом на него меньше некоего критического времени (т.е. система в которой невыполнение данного неравенства приводит к нарушению функциональности). так что понятие реального времени зависит от контекста (от поставленной задачи или круга задач).
таким образом ОСРВ характерна для встроенных приложений, а встроенные приложения характеризуются ограниченным и стабильным набором выполняемых задач. (поэтому на мой взгляд постулаты ваши приведённые выше изначально неверны.)
так что любая система(в том числе и ПЛИС) может быть системой реального времени (не имею в виду ОС), если улсовие Т ответа < Т критическое выполняется для поставленных ей задач(тот же самый пульт от телевизора может считаться системой реального времени, потому что человеку не приходится идти поспать пока каналы всё-таки переключатся, и переключать каналы он может быстрее чем он сможет понять что на них показывают) абсолютное время ответа не имеет никакого значения.

[prog_sun]

vshemm
[А по факту - больше 2-3 dsp задач обычно и не нужно там, где речь идет о "реальном времени"./i]
согласен, мне только такие задачи и встречались. Я вот про вот это спрашивал [i]В системе реального времени состав и количество задач всегда меняется. Задачи уничтожаются и создаются в реальном времени! просто мне еще такие задачи не попадались вот и интересно стало что это за задача которая может уничтожаться в системе реального времени, это фактически мозг получается т.е система наделенная интеллектом. Если под этим понимать вот такую задачу: Просто представьте себе, что ЗУР (зенитная управляемая ракета) летит под управлением ОС жесткого реального времени QNX то это критическая задача по быстродействию. Хотя вроде в интеренете читал статьи что QNX используется в самолетах F-16. А вот на счет того что поставить такую ось на ракету такое не слышал, хотя со времен выхода плейстейшен 2 помню там хвастались говорили что в системе применен риск процессор такой производительности что если его поставить на ракету то вполне справится с видеопотоком и принятием решения по управлению. Речь помоему шла о том что по сличению изображения обьекта найти цель. Если это не был рекламный трюк.
Я года два три назад вплотную занялся QNX хотел найти операционку у которой бы время между приходом возмущения и вырабатываемым ответом на него меньше некоего критического времени . У меня это критическое время было 1 нс, ну максимум 10 нс( и то это в самом худшем варианте). В интернете тогда из всего многообразия осей выбрал QNX как самую быстродействующую. Когда начал изучать его то узнал что у него это время приблизительно где то 1 микросекунда. Да еще мне тогда не понравилось то что у нее код закрыт. Короче в итоге ее тогда с компа снес. Может с тех пор что то новое появилось, не знаю.
MINIX3 - это скорее академическая ОС, чем прикладная. А почему именно с нее надо начинать изучение осей. Если уж на то пошло можно младшие версии взять, они значительно легче. А поняв основы можно тогда на Миникс3 посмотреть как "монтируются" современные быстродействующие интерфейсы, и на основе двух этих знаний сделать нечто свое
А вот про это для начального изучения принципов операционных систем больше подходит Prex буду в интернете читать интересно все же

[zltigo]

хотел найти операционку у которой бы время между приходом возмущения и вырабатываемым ответом на него меньше некоего критического времени . У меня это критическое время было 1 нс...

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

[vshemm]

В системе реального времени состав и количество задач всегда меняется. Задачи уничтожаются и создаются в реальном времени!
Это бардак тогда какой-то или мозг, да Мне почему-то казалось, что динамическое создание/удаление задач - первый шаг к плохому дизайну. Пример. Как уже говорил, шедулер QNX масштабируется как O(n) на количество нитей. Другими словами, время его отработки линейно возрастает с их количеством. Не зная заранее сколько нитей будет в системе, как мы можем гарантировать задержку, вносимую шедулером? Не станет ли она недопустимо велика? Но даже это не самое страшное. При большом количестве нитей возникает риск множественных блокировок. И это отследить намного сложнее. Все помнят луноход на марсе с vxWorks на борту? Его приходилось резетить с земли каждые пару часов именно из за этого.
Есть, конечно, задачи друго рода, например веб сервера или базы данных. Тут да, потоки создаются только в путь. Но это не совсем задача реального времени, т.к. нет дедлайна на время реакции. И потоки редко блокируются друг на друге. Зато такой подход позволяет поднять общую производительность, т.е. среднее время реакции.

Хотя вроде в интеренете читал статьи что QNX используется в самолетах F-16.
Да, но только как HMI. Т.е. если она откажет - самолет не упадет, просто пилот не увидит красивую трехмерную картинку на экране. Придется вертеть башкой и думать мозгом Собственно, здесь важно не низкое время реакции, а отказоустойчивость и математика.

У меня это критическое время было 1 нс, ну максимум 10 нс( и то это в самом худшем варианте).
С такими временами об ОС нужно забыть

[zltigo]

У меня это критическое время было 1 нс, ну максимум 10 нс( и то это в самом худшем варианте).
С такими временами об ОС нужно забыть

Для начала следует забыть о контроллерах и процессорах, поскольку это один такт на Гигагерце и подумать о том, что такая задержка набегает уже на нескольких сотнях миллиметров проводника, не говоря уже о кремниевой логике.

[prog_sun]

zltigo
vshemm
Одна наносекунда, говорите? Операционная система? Извитите, но Вы похоже просто не имеете никакого представления о том, о чем пытаетесь расссуждать.

Тогда не имел представление вот и искал ось с такими характеристиками. Потом перестал искать и вернулся к отработанной технологии железная логика плюс компьютер. А так я просто рассказал историю как вышел на QNX.

Для начала следует забыть о контроллерах и процессорах, поскольку это один такт на Гигагерце и подумать о том, что такая задержка набегает уже на нескольких сотнях миллиметров проводника, не говоря уже о кремниевой логике.
Ну зачем так категорично. Хотя про "о контроллерах и процессорах" давно конечно забыли, но про кремневую логику это вы зря. Конечно до GaAs, SiGe далеко, но все же с 1 нс кремний справляется. А для каких то приложений это уже система реального времени

Да, но только как HMI. Т.е. если она откажет - самолет не упадет, просто пилот не увидит красивую трехмерную картинку на экране. Придется вертеть башкой и думать мозгом smile.gif Собственно, здесь важно не низкое время реакции, а отказоустойчивость и математика.

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

[zltigo]

но про кремневую логику это вы зря.

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

[prog_sun]

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

Пожалуйста вот http://www.onsemi.com/PowerSolutions/parametrics.do?id=400 посмотрите графу где Tpd.
. А собирал я железо подсчет импульсов шириной 1 нс и выдача на комп результата.

[zltigo]

А собирал я железо подсчет импульсов шириной 1 нс и выдача на комп результата.

Читать умеем? Я не спрашивал найти в интернете быстродействующий но ТУПОЙ счетчик на дивной ЭСЛ логике.
Я спрашивал про реализацию Вашего устройства, которое за одну наносекунду должно получить некоторые воздействия, обработать их и выдать реакцию. Такое устройство для которого уже понятие алгоритм это не +1 и для которого возникает мысль об операционной системе, или реализации оного алгоритма в железе сложнее нескольких тригеров.

[prog_sun]

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

принял один импульс, посчитал его, приготовился принимать второй импульс после n-го импульса результат отправил в компьютер или для Вас это не алгоритм?

реализации оного алгоритма в железе сложнее нескольких тригеров.

надо еще "попотеть", решить массу проблем, перед тем как на той элементной базе сделать счет импульсов.

и для которого возникает мысль об операционной системе

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

[AlexandrY]

Трудность понимания систем реального времени именно и заключаеться в том, что многие не представляют где они применяются.
Начинаются гадания: ракеты, радары, космос ... хотя и это тоже, но -
Возьмем обычный фотопринтер. Нет ли у кого желания сделать его на FPGA?
А что, тупые датчики и все, скорости небольшие! Ну может смутить кого-то наличие USB, но не беда, че нить придумаем.
Ан нет, в самом дешевом фотопринтере можно насчитать до 50-и и более задач.
Некоторые с исключительно жестким реалтаймом. Кому понравятся размытые контуры на фотке, или нечеткие цвера, или пропущенные линии или простой принтера и долгая подготовка к работе.
Задачи в принтере создаются буквально для каждого датчика, и еще создаются менеджеры задач управляющие другими задачами. Семафоры и ивенты уже исчисляются сотнями.
Зачем создавать новые задачи?
Ну вот допустим картридж в принтере. Их 5-ть. Они тоже с процессорами.
Обмен на скрости до 1 Mbit-a.
Картриджы выполняют двоякую роль: с одной строны они звено в схеме слежения за уровнем чернил c другой стороны они выполняют задачу защиты от клонирования и симуляции картриджей.
Так как хакеры тоже не дурачки картриджы выполняют процедуры защиты практически перед каждой печатью и в ходе печати. Естественно задачи создаются и уничтожаются динамически.
И все это на фоне того, что принтер непрерывно, а главное прецизионно следит за не менее 3-мя движками, датчиками позиционирования каретки, бумаги, зазаром, скоростями движения, концевыми датчиками, токовыми датчиками, кнопками интерфейса пользователя, проводит расчеты корректировку изображения, следит за USB и поддерживает кучу протоколов по USB, и еще в каждой задаче присутствует механизм диагности и отладки, который тоже состот из нескольких задач.

Если кто скажет зачем так сложно, я могу проще и дешевле на FPGA или без такой сложной системы задач и без RTOS ему памятник постявят фирмы Cannon, Epson, HP и т.д.


И вот такую систему и принято называть системой реального времени. Как видим термин к самому времени как абсолютному так и относительному имеет только косвенное отношение. Это скорее термин описывающий технологию.

немного в офтоп

на мой взгляд, система реального времени - система в которой время между приходом возмущения и вырабатываемым ответом на него меньше некоего критического времени (т.е. система в которой невыполнение данного неравенства приводит к нарушению функциональности). так что понятие реального времени зависит от контекста (от поставленной задачи или круга задач).
таким образом ОСРВ характерна для встроенных приложений, а встроенные приложения характеризуются ограниченным и стабильным набором выполняемых задач. (поэтому на мой взгляд постулаты ваши приведённые выше изначально неверны.)
так что любая система(в том числе и ПЛИС) может быть системой реального времени (не имею в виду ОС), если улсовие Т ответа < Т критическое выполняется для поставленных ей задач(тот же самый пульт от телевизора может считаться системой реального времени, потому что человеку не приходится идти поспать пока каналы всё-таки переключатся, и переключать каналы он может быстрее чем он сможет понять что на них показывают) абсолютное время ответа не имеет никакого значения.

[prog_sun]

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

Вы одно событие представляете как кучу событий. Это сложнее. И к тому же в примере с принтером я так думаю там симбиоз различных систем реального времени. Каждый датчик имеет свое время отклика. К примеру датчик бумаги свои временем отклика( через него врядли вы 1 Мбит пустите) и к примеру поток данных от компа к принтеру это уже другая система реального времени. Но все они должны согласованно на своих скоростях отработать и не останавливая процесс распечатать бумагу. Хотя вот в википедии что написано
# ОС, в которой успешность работы любой программы зависит не только от её логической правильности, но и от времени, за которое она получила этот результат. Если система не может удовлетворить временным ограничениям, должен быть зафиксирован сбой в её работе
# Стандарт POSIX 1003.1 даёт определение: «Реальное время в операционных системах — это способность операционной системы обеспечить требуемый уровень сервиса в определённый промежуток времени»
# ОС, реагирующая в предсказуемое время на непредсказуемое появление внешних событий

то что Вы сказали тоже подходит под систему реального времени.

[vshemm]

Мрак. И это все работает? А как ЧМА применяется? Или на глазок?
А если серьезно, то в примере несколько другие задачи. Нужно выпустить "нечто" как в можно более короткий срок. Это "нечто" поставлено на конвеер. Берем чего-нибудь подешевле, лепим и готово. Отсюда 50+ задач, быстро и недорого.
И систем реального времени нет, а есть задачи с дедлайном и системы, которые эти задачи решают. Понимаю, что это выглядит как "не из металла, а из другого материала", но это так

З.Ы. Кстати, насколько мне известно, в потребительском секторе только Мили применяла QNX в своих стиралках (это чтобы совсем оффтопа не было )

[prog_sun]

Вот здесь http://bugtraq.ru/cgi-bin/forum.mcgi?type=...15&m=145584 хорошо сказали "Неважно как обрабатывает система реального времени данные, это её секрет. Гарантируется только время отклика. Если система не влезла в предел времени отклика, она генерирует ошибку, только и всего."

[zltigo]

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

Первый-Второй курс института. Угадал?

[prog_sun]

zltigo
Если вы из того что я в свое время отказался от вот этой схемы

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

решили что я

Первый-Второй курс института. Угадал?

то Вам виднее вы же Гуру. Вообще то гадают на кофейной гуще.

А я теперь буду знать, что Гуру может ЭСЛ логику тупой диковинкой назвать

[CaPpuCcino]

Если кто скажет зачем так сложно, я могу проще и дешевле на FPGA или без такой сложной системы задач и без RTOS ему памятник постявят фирмы Cannon, Epson, HP и т.д.

ну чем же вам ПЛИС так насолили у них вообще другая область применения - это малотиражное производство. и применять их лучше для поточных алгоритмов(небольшая интенсивность ветвления потока управления, или зависимости по данным).
правда не знаю как устроены принтеры, но то что набор задач у него ограничен и стабилен за жизненный цикл устройства, наверное вопросов не вызывает. к тому же кажется мне что там как и в любой комплексной системе должна быть иерархия: врядли обработкой USB протокола и подсчётом чернил в катридже занимается центральный процессор, так же как и врядли ЦПУ в вашем ПК занимается управлением COM-портом. скорее там хорошо сбалансированная распределённая система. я даже сомневаюсь, что для сигнала об окончании чернил выделен какой-то специалный вектор отличный от какой-либо другой критической ошибки.
однако, я действительно этого не знаю, было бы интересно для примера почитать. подобную инормацию где-нить нарыть можно?

[AlexandrY]

Важны не эти формулировки, а их последующее толкование.
Спросите и многие с пеной у рта будут доказывать, что Windows это не система реального времени.
Хотя все знают что в масштабе минуты или часа Windows гарантировано даст отклик на любое событие
Почемуже она не realtime? Ваши формулировки не дают ответа на это вопрос.

Ищем ответы в практической литературе:
"Real-Time Concepts for Embedded Systems" by Qing Li and Carolyn Yao
"Introduction to real-time operating system" by Robert Betz
"Realtime Operating Systems" by Dr. Jürgen Sauermann
"Real-Time Systems" by Albert M.K. Cheng

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

# ОС, в которой успешность работы любой программы зависит не только от её логической правильности, но и от времени, за которое она получила этот результат. Если система не может удовлетворить временным ограничениям, должен быть зафиксирован сбой в её работе
# Стандарт POSIX 1003.1 даёт определение: «Реальное время в операционных системах — это способность операционной системы обеспечить требуемый уровень сервиса в определённый промежуток времени»
# ОС, реагирующая в предсказуемое время на непредсказуемое появление внешних событий

то что Вы сказали тоже подходит под систему реального времени.

Весь набор задач то известен, но если они все сразу начнут работать, то принтер даже не включится.
Задачи создаются и уничтожаются динамически! Состояние принтера меняеться каждые 10 мс. Каждый такт операционки. Когда каретка справа выполняються одни задачи, когда слева набор задач может быть уже другим.
Конечно там стоит не голый проц, а SoC, на движки есть контроллер, на картриджи тоже контроллеры шин (ктож потянет 5-ть мегабитных потоков да еще full speed USB программно отлавливать ) но это сильно дело не облегчает. Все потоки данных все равно обрабатывает центральный процессор и разве что только маркеры кадров в протоколах сам не выставляет.

ну чем же вам ПЛИС так насолили у них вообще другая область применения - это малотиражное производство. и применять их лучше для поточных алгоритмов(небольшая интенсивность ветвления потока управления, или зависимости по данным).
правда не знаю как устроены принтеры, но то что набор задач у него ограничен и стабилен за жизненный цикл устройства, наверное вопросов не вызывает. к тому же кажется мне что там как и в любой комплексной системе должна быть иерархия: врядли обработкой USB протокола и подсчётом чернил в катридже занимается центральный процессор, так же как и врядли ЦПУ в вашем ПК занимается управлением COM-портом. скорее там хорошо сбалансированная распределённая система. я даже сомневаюсь, что для сигнала об окончании чернил выделен какой-то специалный вектор отличный от какой-либо другой критической ошибки.
однако, я действительно этого не знаю, было бы интересно для примера почитать. подобную инормацию где-нить нарыть можно?

[CaPpuCcino]

Важны не эти формулировки, а их последующее толкование.
Спросите и многие с пеной у рта будут доказывать, что Windows это не система реального времени.
Хотя все знают что в масштабе минуты или часа Windows гарантировано даст отклик на любое событие
Почемуже она не realtime? Ваши формулировки не дают ответа на это вопрос.

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

# Стандарт POSIX 1003.1 даёт определение: «Реальное время в операционных системах — это способность операционной системы обеспечить требуемый уровень сервиса в определённый промежуток времени»

и ещё там похожие в данном топике были

Конечно там стоит не голый проц, а SoC, на движки есть контроллер, на картриджи тоже контроллеры шин (ктож потянет 5-ть мегабитных потоков да еще full speed USB программно отлавливать ) но это сильно дело не облегчает. Все потоки данных все равно обрабатывает центральный процессор и разве что только маркеры кадров в протоколах сам не выставляет.

ну а можно где-нить это почитать, плииз, - интересно же
З.Ы.: 2 AlexandrY упс, кажется, немного запутался с вашим стилем цитирования : (

[zltigo]

Если вы из того что я в свое время отказался от вот этой схемы

Нет из-за того, что такая "мысль" могла придти в голову

А я теперь буду знать, что Гуру может ЭСЛ логику тупой диковинкой назвать

Вы непозволительно невнимательны ЭСЛ это вещь "дивная", а не дикая, а "тупая" это поставленная Вами задача посчитать импульсы.

[prog_sun]

Нет из-за того, что такая "мысль" могла придти в голову

Вы непозволительно невнимательны ЭСЛ это вещь "дивная", а не дикая, а "тупая" это поставленная Вами задача посчитать импульсы.

вот что вы тогда сказали

быстродействующий но ТУПОЙ счетчик на дивной ЭСЛ логике

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

[zltigo]

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

Жаль, что Вы так и не понимаете, что само возникновение "мысли" использовать хоть что-то процессорообразное (причем совершенно вне всякой зависимости от операционной системы и вообще ее наличия) для отработки времен реакции в ОДНУ НАНОСЕКУНДУ, говорит о многом .
Прощайте!

[AlexandrY]

Вся инфа получена на основе реверсинга и реинжениринга
В принтерах бывает на плате отладочный порт по UART-у.
На том порте можно запустить Shell для просмотра состояния RTOS.
Посмотреть состав задач, объектов синхронизации, таймеров и т.д. Можно даже ими управлять.

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

ну а можно где-нить это почитать, плииз, - интересно же

[ishergin]

Сорри что вмешиваюсь
Кто нибудь работал с ChorusOS ? Встречал упоминания что она сравнима и даже в чем-то превосходит QNX. Открытые исходники, куча платформ, и тд (насколько я помню, по объёму и количеству файлов сравнима с QNX, лень распаковывать ). Когда я увлекался копанием исходников ОС, то ее дизайн и структура исходных файлов мне очень понравилась..

[zltigo]

Кто нибудь работал с ChorusOS ?

Для систем такого объема на первый план выходит не наличие исходников, кои все равно не вычитать и не исправить, или заявления о превосходных заложенных идеях, а количество систем на которых она применяется и соответственно по результатам работы на которых правилась и развивалась. Тут QNX без вариатнов превосходит очень и очень многих.

[vshemm]

...
Тут QNX без вариатнов превосходит очень и очень многих.

Справедливо для версии 4, но не для 6.

[prog_sun]

vshemm
[/i]Справедливо для версии 4, но не для 6.[i]

Что за операционка реального времени которая лучше 6 версии?

[Olej]

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

Можно
см. например здесь:
http://qnxclub.net/modules.php?name=Forums...topic&t=443
к примеру, - полнофункциональная сетевая ОС, умещающаяся на дискету и занимающая в RAM <4Mb...
Собрано "из этого"(с)
Весь вопрос в том, какую функциональность вы хотите нагрузить на "более-менее работающую систему"...
GUI + multimedia ?

P.S. Чуть не забыл. Шедулер масштабируется как О(n) не только на CPU, но и на количество тредов. Другими словами, при увеличении работающих тредов в системе время шедулирования увеличивается линейно.

Это неправда ... что и показывают эксперименты.
Более того, если задачу, работающую над какими-то регулярными структурвми выполнить:
- как однотредоввую задачу...
- разделив ту же работу между N тредов (N большое ... сотни и более)...
- разделив ту же работу между N процессов в изолированных MMU адресных пространствах (контекст процессора нужно переключать)...
... то время выполнения суммарной работы во всех случаях не будет различаться более, чем на 10-15%

Хотя вроде в интеренете читал статьи что QNX используется в самолетах F-16.

... и не только как HMI, а как системой управления всей навигацией ... известный пример приводится при разборке случаев "критических ошибок ПО", когда при перебазировании эскадрильи F-16 в Австралию при пересечении экватора они перевернулись "вверх брюхом", и "соглашались" лететь только так - система координат поменялась ...

+ управление огнём танка "Абрамс", который считается лучшим в мире...

+ управление безопасностью всех АЭС Канады...

+ управление распределёнными сетями нефте-газо-перекачки "Газпром"...

+ АСУТП литейными и близкими к ним производствами ... Магнитогорск и др.

А вот на счет того что поставить такую ось на ракету такое не слышал,

да? а вся система телеметрии МКС ?

Спросите и многие с пеной у рта будут доказывать, что Windows это не система реального времени.
Хотя все знают что в масштабе минуты или часа Windows гарантировано даст отклик на любое событие

Даст ...
... если к истечению этого критического интервала времени она просто не зависнет ... чему есть конечная вероятность.

Почемуже она не realtime?

Хотя бы по одной (но не единственной ) причине:
- в ней даже не предпринимаются никакие попытки препятствовать инверсии приоритетов:

- поток 1 (процесс) с низким приоритетом L захватывает мютекс, скажем...
- позже поток 2 (процесс) с высоким приоритетом H хочет тот же мютекс, но это же "потом" ... поэтому он ожидает...
- ... и всё будет нормально, когда через интервал T : а). поток 1 освободит мютекс б). поток 2 получит мютекс в). тут же вытеснит поток 1;
- но до тех пор, пока до истечения интервала T не появится 3-й поток (процесс) среднего приоритета M ... да ещё и не переходящий в блокированные состояния пассивного ожидания (оператор сел со скуки "солитёр" погонять)...
- что имеем? а). поток L владеет мютексом и вытеснен б). потоком M а в). а поток H благополучно ожидает мютекс, которым владеет L ... + г). и это может продолжаться до бесконечности... и ни "в минуты"(с) ни "в часы"(с) она теоретически не разрешается

1. эта ситуация достаточно легко моделируется в Windows...
2. проверено ... "плавали"(с)
3. можете попробовать
4. подробней можно почитать и пообсуждать здесь, например:
http://qnxclub.net/files/articles/invers/invers.html
http://qnxclub.net/modules.php?name=Forums...wtopic&t=16

Ищем ответы в практической литературе:
"Real-Time Concepts for Embedded Systems" by Qing Li and Carolyn Yao
"Introduction to real-time operating system" by Robert Betz
"Realtime Operating Systems" by Dr. Jьrgen Sauermann
"Real-Time Systems" by Albert M.K. Cheng

НИКТО не пытается дать формулировку системам реального времени наподобии тех что привели вы.
Все отсылают к примерам реализаций и просто пытаются искать различия.

... ну, много и разное говорилось... и достаточно конкретные вещи:
http://qnxclub.net/files/articles/rtos/rtos.html
http://qnxclub.net/files/articles/RemarksO...TheMargins.html
http://qnxclub.net/files/articles/rms/rms.html
http://qnxclub.net/files/articles/rta/rta.doc
http://www.cniil.org/QNX_NEUTRINO_RTOS_V6_2_0.html
http://qnxclub.net/modules.php?name=Forums...wtopic&t=36
http://qnxclub.net/modules.php?name=Forums...topic&t=116

[AlexandrY]

Программисты от индустрии сильно оторваны от консамерной техники и практически мало знают о применяемых там технологиях.
Из преведенных ссылок опять же нигде не следуют четкие определения RTOS кроме той что выделил внизу.
Но там только подтверждаються некоторые мои мысли.
Как я уже показал в простом принтере могут выдвигаться требования к realtime гораздо жесче чем в каком нибудь индустриальном дивайсе.
И потери от несоблюдения realtime в принтере больше чем в индустриальном дивайсе.
Принтеров о которых я говорю выпустили несколько миллионов только этого конкретного типа. Потеря качества из-за плохого ПО там сразу приводит к миллионным убыткам.
Именно консамерская техника заставила принять закон о RoHS.
Именно она и диктует понимание RTOS, потому что производители RTOS на нее ориентируются.
И QNX как видно уже понял тренды.

Я конечно могу понять страдания вокруг ЧМА на форуме по QNX.
Но если в мобиле количество задач приближаеться к сотне и она при этом должна поддерживать несколько десятков протоколов в realtime одновременно, а собирается софт к мобиле из друг другу неизвестных кусков то тут уже не до ЧМА.

... ну, много и разное говорилось... и достаточно конкретные вещи:

[url=http://qnxclub.net/files/articles/RemarksOnTheMargins/RemarksOnTheMargins.html]

[prog_sun]

Olej

Много полезного вспомнил и узнал . Про АЭС знал но вот про МКС первый раз слышу.

(prog_sun @ Oct 21 2007, 12:27) *

А вот на счет того что поставить такую ось на ракету такое не слышал,


да? а вся система телеметрии МКС ? wink.gif

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

и не только как HMI, а как системой управления всей навигацией

раньше предполагал что это все вместе. Если говоришь о HMI то подразумеваешь "управление всей навигацией". Тогда в наших рассужденях было другое если эта система выйдет из строя, то самолет от этого не упадет. По крайне мере все перейдет на ручное управление.

[vshemm]

...
к примеру, - полнофункциональная сетевая ОС, умещающаяся на дискету и занимающая в RAM <4Mb...
Собрано "из этого"(с)

Собрано полностью из сорцов? Так сказать from scratch? Впрочем, это вопрос времени.

Это неправда ... что и показывают эксперименты.
Более того, если задачу, работающую над какими-то регулярными структурвми выполнить:
- как однотредоввую задачу...
- разделив ту же работу между N тредов (N большое ... сотни и более)...
- разделив ту же работу между N процессов в изолированных MMU адресных пространствах (контекст процессора нужно переключать)...
... то время выполнения суммарной работы во всех случаях не будет различаться более, чем на 10-15%

Какие эксперименты? Описанный Вами случай при постоянном N показывает оверхед IPC и переключения контекстов. А вот если заглянуть в \services\system\ker\nano_sched.c то можно увидеть циклы по тредам (правда, только в SMP варианте)

...
+ управление огнём танка "Абрамс", который считается лучшим в мире...
...

Пусть используют Кстати, там какая версия?

Хотя бы по одной (но не единственной ) причине:
- в ней даже не предпринимаются никакие попытки препятствовать инверсии приоритетов:
...

Инверсия приоритетов - это недостаток самой парадигмы треды-приоритеты, а не ОС, поэтому возникать инверсия может где угодно. Есть способы, которые могут сгладить негативный эффект, но не нужно заставлять ОС решать проблемы дизайна системы Конечно, наличие inheritance и ceiling - признак хорошего тона, но вряд ли необходимость.

[Olej]

раньше предполагал что это все вместе. Если говоришь о HMI то подразумеваешь "управление всей навигацией". Тогда в наших рассужденях было другое если эта система выйдет из строя, то самолет от этого не упадет. По крайне мере все перейдет на ручное управление.

... упадёт, упадёт ... если не успеете вмешаться - а иначе как бы они перевернулись "брюхом кверху" при перелёте через экватор?

К применениям QNX (степени их критичности) могу добавить, вспомнилось, что весьма многие СУ в мире деланы на SCADA RealFlex (Ирландия ... но люди там "наши" ), вот только некоторые из:

- система согласованного управления всеми маяками Ирландии;
- система управления всем "напольным оборудованием" (а это стрелки, светофоры и т.д.) национальной ж/д транспортной системы Новой Зелландии (делал, кстати, Сименс ... и решил делать на "чужой" системе);

В этих системах может и не фигурировать QNX, а фигурирует RalFlex, но RalFlex "живёт" только и исключительно на одной ОС - QNX.

Очень активно QNX используется в управляющих системах корабельных силовых агрегатов ... это уже из реализаций Санкт-Петербурга.

P.S. а, кстати, вспомнил ... здесь много со знанием дела говорили про "ракеты"? так вот, я вам маленькую гос.тайну выдам (точнее здесь их 2 ): а). что вся "наземка" и значительная часть "борта" последних пусков ("Булава" - помните? или "Египсат"?) - сделаны в QNX б). потому что делаются они в Харькове (НИИ РИ ... это уже 3-я военная тайна ).
И, кстати, что интересно - в версии QNX 6, и переход с 4-ки на 6-ку очень тщательно обосновывался и утверждался техсоветом института ... года 2 назад ... это к попыткам противопоставлять QNX 2 / QNX 4 / QNX 6 - архитектурной разницы между ними нет.

Собрано полностью из сорцов? Так сказать from scratch? Впрочем, это вопрос времени.

Собирается procnto, всё что "вокруг" микроядра + libstd ... для "того" практически ничего больше и не надо.
А остальное - это теперь действительно вопрос времени.

Пусть используют Кстати, там какая версия?

Я думаю что 2, судя по времени, когда система ещё не подлежала коммерческим продажам.

Инверсия приоритетов - это недостаток самой парадигмы треды-приоритеты, а не ОС, поэтому возникать инверсия может где угодно. Есть способы, которые могут сгладить негативный эффект, но не нужно заставлять ОС решать проблемы дизайна системы Конечно, наличие inheritance и ceiling - признак хорошего тона, но вряд ли необходимость.

Нет, инверсия не "недостаток самой парадигмы треды-приоритеты"© - точно то же самое будет, если в любой ОС слова "тред" заменить на "процесс" или "задача", только синхронизироваться (в смысле захватывать) они будут в этом случае на именованном семафоре ... или на любом примитиве синхронизации в shared memory.
Кстати, если это проделать в MINIX 3 (которая "очень-и-очень" похожа на QNX по структуре), где вообще нет тредов (не сделали ещё), то там практически наверняка ситуация эта и возникнет...

А вообще, здесь споров много возникло о "реалтаймовости" ... а споры то - пустые, говорится просто - о разном.
Вы сами, кажется, где-то в предыдущих постах (искать лень) почти дошли до:
- ОС вообще не может быть "реалтайм" (такой она называется только как коммерческий трюк) - реалтайм может быть (или не быть ) только целевая разрабатываемая система...
- разные ОС могут только предоставлять механизмы, которые обеспечат целевой системе реалтаймовость (или не обеспечат) ... вот QNX - обеспечит, а Windows & Linux - не обеспечат...
- и говорить о реалтаймовости можно только тогда когда возникают параллельность (потоки, процессы, синхронизации)...
- однонитиевое ПО не может быть (но не может и не быть) реалтайм - это циклический конечный автомат: либо он успевает за время критического цикла, либо не успевает... это прекрасно реализуется в SWITCH-технологии проф.Шалыть;
- и если целевая задача не обладает выше некоторого уровня разветвлённостью-параллельностью (и степенью сложности) - то и копья ломать об реалтаймовость нет резона ... и ОС реалтайм для этого не нужна.

[prog_sun]

+ АСУТП литейными и близкими к ним производствами ... Магнитогорск и др.

и вот это

- система согласованного управления всеми маяками Ирландии;
- система управления всем "напольным оборудованием" (а это стрелки, светофоры и т.д.) национальной ж/д транспортной системы Новой Зелландии (делал, кстати, Сименс ... и решил делать на "чужой" системе);

В этих применениях большое значение имеет надежность системы а не время реакции системы.
Я так предполагал что для таких систем и Линукса достаточно. Зачем например для литейного производства время реакции в одну микросекунду?

P.S. а, кстати, вспомнил ... здесь много со знанием дела говорили про "ракеты"? wink.gif так вот, я вам маленькую гос.тайну выдам (точнее здесь их 2 wink.gif): а). что вся "наземка" и значительная часть "борта" последних пусков ("Булава" - помните? или "Египсат"?) - сделаны в QNX б). потому что делаются они в Харькове wink.gif (НИИ РИ ... это уже 3-я военная тайна wink.gif).

Какая же это тайна? Вроде Украина в Нато стремиться . А так что да то да на Украине сильное QNX сообщество. По крайне мере тогда года три назад осваивал QNX используя материалы и форумы этого сообщества. Раз Вы так со знанием дела говорите, наверно тоже отуда?

[Olej]

В этих применениях большое значение имеет надежность системы а не время реакции системы.
Я так предполагал что для таких систем и Линукса достаточно. Зачем например для литейного производства время реакции в одну микросекунду?

А если искать синоним "реалтайм" - то ближайший и будет "надёжность" ... predictable, а вот само абсолютное значение времени реакции - ну просто никакого отношения к реалтайм и не имеет, и вот в этом и состоит самое частое заблуждение относительно риалтайм.
И вот именно поэтому всем им Linux не сгодился

Какая же это тайна? Вроде Украина в Нато стремиться .

Вот вы знаете, а я - не знаю куда она "стремится"(с) ... наверное, в задницу...
А тайна то и есть в том, что для всех самых "звучащих" российских пусков вся наземка (но и не только) делается а). в QNX + б). в 6-м + в). в Украине - так что это к тому, что "может или не может в ракете?"

[prog_sun]

А если искать синоним "реалтайм" - то ближайший и будет "надёжность" ... predictable,

С этим двумя руками согласен.
А вот с этим что делать даже не знаю

а вот само абсолютное значение времени реакции - ну просто никакого отношения к реалтайм и не имеет

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

И вот именно поэтому всем им Linux не сгодился

Вообще не понял. Может ссылочку дадите, где говорится что по надежности QNX на много превосходит Linux. Что то я в этом сомневаюсь Или клоните к тому что QNX более "риалтаймнее" чем Linux, то значит и более надежнее ее. И это превосходство имеет решающее значение в литейном производстве.

[Olej]

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

Это всё - "скорость" ... но к "реалтаймовости" и pedictable - скорость не имеет никакого касательства, и даже не коррелирована с ними...
Может быть "быстрая" система и "медленная" (так же как и процессор) ... может быть pedictable & non pedictable ... - сделайте из них линейную комбинацию, и получите полный спектр систем .
Более того, при прочих равных, realtime OS будет медленне чем general purpose OS - в ней всё приходится делать тщательнее ... поэтому, скорее, скорость и реалтаймовость - отрицательно коррелированы

Вообще не понял. Может ссылочку дадите, где говорится что по надежности QNX на много превосходит Linux. Что то я в этом сомневаюсь Или клоните к тому что QNX более "риалтаймнее" чем Linux, то значит и более надежнее ее. И это превосходство имеет решающее значение в литейном производстве.

Вот здесь был перевод, который девочка сделала с отчёта Dedicated Systems:
http://www.cniil.org/QNX_NEUTRINO_RTOS_V6_2_0.html

Перевод известного отчёта Dedicated Systems по тестированию QNX Neutrino 6.2.0. Перевод выложен на сайте ЦНИИЛ и выполнен, как сказано на сайте "...студенткой группы 5057/2 Ксенией Некрасовой."

... но к сожалению, авторы испугались и его спрятали
Зайдите на сайт Dedicated Systems (URL его очень легко найти по названию - это крупнейший независимый тестер) - там много обстоятельных отчётов-сравнений (30-50 стр. и более)...
Вот там доказывается, что надёжностные/риалтаймовые показатели Linux (RT-Linux ) - на порядки хуже аналогичных показателей QNX.

Как уже говорил, шедулер QNX масштабируется как O(n) на количество нитей. Другими словами, время его отработки линейно возрастает с их количеством.

А вот здесь вы, пожалуй, правы... не так однозначно, может, O( n ) ... O( f( n ) )
Я по вашему утверждению понаделал тестов как это выглядит со стороны конечного пользователя ("чёрный ящик")...
Чтоб не пересказывать много - здесь:
http://qnxclub.net/modules.php?name=Forums...topic&t=472
- всё детально описано.

Но всё это вовсе не так страшно:
- шедулирование (по крайней мере round-robin / sporadic, а не "кооперативное" ) всегда происходит в момент системного тика (одного из) и его время суммируется с обслуживанием службы времени ... которое а). ~const б) >> времени шедулирования...
- а само шедулирование - очень коротко...

Кстати, здесь ещё одно интересное отличие RTOS vs GPOS:
- есть размер системного тика ... многие производители ОС берегут его значение как "тайну мадридского двора"...
- из разных источников: Windows - 10мс. (15мс. при SMP); Linux - 10мс. ... в ядрах 2.6.х может изменяться (перекомпиляцией ядра!) ... до 1 (?) мс.; QNX - 1мс. by default, может изменяться runtime вплоть до 10мкс.
- интервал шедулирования round-robin - таймслайс - всегда кратен тиксайз со множителем N ... - это ещё большая тайна производителя : в QNX - 4, Windows - 13, ... Linux - не знаю
- итого, минимальный временной квант диспетчеризации QNX составляет 40мкс., а в Windows - 130мс. - 3.5 порядка, впечатляет? Это как если бы на вашем мониторе установить частоту развёртки не 100гц., а 100 / 3000 = 0.03гц - как, не слабо? , не хочется за таким поработать?

[vshemm]

Так, давайте разделим понятия "скорость", "детерминированность" и "реалтаймовость". Первые два - характеристики ОС, в то время как третье - интегральная характеристика и зависит от задачи. Так же не совсем верно, что RTOS обычно медленнее GPOS, скорее микроядерные всреднем медленнее монолитных, а это совсем другое.

По надежности - тоже спорный вопрос. Все ОС требуют немалой доработки напильником в случае, если они применяются в критичных по надежности задачах. И никто не использует их "из коробки", разве что производитель сам заточил ОС под определенную задачу. Другими словами, то, что в Канаде АЭС управляются QNX'ом, не значит, что его будут вслепую внедрять на АЭС за ее пределами. А вот рассматривать как кандидата - да. Трудоемкость доработки - вопрос отдельный

По шедулеру. Для однопроцессорного варианта - все нормально, масштабирование отличное, т.е. O(1). Для SMP - тут явно сыровато. И проблема даже не в том, что шедулер зависит от количества нитей (это важнее для всяких серверов с огромным количевством запросов), а в том, что он может исполняться только на одном процессоре. Т.е. другие процессоры будут блокироваться на нем. Более того, все говорит о том, что и с микроядром тоже самое, как только один процессор вошел в него, все остальные будут ждать. Учитывая, что каждый чих происходит через микроядро, оно может стать узким местом. Честно говоря, еще не въехал в Ваши тесты, но у меня ощущение, что тестируется что то другое

Далее. Шедулирование происходит не только в момент системного тика (тут речь уже не только о QNX, а вообще об ОС в целом). Есть еще много мест: принудительный вызов шедулера в коде, блокировка на мьютексах/семафорах и т.п., различные сигналы, в т.ч. и из обработчика прерываний. И это хорошо, т.к. повышает скорость срабатывания логики. А вот небольшой системный тик не нужен вообще (достаточно возможности его менять в некоторых пределах), т.к. при этом повышается (и очень сильно) оверхед. И правда, общение с внешним миром происходит либо асинхронно по ивентам, либо по циклограммам, тут принудительное шедулирование не нужно, можно обойтись своими силами. А вот для организации "параллельного" выполнения задач - да. На сцене появляется квант времени (time slice), т.к. классический алгоритм FIFO никогда не допустит вытеснения более приоритетной задачи менее приоритетной (в RR тоже есть time slice, но мы рассмотрим "супер быстрый" алгоритм, где даже самая низкоприоритеная нить получает время). И зачем тут малый квант? Более того, обычно чем выше приоритет у нити, тем ее квант больше. В линуксе он меняется гдето от 5мс до 800мс. Кстати, в нем же недавно появилась опция TICKLESS - холостых тиков вообще нет (по задумке). Очень интересная опция, жаль пока нет времени разобраться

P.S. Оффтоп, конечно, но что поделать

[Olej]

Собственно, открытие кода QNX, с чего и началась вся тема, поимело свой результат (или начинает иметь?):
http://www.qnx.com/news/pr_2471_1.html
http://www.rts.ua/rus/news/manufacturer/0/93/

Advantech присоединяется к QNX Community
Дейвид ДеМинт (David DeMint), менеджер проектов компании Advantech таким образом проеагировал на сообщение об открытии исходных текстов и процесса разработки QNX Neutrino:

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

Имея доступ к исходным текстам , разработчики почувствуют превосходную архитектуру микроядра, проверенную безопасность и стабильность QNX Neutrino.

Как один из крупнейших производителей встраиваемых вычислительных систем, мы планируем работать с QNX , что бы разработать пакеты поддержки для ETX, COM-Express, а так же широкой номенклатуры одноплатных компьютерных систем.

Участие в расширенном QNX сообществе отражает роль Advantech, как постоянного лидера встраиваемых вычислений."

Т.е., ясное дело, что акция эта была направлена никак не на open community, а на брандовых производителей оборудования в классе prom-PC.

[prog_sun]

http://www.dedicated-systems.com/encyc/pub...time_definition

There are _several_ definitions of real-time, most of them contradictory. Unfortunately the topic is controversial, and there doesn't seem to be 100% agreement over the terminology.

1. The canonical definition of a real-time system (from Donald Gillies mailto:gillies@ee.ubc.ca ), is the following:

"A real-time system is one in which the correctness of the computations not only depends upon the logical correctness of the computation but also upon the time at which the result is produced. If the timing constraints of the system are not met, system failure is said to have occurred."

2. POSIX Standard 1003.1 defines "real-time" for operating systems as:
"Realtime in operating systems: the ability of the operating system to provide a required level of service in a bounded response time"

там есть еще другие определения. А мне вот это понравилось

4. One will also see references to "real-time" systems when what is meant is just "fast". It might be worth pointing out that "real-time" is not necessarily synonymous with "fast"; that is, it is not the latency of the response per se that is at issue (it could be of the order of seconds), but the fact that a bounded latency sufficient to solve the problem at hand is guaranteed by the system. In particular, frequently, algorithms that guarantee bounded latency responses are less efficient overall than algorithms that don't.

и вот это

5. One will also occasionally see discussions of "soft" vs. "hard" real-time systems. In many of these discussions, "hard" real-time means the type of real-time system discussed above, and "soft" real-time means systems which have reduced constraints on "lateness" but still must operate very quickly and repeatably. However, the definition is controversial, as some mean by "hard" and "soft" the degree of time constraints. For instance, a real-time process attempting to recognize images may have only a few hundred microseconds in which to resolve each image, but a process that attempts to position a servo-motor may have tens of milli-seconds in which to process its data.

там еще много чего интересного.

[Olej]

там еще много чего интересного.

это всё только определения...

при том, что многие из них формулируются по принципу "масло маслянное" ...
... "POSIX Standard 1003.1"(с) в своём первозданном виде - это стандарт ещё прошлого века , и уж определения там никто с того времени не переписывал точно...
... а о том, что реалтайм - это далеко не "быстро", а скорее даже наоборот - так я вас давно в этом убеждаю, но вы мне ведь не верите ...

А вообще, Dedicated Systems - одно из немногих мест, где из всей этой "каши" вокруг реалтайм можно извлечь хоть что-то полезное .

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

Вот это стоит быть прочитанным.

[AlexandrY]

Ну главного события еще не произошло.
QNX пока еще расхваливаем авансом.
Middleware еще не выложено, а без него QNX грош цена.

Сейчас альтернатив QNX как ядру навалом. Тут недалеко выложены и Montavista, и ThreadX, и ARTX, и Nucleus, и VxWorks, и uCOS, и eCOS. И большинство с кой каким middleware.

Однако обнаружил тренд.
Появляются чипы с ядрами такие как ARM Cortex-M3, S08 где MMU мягко говоря сделано не так как его представяляет QNX.
Т.е. почти все выше перечисленные ядра на них встанут, а QNX не встанет.
Может этим вызвана суета QNX?

Собственно, открытие кода QNX, с чего и началась вся тема, поимело свой результат (или начинает иметь?):
http://www.qnx.com/news/pr_2471_1.html
http://www.rts.ua/rus/news/manufacturer/0/93/
Т.е., ясное дело, что акция эта была направлена никак не на open community, а на брандовых производителей оборудования в классе prom-PC.

[?ELF]

Извините, что встреваю в разговор специалистов на далёкую от моих повседневных задач тему.
Но, человек спрашивал про «визуальность» QNX и IDE.

Может быть, я с QNX не работал никогда, а как это выглядит, я о визуальности, а можно скришоты?

Вспомнил, что где-то в архивах у меня валяются скриншоты от экспериментов 4-х летней давности с QNX 6.2 для x86. Нашёл вот их случайно.










---
P.S. поставил сегодня на закачку QNX Momentics Development Suite 6.3.2 - 523.41 MB.
Хочется посмотреть, что нынче раздают в комплекте.

[prog_sun]

А вот солнышко на первом рисунке что это за знак и история этого знака, хотел узнать тогда но так и не узнал. А сейчас посмотрел скриншоты и вспомнил этот вопрос. Или это так QNX понравился этот рисунок и вставили и никаго смысла в рисунке нет.

[Andrew2000]

Сейчас альтернатив QNX как ядру навалом. Тут недалеко выложены и Montavista, и ThreadX, и ARTX, и Nucleus, и VxWorks, и uCOS, и eCOS. И большинство с кой каким middleware.

Появляются чипы с ядрами такие как ARM Cortex-M3, S08 где MMU мягко говоря сделано не так как его представяляет QNX.
Т.е. почти все выше перечисленные ядра на них встанут, а QNX не встанет.

Если не ошибаюсь, то Nucleus, uCOS и eCOS - MMU и не нада, для VxWorks - тоже не обязательно.
Про ThreadX и ARTX ничего не скажу - не знаю, но есть подозрение, что ThreadX-у MMU тоже не нада.
Montavista - Linux вид сбоку.
Вопщем... че-то я альтернатив QNX-у все равно не вижу.

[?ELF]

А вот солнышко на первом рисунке что это за знак и история этого знака, хотел узнать тогда но так и не узнал. А сейчас посмотрел скриншоты и вспомнил этот вопрос. Или это так QNX понравился этот рисунок и вставили и никаго смысла в рисунке нет.

Offtop.
Меня тоже эта символика интересовала. Т.к., родина QNX, всё же, Канада а не Россия, то, возможно, это «роза ветров»?
Вроде того, «QNX — во все стороны света»?
Но, что в центре? Планета Земля?

---
P.S. запоминающийся логотип. Как и монограмма, впрочем. Коммерческая ось... Графические дизайнеры тоже не забыты...

---
P.P.S. извиняюсь за offtop в этом топике.