Страниц: [1]
  Печать  
Автор Тема: QNX vs (RT)Linux  (Прочитано 766 раз)
GrayCat
Full Member
***
Offline Offline

Сообщений: 131


Gray©at


Просмотр профиля
« : Июля 07, 2020, 10:09:57 am »

Приветствую аксакалов!

В связи с переходом экосистемы QNX в стадию перманентного загнивания, потихоньку смотрю в сторону Real-Time вариаций Linux.

В нашей ныне существующей самописанной АСУ ТП ничего такого слишком уж "реал-таймового" не требуется. Обмен данными через RS-485 с модулями В/В и частотниками, относительно быстрый (сотни миллисекунд) останов конвееров при сработке датчиков безопасности. Коммуникация с оборудованием -- мультипортовые платы, сейчас это Moxa CP-138U-I, на шине PCI, 8-портовые, до трёх штук на сервер. И вот тут нас ожидает первая засада: в современных чипсетах шины PCI уже давно нет, наружу торчит PCI-Express и в лучшем случае на промышленных материнках ставят "мост" PCIE-PCI. Но, не всегда этот мост корректно работает без своего драйвера из-под QNX (не проходят прерывания). С другой стороны, нынешние мультипортовки на PCIE все идут слишком "умные", требуют драйвера даже чтобы работать в режиме "просто-8250" (в них как минимум свой контроллер прерываний, требующий инициализации из софта), а на драйвера для QNX все производители давно забили.

Вторая засада -- это видеокарты. У нас HMI оператора крутится на том же сервере, плюс несколько удалённых рабочих станций. Ничего особенного, текст плюс анимация путём показа готовых наборов кадров для каждого механизма. Никаких OpenGL или там "слоёв". Но, как все прекрасно знают, по части драйверной поддержки сейчас осталась только встроенная графика Intel на софте производства КПДА ;-) . Да и этот "ручеёк", похоже, скоро иссякнет. Соответственно, мы остаёмся сильно ограничены в портах вывода видео. Вдобавок, как показали наши эксперименты, встроенный видеоадаптер, разделяющий память с процессором, крайне негативно сказывается на "реал-таймовости" системы. На платформе i830 мы когда-то наблюдали несколько сотен миллисекунд полного "затыка" на время блиттинга FullHD из OffScreen-Context на экран.

Плюс, проблемы с современными USB 3.0 и выше; какие-то непонятки с некоторыми моделями нынешних мышей и клавиатур; сетевухи современные многие либо не работают под QNX, либо дают какие-то невообразимые задержки...

С другой стороны, за последние годы, как я вижу, разработка Линукса резко продвинулась в сторону Real-Time. Насколько я понял, варианты сейчас следующие:
  • Относительно недавно "встроенный" в основную линуксовую ветку механизм "PREEMPT_RT". Удобно тем, что юзер-код пишешь почти "как обычно". Ядро и всё окружение используется "дистрибутивное", почти без доработок напильником.
  • "Двухъядерная" система на базе Xenomai (Cobalt). Наиболее "жёсткий" Real-Time из доступных под Linux. Приложения RealTime пишутся специально под ко-ядро Cobalt, обычные -- стандартный User-space линукса. Возможно, потребует и специфических драйверов для железа.
  • "Одноядерная" система на базе Xenomai (Mercury). Как я понял, "расширяет" функциональность стандартного PREEMPT_RT. Позволяет обойтись без написания спец. драйверов, и Real-Time обеспечивается для User-процессов. Общая средняя производительность (throughput) получается плохая, но на современных процессорах это не проблема.
   
Вот и хочу я проконсультироваться с сообществом. Кто-нибудь сравнивал именно QNX с этими вариантами? Например, вот как Линуксные модификации между собой:
http://pdfs.semanticscholar.org/9eb5/1dbe38fb23034e80b8664d8281996d2a5ef6.pdf?_ga=2.115305735.1422742923.1510677552-1828769110.1510677552
 -- большая работа проведена, очень наглядные цифры получены. Но, насколько это соотносится с QNX?

В какую сторону посоветуете смотреть? Время пока есть, можно не спеша выбрать вектор развития, но вот упереться в тупик как сейчас с QNX -- очень не хотелось бы.
Записан

Gray©at
A_O
Full Member
***
Offline Offline

Сообщений: 213


Просмотр профиля
« Ответ #1 : Июля 08, 2020, 06:59:53 pm »

У меня есть работающая система ЧПУ под Линуксом. Правда, там только обмен данными с контроллером по Ethernet/UDP - порядка 100 байт туда-обратно с постоянным периодом 10 мс, по инициативе контроллера, и графика не очень сложная (отображение движения рабочего органа по плоскому контуру). Работает без всяких RT примочек, обычный пользовательский процесс. Разумеется, цикл обмена выделен в отдельную нить с максимальным приоритетом.
« Последнее редактирование: Июля 08, 2020, 07:07:14 pm от A_O » Записан
LH
Full Member
***
Offline Offline

Сообщений: 130


Просмотр профиля
« Ответ #2 : Июля 09, 2020, 08:00:30 am »

У нас контроллер под QNX (наряду с другими работами) с легкостью выдает управляющие
команды через ЦАП на объект управления с периодом выдачи 1мс (требование ТЗ).

Какая альтернатива при смене ОС ?


Записан
darkelf
QOR.Moderator
*****
Offline Offline

Сообщений: 261


Просмотр профиля
« Ответ #3 : Июля 09, 2020, 12:53:09 pm »

Мы использовали Линукс с ядром PREEMPT_RT - в принципе после определённых доработок более-менее добились обеспечения цикла 1 мс. Всё реализовано на уровне прикладных задач, ядром дорабатывалось в плане убирания, в некоторых местах, излишнего PREEMPT_RT (был отдельно обработчик аппаратного прерывания, отдельно ядерный поток, который активировался из обработчика, а был прикладной поток, который активировался из ядерного потока, пришлось исключать ядерный поток и напрямую активировать прикладной).
Записан
GrayCat
Full Member
***
Offline Offline

Сообщений: 131


Gray©at


Просмотр профиля
« Ответ #4 : Июля 13, 2020, 11:16:06 am »

О, уже лучше, пошло обсуждение.

А то я попытался аналогичную тему на КПДА поднять, так меня там чуть ли не забанили с формулировкой -- ХА-ХА! -- за "Рекламу Linux"!   Cheesy  Grin  Angry

Есть ли у кого-нибудь конкретные цифры, типа как в упомянутой выше работе? Вон у них там график очень показательный.
Записан

Gray©at
LH
Full Member
***
Offline Offline

Сообщений: 130


Просмотр профиля
« Ответ #5 : Июля 14, 2020, 07:36:33 am »

м.б. вместо "рекламы Линукс", Вы напишите а конференцию КПДА отдельно по каждому проблемному вопросу и попросите
подсказать решение. Думаю, многим будет интересно, а КПДА должна будет отвечать.

Сомнения, изложенные Вами, волнуют и другие трудовые коллективы разработчиков (известно по собственному опыту).

Спасибо.
« Последнее редактирование: Июля 17, 2020, 09:31:38 am от LH » Записан
GrayCat
Full Member
***
Offline Offline

Сообщений: 131


Gray©at


Просмотр профиля
« Ответ #6 : Июля 17, 2020, 09:40:07 am »

м.б. вместо рекламы Линукс, Вы пишите а конференцию КПДА отдельно по каждому проблемному вопросу и просите
подсказать решение. Думаю, многим будет интересно, а КПДА должна будет отвечать.

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

КПДА ведёт свою "узкую" ветку под уже существующих заказчиков. Для сообщества, они уже потеряны. Сами авторы QNX сменили парадигму, и тоже уже работают под конкретных клиентов. Всё, в качестве общедоступной универсальной Self-Hosted системы с полноценным GUI, QNX потеряна.

Поддержки современных дискретных видеокарт -- нет и не будет. Встроенная графика Intel -- исключительно по милости КПДА, причём в любой момент следующая версия их драйвера перестанет работать в "коробочной" 6.5.0. Поддержка USB 3.0 -- после сервис-пака худо-бедно есть, но, например, на современных материнках вы уже не загрузите Live-CD по-нормальному. Плюс, постоянно какие-то траблы с конкретными моделями USB-мышек и клавиатур, а также удлиннителями USB.

Отдельная тема -- мультипортовки (RS-232, RS-485). Шина PCI отмирает, а новые PCI-Express платы требуют специфических драйверов. Которые под QNX никто не напишет.

Сетевы платы чипы -- уже скоро закончатся совместимые с "Intel E1000" чипсеты, драйверов под новые нам никто не даст. Да и те что есть -- глюкавые, а "чинить" их некому.

...Перечислять можно долго. "Родители" QNX систему забросили, КПДА -- жадные барыги с ограниченными ресурсами. Да и потребность в QNX  в качестве основы для "PLC + HMI" в наше время объективно снижается, ввиду перехода на распределённые архитектуры и разделение реал-таймовых задач и "потоковых". Но вот у нас, например, в маленькой сельскохозяйственной компании, мы такого сделать не можем. Менять полностью архитектуру нескольких десятков объектов с АСУ ТП нам никто не даст. Так что, смотрим в сторону варианта "Написать систему такую же как у нас но на Linux".

Вот отсюда и вопросы, упомянутые в шапке темы. В какую сторону двигаться?
Записан

Gray©at
longest
Участник
*
Offline Offline

Сообщений: 21


Просмотр профиля
« Ответ #7 : Августа 01, 2020, 12:46:40 pm »

Так сами же и обозначили вектор развития:
/ввиду перехода на распределённые архитектуры и разделение реал-таймовых задач и "потоковых"/

Если у вас реакция сотни мс, то какая вам разница какой линукс? Любой подойдет.

А что бы с драйверами для PCIe не заморачиваться - делайте свою железку сбора данных в Eth. на ПЛИС.
Записан
Страниц: [1]
  Печать  
 
Перейти в: