Есть задача управления некими девайсами, забирать с них данные и отправлять команды надо регулярно. Раньше было 100 гц и более-менее нормально справлялась Windows Embedded. Сейчас требуется увеличить точность периода до 1мс и поднять частоту до 300-500 гц. Винда тут уже не помощник. Приём\передача данных по UDP и по RS-485 через платы MOXA.
Логичным выглядит переход на ОСРВ. Выбор между совместными с windows системами типа RTX или InTime, и полноценными ОС типа QNX. Linux теоретически рассматриваю, но с опенсорсом как-то наелся уже, по моему опыту как повезёт, можно крупно попасть на сырую недоделку.
Если кто-то имел опыт подобной разработки, помогите пожалуйста с выбором.
Здравствуйте, Тёма, Вы писали:
Тё>Сейчас требуется увеличить точность периода до 1мс и поднять частоту до 300-500 гц. Винда тут уже не помощник.
На современном железе ядро обычной (XP/7/8/8.1) винды с легкостью обрабатывает частоту событий до 800-1000 Гц и обеспечивает точность периода до 400-500 мкс. Стабильность нарушают исключительно драйверы — как левые, так и некоторые встроенные. Часто гадят видеодрайверы, сетевые, драйверы сопряжения с ACPI и ноутбучными контроллерами (EC). Во многих случаях можно подобрать версии/конфигурации, в которых задержки будут достаточно малы. Подозреваю, что в Embedded можно проделать то же самое. Если винда, как среда выполнения, привычна и удобна — логичнее допилить ее, нежели осваивать новую ОС.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Здравствуйте, Тёма, Вы писали:
Тё>>Сейчас требуется увеличить точность периода до 1мс и поднять частоту до 300-500 гц. Винда тут уже не помощник.
ЕМ>На современном железе ядро обычной (XP/7/8/8.1) винды с легкостью обрабатывает частоту событий до 800-1000 Гц и обеспечивает точность периода до 400-500 мкс. Стабильность нарушают исключительно драйверы — как левые, так и некоторые встроенные. Часто гадят видеодрайверы, сетевые, драйверы сопряжения с ACPI и ноутбучными контроллерами (EC). Во многих случаях можно подобрать версии/конфигурации, в которых задержки будут достаточно малы. Подозреваю, что в Embedded можно проделать то же самое. Если винда, как среда выполнения, привычна и удобна — логичнее допилить ее, нежели осваивать новую ОС.
Это труднопрогнозируемый по сроку путь в никуда =)
Оно ещё и от железа зависит. Каждый раз при заказе железа под новый проект с вероятностью 0.3 вылазит что-нибудь типа "компонент Х внезапно под 8 недель и только от 20 штук" и приходится куда-то менять конфиг. И сразу вся эта тонкая настройка слетает.
А про драйверы вы правы. Больше всего картину портила запись на диск и, внезапно, включенная опция Energy Efficient Ethernet у сетевухи.
Но даже сейчас, после всех настроек на которые мне хватило мозгов, винда может раз в пол часа-час выдать 20-30 мс вместо 10, и даже это критично.
Вобщем, можно и дальше закручивать шестигранный болт шлицевой отверткой. Но в какой-то момент уже надо купить соотв. ключ =)
Здравствуйте, Тёма, Вы писали:
Тё>Оно ещё и от железа зависит. Каждый раз при заказе железа под новый проект с вероятностью 0.3 вылазит что-нибудь типа "компонент Х внезапно под 8 недель и только от 20 штук" и приходится куда-то менять конфиг. И сразу вся эта тонкая настройка слетает.
А на неизвестном заранее железе Вы с любой ОС будете с высокой вероятностью иметь геморрой. Гарантировать величину задержек можно лишь на "аппаратно-программном комплексе", тут без вариантов.
Если не нужны навороченные аппаратные конфигурации — попробуйте посмотреть в сторону компактных SoC на ARM/MIPS, как в виде независимых плат типа Raspberry, так и каких-нибудь маршрутизаторов с поддержкой OpenWRT/DD-WRT и прочих открытых систем. Но там, соответственно, будет тот самый геморрой с опенсорсом.
Тё>Больше всего картину портила запись на диск и, внезапно, включенная опция Energy Efficient Ethernet у сетевухи.
Как раз не "внезапно", а вполне закономерно. Все эти "экономичные" режимы порой реализуются через периодическое отключение приемопередающей части, а обработка возникающих при этом дополнительных событий делается до ужаса криво, через те же процедуры инициализации, что и в стартовом коде драйвера. То есть — последовательно, с циклами ожидания от сотен микросекунд до единиц миллисекунд.
Тё>Вобщем, можно и дальше закручивать шестигранный болт шлицевой отверткой. Но в какой-то момент уже надо купить соотв. ключ =)
Беда в том, что для Ваших болтов универсального ключа не существует в природе. Разве что наборы, которые все равно придется так и ли иначе дотачивать под каждый из очередных болтов.
Тё>Это труднопрогнозируемый по сроку путь в никуда =) Тё>Оно ещё и от железа зависит. Каждый раз при заказе железа под новый проект с вероятностью 0.3 вылазит что-нибудь типа "компонент Х внезапно под 8 недель и только от 20 штук" и приходится куда-то менять конфиг. И сразу вся эта тонкая настройка слетает.
Mach3 — ПО для управления ЧПУ управляет по LPT четыремя шаговиками, выдавая и больше 1КГц на каждый, плюс PWM сигнал на скорость шпинделя. Ну и входные сигналы обрабатывает. На случайно найденой на помойке плате 10+ лет старости. Правда, он драйвер какой-то свой ставит.
Тё>А про драйверы вы правы. Больше всего картину портила запись на диск и, внезапно, включенная опция Energy Efficient Ethernet у сетевухи. Тё>Но даже сейчас, после всех настроек на которые мне хватило мозгов, винда может раз в пол часа-час выдать 20-30 мс вместо 10, и даже это критично.
А, ну это не знаю, может и бывает так, и тот же Mach3 в этих случая косячит
Слышал про RT Linux вроде — какое-то риал тайм ядро типа в режиме гипервизора как-то, а под ним линукс крутится. Вроде и ОС, а вроде и риалтайм доступен
Здравствуйте, Тёма, Вы писали:
Тё>Есть задача управления некими девайсами, забирать с них данные и отправлять команды надо регулярно. Раньше было 100 гц и более-менее нормально справлялась Windows Embedded. Сейчас требуется увеличить точность периода до 1мс и поднять частоту до 300-500 гц. Винда тут уже не помощник. Приём\передача данных по UDP и по RS-485 через платы MOXA. Тё>Логичным выглядит переход на ОСРВ. Выбор между совместными с windows системами типа RTX или InTime, и полноценными ОС типа QNX. Linux теоретически рассматриваю, но с опенсорсом как-то наелся уже, по моему опыту как повезёт, можно крупно попасть на сырую недоделку. Тё>Если кто-то имел опыт подобной разработки, помогите пожалуйста с выбором.
А чем вам Windows Embedded Compact не подходит ( только не просто windows embedded ), вполне себе hard real time.
ну а так все зависит от того сколько вы готовы заплатить, vxworks, qnx, windows ce,...
Здравствуйте, Тёма, Вы писали:
Тё>Есть задача управления некими девайсами, забирать с них данные и отправлять команды надо регулярно. Раньше было 100 гц и более-менее нормально справлялась Windows Embedded. Сейчас требуется увеличить точность периода до 1мс и поднять частоту до 300-500 гц. Винда тут уже не помощник. Приём\передача данных по UDP и по RS-485 через платы MOXA. Тё>Логичным выглядит переход на ОСРВ. Выбор между совместными с windows системами типа RTX или InTime, и полноценными ОС типа QNX. Linux теоретически рассматриваю, но с опенсорсом как-то наелся уже, по моему опыту как повезёт, можно крупно попасть на сырую недоделку. Тё>Если кто-то имел опыт подобной разработки, помогите пожалуйста с выбором.
Здравствуйте, ioni, Вы писали:
I>А чем вам Windows Embedded Compact не подходит ( только не просто windows embedded ), вполне себе hard real time. I>ну а так все зависит от того сколько вы готовы заплатить, vxworks, qnx, windows ce,...
С Windows CE был небольшой опыт лет 7 назад, тогда пришёл к выводу, что без BSP от производителя железа её не запустить, а железо я сам подбираю. Можно в принципе попробовать еще раз, много времени прошло.
А по цене да, узнали цены на QNX и RTX и как-то поостыл пыл всё переделать под ОСРВ =) Буду выпрашивать триал и оценивать по конкретному результату.
Документ из ответа ниже интересный, посмотрю, спасибо.
Здравствуйте, LuciferSaratov, Вы писали:
LS>Здравствуйте, Тёма, Вы писали:
Тё>>А по цене да, узнали цены на QNX и RTX
LS>странно, что тут никто до сих пор FreeRTOS не упомянул. LS>вроде бы вполне зрелое решение, есть и поддержка за деньги, если надо.
Ещё есть вот такая штука , вроде не менее популярная чем freeRTOS.
Здравствуйте, Marty, Вы писали:
M>Mach3 — ПО для управления ЧПУ управляет по LPT четыремя шаговиками, выдавая и больше 1КГц на каждый, плюс PWM сигнал на скорость шпинделя. Ну и входные сигналы обрабатывает. На случайно найденой на помойке плате 10+ лет старости. Правда, он драйвер какой-то свой ставит.
Не думаю, что там точное время важно. Главное выдать нужное количество импульсов на все двигатели синхронно. Драйвер, скорее всего, для прямого доступа к LPT.
В PWM с LPT я не очень верю, только если на низкой частоте и не очень точно.
M>Слышал про RT Linux вроде — какое-то риал тайм ядро типа в режиме гипервизора как-то, а под ним линукс крутится. Вроде и ОС, а вроде и риалтайм доступен M>ЗЫ А, Линукс не торт, сорри
В целом торт, но по моему опыту количество подводных граблей в опенсорсе может быть очень большим. Всё сильно зависит от конкретного проекта.
Здравствуйте, Тёма, Вы писали:
Тё>С Windows CE был небольшой опыт лет 7 назад, тогда пришёл к выводу, что без BSP от производителя железа её не запустить, а железо я сам подбираю.
Так BSP — это, по сути, тот же набор драйверов железа, только не динамически подключаемый, а линкуемый непосредственно в ядро.
Если у Вас непостоянная аппаратная конфигурация — без драйверов Вам в любом случае не обойтись. А гарантировать того, что они не будут портить время отклика, никто, разумеется, не сможет.
Я бы для начала попробовал ту же XP Embedded на многоядерном процессоре, приняв меры для распределения кода по ядрам. Сгодится даже двухъядерный, если первое ядро отдать под обработчики прерываний и системый код, а на втором гонять только код, критичный к задержкам, и без крайней нужды не пользоваться примитивами, захватывающими общие блокировки или вызывающими IPI (к ним, кстати, относится и DbgPrint).
