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

Сообщений: 129


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

Сообщений: 129


Просмотр профиля
« Ответ #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 (был отдельно обработчик аппаратного прерывания, отдельно ядерный поток, который активировался из обработчика, а был прикладной поток, который активировался из ядерного потока, пришлось исключать ядерный поток и напрямую активировать прикладной).
Записан
Страниц: [1]
  Печать  
 
Перейти в: