Real-time и не-real-time - в одном флаконе или раздельно? Опции

[syoma]

Получается большой черный ящик, с массой входов и выходов, работающий (декларирутеся) в реалтайм и надежно (декларируется).

Вот именно, а еще во-первых мне желательно уложиться в сроки разработки, так как надо продемонстрировать хоть что-то за пару месяцев и в живых условиях. И второе - при подходе все-в-одном изначально придется очень серьезно думать об архитектуре всего ПО, чтобы позднее не напороться на грабли из-за которых придется все полностью переписывать. А такой премиум, как системный архитектор ПО, у меня для этого проекта не предусмотрен.

А какая платформа HW, если не секрет, и какие RTOS рассматриваете ?

Если делать раздельно,то STM32F4 для реалтаймовой части, а для не-реалтаймовой в принципе пофиг, лишь бы вся нужная периферия поддерживалась из Линукса, да модуль/чип подходил для промышленных применений и стоил баксов до 30.
RTOS - только freeware.

[k155la3]

. . . .
Если делать раздельно,то STM32F4 для реалтаймовой части, а для не-реалтаймовой в принципе пофиг, лишь бы вся нужная периферия поддерживалась из Линукса, да модуль/чип подходил для промышленных применений и стоил баксов до 30.
RTOS - только freeware.

У FreeRTOS есть порт под STM32F407. Это если ось потребуется.
Есть еще интересная весч ptotothreads (мне на форуме тут как-то рекомендовали. author Adam Dunkels <adam@sics.se>).
По сути это оболочка для while(1) { }.

[AlexandrY]

Если делать раздельно,то STM32F4 для реалтаймовой части, а для не-реалтаймовой в принципе пофиг, лишь бы вся нужная периферия поддерживалась из Линукса, да модуль/чип подходил для промышленных применений и стоил баксов до 30.
RTOS - только freeware.

Я не так строю систему.
Да, Ethernet представляет некоторую опасность. Поскольку он будет подвергаться постоянному флуду.
Но с тем же успехом флуду подвержен и CAN и RS485 при сбоях оборудования.
Все сетевые стеки должны выбирать между быстродействием и защищенностью.

Но Ethernet одновременно и скоростной протокол, быстрее USB в микроконтроллерной реализации. Если его отделить от CAN-а c RS485, то сразу теряете много возможностей отладки этих самых CAN и RS485.
А в быстрых проектах гибкая и мощная отладка является самой важной.
Доморощенный межпроцессорный протокол по UART-у не спасет, либо выльется еще в больший челендж чем защита Ethernet-а от флуда.
Поэтому однозначно Ethernet у меня стоит на одном борту с CAN и прочими полевыми шинами.
К тому же сам стек TCP с Ethernet в исходных кодах и отладка и поиск ошибок в нем не составляет никаких проблем.
USB проблем не вызывает, там в шине всегда чисто и бояться нечего.
Другое дело Wi-Fi или BLE. Они открыты всем и всегда для флуда и их стеки не даются в исходниках. Вот для них я ставлю отдельные чипы, и связываю по SPI.
Отдельным внешним микроконтроллером можно делать только очень примитивные функции вроде оцифровки, предобработки, фильтрации, генерации сигналов.
Т.е. все то что действительно можно запустить практически без отладки или полностью отсимулировать в MATLAB-е.

Естественно все это относится только к развитым RTOS: Micrium 5, MQX, embOS, Nucleus Plus...
Если иметь в виду FreeRTOS то все будет печальней.
Тогда уже лучше Mbed OS. Там хотя бы есть такая экзотика как гипервизор для защищенного режима. Можно BLE ставить прямо вместе с риалтайм системой.

[mantech]

Да, Ethernet представляет некоторую опасность. Поскольку он будет подвергаться постоянному флуду.
Но с тем же успехом флуду подвержен и CAN и RS485 при сбоях оборудования.
Все сетевые стеки должны выбирать между быстродействием и защищенностью.

И что? Сделайте его неприоритетным процессом, и пусть флудит, на что он может повлиять? Что страничка откроется на неск. мсек позднее, и кому от этого хуже?

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

[k155la3]

У меня сейчас тоже проблема выбора OS или вообще безосевость.
Разве что платформа определена MSP430. Это "бытность данная мне в реальность".

Собственно, если есть возможность - использовать коммерческую OS (и это намного проще-эффективнее),
как рекомендует AlexandrY, но не "в лоб", а с правильными настройками как самой оси,
так и своего разрабатываемого ПО. Тогда и возможен однопроцессорный вариант.
(предполагается, что разработчики ОС выполнили работу качественно, провели всякие сертификации, тесты итд,
и сделали процентов 80 от "проверочной" работы, которую нам надо будет проделать для free OS)
Недостаток один - ЭТО надо покупать и задорого.

С free XXXRTOS - все намного сложнее-неопределеннее, как с выбором собственно OS, так и с ее
опятьже настройкой-адаптацией, дописыванием драйверных модулей.
Достоинство - нет необходимости денежных затрат. Смотря какой вид лицензии, можно ли использовать для коммерческих целей
как встроеннное ПО.

[AlexandrY]

Достоинство - нет необходимости денежных затрат. Смотря какой вид лицензии, можно ли использовать для коммерческих целей
как встроеннное ПО.

Насчет коммерческих осей.
Сейчас на западе на это смотрят проще.
Если ваша компания зарабатывает меньше миллиона долларов в год, то дают исходники бесплатно и не цепляются если вы в ваших поделках там использете их RTOS.
Так сейчас и Micrium делает и Mentor. Мне они так предлагали. uCOS и Nucleus Plus соответсвенно.
Есть такие оси как MQX которые коммерческого уровня, но полностью открыты для использования.
Если исходники не так важны, то вон ThreadX у Renesas, тоже очень развитая ось.
Free оси плохи не тем что некачественные, а тем что скверно документированы и растащены на всякие сомнительные ветки и платформы в которых можно вечно разбираться.
Освоение free оси в разы сложнее коммерческой. Сложнее и поддержка изделий с free осями.

Если же работа с миллисекундами или релейной логикой - то реалтайм там в полной мере представлен.

Реле два раза может клацнуть пока пройдет цикл в 2 мс у ПЛК.
ПЛК который всегда реагирует не раньше 1..2 мс ну никак к реальному времени отнести не могу.

И что? Сделайте его неприоритетным процессом, и пусть флудит, на что он может повлиять? Что страничка откроется на неск. мсек позднее, и кому от этого хуже?

В интернете не просто флудят, а DOS-ят все порты. Ваш-то HTTP сервер небось на одних memcpy да strcpy сделан. А это любимый объект атаки по переполнению.

[syoma]

Собственно, если есть возможность - использовать коммерческую OS (и это намного проще-эффективнее),
как рекомендует AlexandrY, но не "в лоб", а с правильными настройками как самой оси,
так и своего разрабатываемого ПО. Тогда и возможен однопроцессорный вариант.
(предполагается, что разработчики ОС выполнили работу качественно, провели всякие сертификации, тесты итд,
и сделали процентов 80 от "проверочной" работы, которую нам надо будет проделать для free OS)
Недостаток один - ЭТО надо покупать и задорого.

В том-то и дело. Допустим я захочу купить эту ось. Не знаю, сколько в среднем по рынку, но я считаю что качественная ось будет стоить 10к$ за лицензию + еще 10-20$ за рантайм на каждое устройство. При моих количествах примерно 1000 изделий в год выходит, что в себестоимости изделия стоимость оси будет 20-30 баксов, так как обычно через 2 года надо покупать поддержку, которая стоит, как новая лицензия. А ведь за эти деньги уже можно купить чуть ли не компьютер на линуксе.
Так вот стоит оно того?

[AlexandrY]

так как обычно через 2 года надо покупать поддержку, которая стоит, как новая лицензия. А ведь за эти деньги уже можно купить чуть ли не компьютер на линуксе.
Так вот стоит оно того?

Это какая-то ваша внутренняя проблема. Я поднял около 5-ти комерческих осей на голых платформах. Никогда не обращался не только в их тех поддержку, но даже на их форумы.
Главное иметь исходники.

[mantech]

В интернете не просто флудят, а DOS-ят все порты. Ваш-то HTTP сервер небось на одних memcpy да strcpy сделан. А это любимый объект атаки по переполнению.

Чет не понял причем тут ддосы и копирование блока... Пускай, забьют мне весь канал по езернету, да, вебка открываться не будет, и все! Причем тут копирование? Забьют весь пул стека, ну и пусть, больше, чем нужно выделить не получится - сработает ограничение, в чем проблема - не понятно. Если вы выделяете память без ограничений - ну тогда логика тут бессильна

Реле два раза может клацнуть пока пройдет цикл в 2 мс у ПЛК.

И что это за "реле" такое, которое за 1 мсек срабатывает SSR - так это уже не реле в классическом понимании.

[syoma]

Это какая-то ваша внутренняя проблема. Я поднял около 5-ти комерческих осей на голых платформах. Никогда не обращался не только в их тех поддержку, но даже на их форумы.

Конечно, я о ней уже писал. Она называется "отсутствие квалифицированного специалиста, который способен поднять 5 коммерческих осей на голых платформах". И вторая проблема, как я уже тоже писал - одного портирования операционки мало, нужна архитектура.

ПЛК который всегда реагирует не раньше 1..2 мс ну никак к реальному времени отнести не могу.

Во многих системах реального времени опрос входов и выходов осуществляется с периодами и побольше этих. Естественно и реакция в худшем случае будет соответствующей. Тем не менее, это реальное время.

[mantech]

Допустим я захочу купить эту ось. Не знаю, сколько в среднем по рынку, но я считаю что качественная ось будет стоить 10к$ за лицензию + еще 10-20$ за рантайм на каждое устройство

Вот на это и рассчитывают, купят, а потом еще разбираться с ней... А по началу представляют, что раз уж стоит столько, так все остальное в шоколаде будет

Освоение free оси в разы сложнее коммерческой. Сложнее и поддержка изделий с free осями.

Я поднял около 5-ти комерческих осей на голых платформах. Никогда не обращался не только в их тех поддержку, но даже на их форумы.
Главное иметь исходники.

Два взаимоисключающих высказывания - т.е. у фри-осей исходников нет, или у коммерческих они какие-то особенные...
Отличие лишь в том, что там побольше их и, надеюсь, они лучше протестированы, хотя не факт.

Сообщение отредактировал mantech - Oct 28 2017, 15:48

[k155la3]

. . .
Так вот стоит оно того?

СтОит или нет - зависит от ментальности, географического местоположения и конечной цены продукта

Для выпуска прототипа, если есть возможность, лучше взять готовое решение "по макисмуму", те это коммерческая OS
с исходником, документацией, требуемыми драйверными модулями.
После принятия прототипа "за основу" и невозможности использовать эту комм. OS -
подобрать подходящее из free и де-портировать ( ) работающий прототип "туда".

ps
Есть альтеннатива следующего вида. Решение, которое предоставляет производитель.
П.О. TexasInstriments:
Операционная система: Ti-RTOS / SYS-BIOS / MSP430 (TCP, Ethernet нет) Процессоры Ti
Процессоро-зависимый набор драйверов: DriverLib (библиотека в исходниках, встроенная периферия)
Среда разработки: Code Composer Studio (компилятор, IDE)

[mantech]

Для выпуска прототипа, если есть возможность, лучше взять готовое решение "по макисмуму", те это коммерческая OS
с исходником, документацией, требуемыми драйверными модулями.
После принятия прототипа "за основу" и невозможности использовать эту комм. OS -
подобрать подходящее из free и де-портировать ( sm.gif ) работающий прототип "туда".

Шедеврально!! Т,е. заплатить кучу бабок за эту ось, вникнуть в нее, сделать проект... А потом, да ну ее нафиг, делаем на бесплатной... Один вопрос - зачем такой мазохизм???

[Студент заборстр...]

У нас как раз почти-промышленный контроллер - логика управляет достаточно ответственным оборудованием, поэтому зависание может привести к серьезным поломкам.

В нормально спроектированной RTOS зависание не возможно

ПЛК который всегда реагирует не раньше 1..2 мс ну никак к реальному времени отнести не могу.

Понятие "реальное время" перпендикулярно тому, через сколько времени ртось среагирует на событие.

Если ртось УСПЕВАЕТ ВОВРЕМЯ среагировать и обработать евент за ДЕТЕРМИНИРОВАННОЕ время и это время устраивает заказчика, значит это ртось. Даже если время реакции сотни милисекунд

К примеру если цикл ПЛК 0.5 секунды то нафига успевать среагировать и обрабатывать евент за микросекунды?

Сообщение отредактировал Студент заборстроительного - Oct 28 2017, 17:56

[k155la3]

Шедеврально!! Т,е. заплатить кучу бабок за эту ось, вникнуть в нее, сделать проект... А потом, да ну ее нафиг, делаем на бесплатной... Один вопрос - зачем такой мазохизм???

Вы мне льстите (шедеврально). В моем посте слово "заплатить" не фигурировало.
Хотя еслиб масштаб цен позволял - покупал бы.