Прошу прощения за поднятие столь старой темы, но я недавно также столкнулся с данной проблемой и как отправную точку своих поисков использовал эту тему, поэтому чувствую себя обязанным поделится находками здесь.
В общем есть утилита loadfonts которая позволяет загрузить искомые шрифты перед devc-con, проверено на QNX 6.5 SP1, утилита и инструкции лежат на GitHUBе: https://github.com/raspopov/loadfont
1
: Ноября 07, 2020, 10:26:42 pm
|
||
Автор Karenin - Последний ответ от ryo-oh-ki | ||
2
: Августа 01, 2020, 12:46:40 pm
|
||
Автор GrayCat - Последний ответ от longest | ||
Так сами же и обозначили вектор развития:
/ввиду перехода на распределённые архитектуры и разделение реал-таймовых задач и "потоковых"/ Если у вас реакция сотни мс, то какая вам разница какой линукс? Любой подойдет. А что бы с драйверами для PCIe не заморачиваться - делайте свою железку сбора данных в Eth. на ПЛИС. |
3
: Июля 17, 2020, 09:40:07 am
|
||
Автор GrayCat - Последний ответ от GrayCat | ||
м.б. вместо рекламы Линукс, Вы пишите а конференцию КПДА отдельно по каждому проблемному вопросу и просите подсказать решение. Думаю, многим будет интересно, а КПДА должна будет отвечать. А чего писать-то?!... Их ответы мы и так прекрасно все предсказать можем:
КПДА ведёт свою "узкую" ветку под уже существующих заказчиков. Для сообщества, они уже потеряны. Сами авторы QNX сменили парадигму, и тоже уже работают под конкретных клиентов. Всё, в качестве общедоступной универсальной Self-Hosted системы с полноценным GUI, QNX потеряна. Поддержки современных дискретных видеокарт -- нет и не будет. Встроенная графика Intel -- исключительно по милости КПДА, причём в любой момент следующая версия их драйвера перестанет работать в "коробочной" 6.5.0. Поддержка USB 3.0 -- после сервис-пака худо-бедно есть, но, например, на современных материнках вы уже не загрузите Live-CD по-нормальному. Плюс, постоянно какие-то траблы с конкретными моделями USB-мышек и клавиатур, а также удлиннителями USB. Отдельная тема -- мультипортовки (RS-232, RS-485). Шина PCI отмирает, а новые PCI-Express платы требуют специфических драйверов. Которые под QNX никто не напишет. Сетевы ...Перечислять можно долго. "Родители" QNX систему забросили, КПДА -- жадные барыги с ограниченными ресурсами. Да и потребность в QNX в качестве основы для "PLC + HMI" в наше время объективно снижается, ввиду перехода на распределённые архитектуры и разделение реал-таймовых задач и "потоковых". Но вот у нас, например, в маленькой сельскохозяйственной компании, мы такого сделать не можем. Менять полностью архитектуру нескольких десятков объектов с АСУ ТП нам никто не даст. Так что, смотрим в сторону варианта "Написать систему такую же как у нас но на Linux". Вот отсюда и вопросы, упомянутые в шапке темы. В какую сторону двигаться? |
4
: Июля 14, 2020, 07:36:33 am
|
||
Автор GrayCat - Последний ответ от LH | ||
м.б. вместо "рекламы Линукс", Вы напишите а конференцию КПДА отдельно по каждому проблемному вопросу и попросите
подсказать решение. Думаю, многим будет интересно, а КПДА должна будет отвечать. Сомнения, изложенные Вами, волнуют и другие трудовые коллективы разработчиков (известно по собственному опыту). Спасибо. |
5
: Июля 13, 2020, 11:16:06 am
|
||
Автор GrayCat - Последний ответ от GrayCat | ||
О, уже лучше, пошло обсуждение.
А то я попытался аналогичную тему на КПДА поднять, так меня там чуть ли не забанили с формулировкой -- ХА-ХА! -- за "Рекламу Linux"! ![]() ![]() ![]() Есть ли у кого-нибудь конкретные цифры, типа как в упомянутой выше работе? Вон у них там график очень показательный. |
6
: Июля 09, 2020, 12:53:09 pm
|
||
Автор GrayCat - Последний ответ от darkelf | ||
Мы использовали Линукс с ядром PREEMPT_RT - в принципе после определённых доработок более-менее добились обеспечения цикла 1 мс. Всё реализовано на уровне прикладных задач, ядром дорабатывалось в плане убирания, в некоторых местах, излишнего PREEMPT_RT (был отдельно обработчик аппаратного прерывания, отдельно ядерный поток, который активировался из обработчика, а был прикладной поток, который активировался из ядерного потока, пришлось исключать ядерный поток и напрямую активировать прикладной).
|
7
: Июля 09, 2020, 08:00:30 am
|
||
Автор GrayCat - Последний ответ от LH | ||
У нас контроллер под QNX (наряду с другими работами) с легкостью выдает управляющие
команды через ЦАП на объект управления с периодом выдачи 1мс (требование ТЗ). Какая альтернатива при смене ОС ? |
8
: Июля 08, 2020, 06:59:53 pm
|
||
Автор GrayCat - Последний ответ от A_O | ||
У меня есть работающая система ЧПУ под Линуксом. Правда, там только обмен данными с контроллером по Ethernet/UDP - порядка 100 байт туда-обратно с постоянным периодом 10 мс, по инициативе контроллера, и графика не очень сложная (отображение движения рабочего органа по плоскому контуру). Работает без всяких RT примочек, обычный пользовательский процесс. Разумеется, цикл обмена выделен в отдельную нить с максимальным приоритетом.
|
9
: Июля 07, 2020, 10:09:57 am
|
||
Автор GrayCat - Последний ответ от GrayCat | ||
Приветствую аксакалов!
В связи с переходом экосистемы 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. Насколько я понял, варианты сейчас следующие:
Вот и хочу я проконсультироваться с сообществом. Кто-нибудь сравнивал именно QNX с этими вариантами? Например, вот как Линуксные модификации между собой: http://pdfs.semanticscholar.org/9eb5/1dbe38fb23034e80b8664d8281996d2a5ef6.pdf?_ga=2.115305735.1422742923.1510677552-1828769110.1510677552 -- большая работа проведена, очень наглядные цифры получены. Но, насколько это соотносится с QNX? В какую сторону посоветуете смотреть? Время пока есть, можно не спеша выбрать вектор развития, но вот упереться в тупик как сейчас с QNX -- очень не хотелось бы. |
10
: Апреля 26, 2020, 01:45:20 am
|
||
Автор qnx_user - Последний ответ от qnx_user | ||
Подскажите пожалуйста, можно ли из обработчика tto, каким-то образом узнать открыто ли устройство?
У меня есть некий самописный драйвер, который представляет собой пару устройств символьного ввода/вывода (например /dev/v1 и /dev/v2) связанных друг с другом, v2 связан с v1 через (TTYDEV*)dev->extra (и наоборот так же). Когда в v1 поступают данные, они просто передаются в v2. Код функции: Код: (обработчик tto) int tto ( TTYDEV *dev, int action, int arg1 ) Если, например в v1 писать данные, а v2 не открыт на чтение, то данные буферизируются в его входном буфере и если его открыть спустя какое-то время, то будут вычитаны ранее записанные в него данные (даже если v1 уже отвалился). Мне требуется, в случае если v2 не открыт на чтение, не производить в него запись из v1.{ 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); } Спасибо! Возможное решение: Нашел в структуре TTYDEV атрибутивную запись на устройство, в которой есть поле ext->attr.rcount - число читателей, наверное можно использовать его. P.S. Может быть тут еще есть живые ![]() |