Последние сообщения

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

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

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

[универсальной]

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

А чего писать-то?!... Их ответы мы и так прекрасно все предсказать можем:

• "Напишите в наш отдел продаж, обсудим вопрос оплаты написания драйвера под вас".
• "На данный момент, эта фича не реализована".
• "Чтобы реализовать, напишите в наш отдел продаж, обсудим вопрос оплаты написания фичи под вас".

КПДА ведёт свою "узкую" ветку под уже существующих заказчиков. Для сообщества, они уже потеряны. Сами авторы 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".

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

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

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

Спасибо.

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

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

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

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

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

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

У меня есть работающая система ЧПУ под Линуксом. Правда, там только обмен данными с контроллером по Ethernet/UDP - порядка 100 байт туда-обратно с постоянным периодом 10 мс, по инициативе контроллера, и графика не очень сложная (отображение движения рабочего органа по плоскому контуру). Работает без всяких RT примочек, обычный пользовательский процесс. Разумеется, цикл обмена выделен в отдельную нить с максимальным приоритетом.

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

В связи с переходом экосистемы 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 -- очень не хотелось бы.

[Возможное решение:]

Подскажите пожалуйста, можно ли из обработчика tto, каким-то образом узнать открыто ли устройство?

У меня есть некий самописный драйвер, который представляет собой пару устройств символьного ввода/вывода (например /dev/v1 и /dev/v2) связанных друг с другом, v2 связан с v1 через (TTYDEV*)dev->extra (и наоборот так же).
Когда в v1 поступают данные, они просто передаются в v2. Код функции:

Код: (обработчик tto)

int tto ( TTYDEV *dev, int action, int arg1 )
{
TTYDEV *ext = dev->extra;
int status = 0;
char c;

switch ( action )
{
//case TTO_STTY:
//case TTO_CTRL:
//case TTO_LINESTATUS:
// return 0;

case TTO_DATA:
//case TTO_EVENT:
break;

default:
return 0;
}

while ( dev->obuf.cnt > 0 )
{
/*
// Если входной буфер внешнего tty заполнился - уходим.
if ( ext->ibuf.cnt >= ext->ibuf.size ) {
dev->un.s.tx_tmr = 3; // Timeout
break;
}
*/

if ( dev->flags & (OHW_PAGED|OSW_PAGED) && !(dev->xflags & OSW_PAGED_OVERRIDE) ) {
dev->un.s.tx_tmr = 3; // Timeout
break;
}

// Получаем символ из obuf
dev_lock( dev );
c = tto_getchar( dev );
dev_unlock( dev );

// Отправляем на внешнее устройство
status |= tti( ext, c );
dev->un.s.tx_tmr = 3;  // Timeout
if ( dev->xflags & OSW_PAGED_OVERRIDE )
{
atomic_clr(&dev->xflags, OSW_PAGED_OVERRIDE);
break;
}
}

if ( status )
iochar_send_event( ext );

    return tto_checkclients(dev);
}

Если, например в v1 писать данные, а v2 не открыт на чтение, то данные буферизируются в его входном буфере и если его открыть спустя какое-то время, то будут вычитаны ранее записанные в него данные (даже если v1 уже отвалился). Мне требуется, в случае если v2 не открыт на чтение, не производить в него запись из v1.

Спасибо!

Возможное решение:
Нашел в структуре TTYDEV атрибутивную запись на устройство, в которой есть поле ext->attr.rcount - число читателей, наверное можно использовать его.

P.S. Может быть тут еще есть живые

Маршрутизацию смотрел, не вижу, что не так. Или нужно явно сеть 192.168.55 добавлять?

Код:

Routing tables
Destination      Gateway            Flags     Refs     Use  Interface

Route Tree for Protocol Family 2:
(root node) =>
default          192.168.54.21      UG          0     2809  en1
127.0.0.1        127.0.0.1          UH          1   208287  lo0
192.168.206.25   192.168.206.26     UH          1        0  sl0
192.168.206.26   127.0.0.1          UH          0        0  lo0
192.168.54       192.168.54.10      U           6    67828  en1
(root node)