Версия для печати темы

Автор: syoma Oct 26 2017, 09:41

Привет. Собственно вопрос из области начинающих по архитектуре процессорной системы. Делаем новый проект и возник вопрос.
С одной стороны есть программа, работающая в жестком реальном времени с коммуникацией, через CAN, SPI и RS485. Это основная функция системы.
С другой стороны есть куча других интерфейсов - SD card, Ethernet, USB и прочих, которые служат для вспомогательных функций - записи логов, параметрирования, обновления ПО, удаленного доступа через WEB и bluetooth, терминалки и т.д.

Если все это реализовывать на одном процессоре, то получается, что надо использовать RTOS, что требует определенных программистских навыков и не нравится то, что это уменьшает защиту системы от внешних хакерских атак. Если из-за Ethernetа зависнет основная программа - это будет очень-очень плохо. Т.е. в результате увеличиваем затраты на разработку, делаем сложную программу, но уменьшаем стоимость железа.
Поэтому у меня настрой такой, что основной процессор должен выполнять только основную real-time программу и все. При этом ему не нужна операционная система вообще, так как нужные интерфейсы реализуются как функции ввода/вывода - это уже реализовано и проверено.
А для всего остального поставить отдельный процессор или даже платку, на которой будет крутиться обыкновенный Linux со всеми нужными драйверами. И с основным процессором эта плата будет общаться только через CAN. В этом случае практически все функции будут уже реализованы в самом ядре и программисту надо будет сделать очень мало и хоть на питоне или джаве. То есть затраты на разработку будут гораздо меньше, имеем барьер от хакерских атак - если этот процессор зависнет, система будет прекрасно работать дальше, но увеличиваем стоимость железа.

Как думаете это нормальный подход сегодня?

Автор: Kabdim Oct 26 2017, 10:36

А RTOS у которой в кач-ве guestOS крутится тот же linux чем не нравится? Ну или SoC которые и так совмещают процы A и М серии.

Автор: k155la3 Oct 26 2017, 10:52

В промышленных контроллерах (PLC) практикуется "разнесение" функций собственно контроллера и
"вспомогательных" функций-процессов на сопроцессоры. По крайней мере, так было лет 10-20 назад.
Собственно PLC обеспечивал реалтайм логику и основные коммуникации, тоже в рамках реалтайм.
Вспомогательные функции выносились в специализированные модули - коммуникационные процессоры, функциональные модули
(например "быстрые" счетчики для энкодеров), панели операторов итд.
Это на мой взгляд сделано для обеспечения надежности. (завес коммуникационного процессора не выводит из работы
собственно PLC, тк это может очень дорого стоить)
Еслиб бы Ваша система "набиралась" из модулей пром. PLC:
- Процессорный блок с RS485, CAN
- Коммуникационный (со) процессор - SD card, Ethernet, USB, HMI
"общение" - по SPI с использованием линий апп. прерываний в обе стороны.

Автор: syoma Oct 26 2017, 11:57

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

Не нравится стоимостью затрат на реализацию, когда с точки зрения преимуществ дает мало.

Автор: AlexandrY Oct 26 2017, 12:24

Да будет вам известно, что PLC никакой риалтайм не обеспечивают.
Там всегда есть такое окошко с показателем нагрузки процессора,
и если вы не следите за ним в ручном режиме и сами не спланировали задачи как надо, то рухнет весь этот риалтайм.
Более того, если на своей платформе вы можете прицизионно профайлить, то на PLC вам это не удастся.

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

Автор: syoma Oct 26 2017, 12:44

Ну вот с другой сторону смотрю на системы типа TwinCAT и Codesys, которые стоят не в одном десятке мировых промышленных ПЛК. И получается, что там все в одном флаконе крутится - и реалтайм и всякие Скады с Веб-визуализациями. Но там народ, наверное годами софт отлаживал, а у меня столько времени нет. А за портирование того же CodeSys рантайм просят 15кевро + лицензия за каждый девайс.

Автор: Lagman Oct 26 2017, 13:39

Вы смешали две сущности, реалтайм и скаду. Скада в основном это отображение, сбор, обработка и хранение информации ну и иногда управление и это верхний уровень (хотя это тоже под вопросом, т.к. если вы занимаетесь бизнес процессами то скада это нижний уровень) для автоматизации технологического процесса, а вот PLC считается нижним но и тут реалтайм очень ограниченный, так как любой PLC имеет ограничение на количество точек и частоту опроса точки, но хорошо работает с верхним уровнем, почти в реалтайме.

Автор: AlexandrY Oct 26 2017, 14:15

Если 15кевро, то значит портирование плевое дело, на месяц работы.
Вы как будто не в Европе живете.

Автор: syoma Oct 26 2017, 14:38

Сорри, неправильно сказал - 15к - это за тулкит - лицензию и исходники с библиотеками. Портирование сюда не входит.

Автор: k155la3 Oct 26 2017, 14:59

Если под реалтаймом, в данном случае подразумевать, что входной сигнал/состояние на "входе" системы
будет принят-зафиксирован-обработан, и выдан управляющий сигнал - в течение определенного времени,
то, естественно, обеспечивает. Время порядка единиц-десятков мс.
А как иначе ? На входах сложилась аварийная комбинация сигналов, надо выдать сигнал на отключение,
а на оп. панели нарисованы "часики" ? (я понимаю, что аварийные цепи-защиты делаются аппаратно).

Автор: AlexandrY Oct 26 2017, 17:08

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

Автор: k155la3 Oct 26 2017, 17:21

Ok.

Автор: syoma Oct 27 2017, 07:50

Ну, скажем так, не везде. У нас в отрасли цепи безопасности требуются еще аппаратные. Но это не отменяет того факта, что контроллер, помимо обеспечения правильности функционирования объекта, также отвечает за защиту оборудования от нештатных ситуаций на более высоком уровне - комбинаций различных условий и состояний объекта, которые уже цепями безопасности не отработаешь, а только на алгоритмическом уровне. Реал-тайм в данном случае означает, что программа в этом контроллере должна вызываться с определенным временным интервалом, который гораздо меньше, чем необходимый для безопасной и правильной работы оборудования и что программный цикл должен всегда выполняться быстрее этого интервала. В противном случае срабатывает ватчдог и контроллер вылетает в безопасное состояние с соответствующим приведением в безопасное состояние всего объекта. В нашей системе программный цикл должен быть в пределах 5мс, в идеале 2мс. ПЛК, кстати на интервалах от 10мс тоже прекрасно справляются с этой задачей, обеспечивая реал-тайм.

Но тема не об этом, а о том, почему стоит комбинировать такой реал-тайм с функциями, которые его не требуют в одном процессоре и какой бенефит это обеспечивает, кроме как удешевления железа. Или стоит ли, наоборот, разделить эти части на разные аппаратные платформы. Какие тренды?

Автор: AlexandrY Oct 27 2017, 08:26

Не все так просто. Сколько микроконтроллеров будет применено решает софт, расстояния и гальванические барьеры.

Автор: k155la3 Oct 27 2017, 10:17

извиняюсь что влез.
Вы правы - насчет удешевления. Если девайс тиражирутся тысячами, то экономия 2-3-5 $ абсолютно оправдана, и впихивание "всего"
в один чип имеет смысл. Если... Если есть гарантированная возможность обеспечить правильность и надежность этого "все в одном".
Это подразумевает или использование готовых (сделанных кем-то) решений, наподобие Codesys, или - серьезные затраты времени
на разработку и тестирование этого монстра. Сразу возникет вопрос об RTOS. Комммерческая (дорого) или Free ?
А есть ли все необходимые драйверные модули для процессорной и внешней периферии ? итд.
И самое главное, сколько людей и какой квалификации должны все это разработать и оттестировать.
Получается большой черный ящик, с массой входов и выходов, работающий (декларирутеся) в реалтайм и надежно (декларируется).
---
Для малых тиражей имеет смысл разделить большой ЧЯ (однопроцессорный) на два:
- ЧЯ1/реалтайм/высокая-надежность и
- ЧЯ2/реалтайм-не-очень/средняя надежность (не очень ответственные процессы).
Тогда разработку и отладку-тестирование этих двух девайсом можно разделить и соотв-но упростить, что повысит надежность каждого. На завершающем этапе - обЪединить эти 2 процессора (каждый из которых уже отлажен), что уже не будет так сложно.
----
IMHO, аднака

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

Автор: syoma Oct 27 2017, 15:20

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


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

Автор: k155la3 Oct 27 2017, 15:47

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

Автор: AlexandrY Oct 27 2017, 17:05

Я не так строю систему.
Да, 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 Oct 28 2017, 12:13

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

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

Автор: k155la3 Oct 28 2017, 13:16

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

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

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

Автор: AlexandrY Oct 28 2017, 14:03

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


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


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

Автор: syoma Oct 28 2017, 14:04

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

Автор: AlexandrY Oct 28 2017, 14:13

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

Автор: mantech Oct 28 2017, 15:41

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



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

Автор: syoma Oct 28 2017, 15:42

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


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

Автор: mantech Oct 28 2017, 15:47

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



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

Автор: k155la3 Oct 28 2017, 16:03

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

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

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

Автор: mantech Oct 28 2017, 17:23

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

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

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


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

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

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

Автор: k155la3 Oct 28 2017, 18:21

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

Автор: mantech Oct 28 2017, 18:28

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



В любом нормально спроектированном софте не возможно, и это факт! Вот только вероятность сделать все правильно обратно пропорциональна сложности софта, и это тоже факт, поэтому чем проще - тем лучше, а проще без оси и динамического выделения памяти, и если задачу можно решить не прибегая к этим двум факторам - это и есть гуд

Автор: syoma Oct 29 2017, 09:35

Извиняюсь, но я был бы полным идиотом, если бы рассчитывал на это. Поэтому каким бы ни был надежным софт, а аппаратный ватчдог в моем проекте должен присутствовать.

Автор: AlexandrY Oct 29 2017, 12:22

Тогда убойный вопрос: откуда вы знаете что ваша программа в ПЛК реагирует за детерминированное время?
В ПЛК есть только цикл и все. Вы только знаете что он выполняется за скажем 2 мс и всегда обновит выходы данными из памяти за это время.
Но будут ли валидные данные в памяти в это время?
ПЛК не гарантирует никаким образом программе выполнение за цикл.

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

Реальное время в современной трактовке - инструмент, а не явление. RTOS - это фреймворк, а не просто планировщик и объекты синхронизации.


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

Автор: mantech Oct 29 2017, 12:25

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

Автор: AlexandrY Oct 29 2017, 12:27

Не видно оснований для такой эвристики.

Автор: mantech Oct 29 2017, 17:20

Сначала копирование строк в проге не понравилось, теперь ватчдог... Вообще-то ватчдог нужен для того, если происходит непредвиденное зависание МК в результате критических сбоев, которые вообще-то не должны происходить изрядно-регулярно. Думаете в вашей любимой MQX их не может быть в принципе?? Или веб-сервер в ней сделан как-то по-другому, без применения функций копирования массивов и строк??

Автор: syoma Oct 29 2017, 19:33

Что значит "готов порвать"? Задача ватчдога как раз в том, чтобы гарантировать реальное время. Т.е. если у меня цикл 5мс, то программа должна выполниться за меньшее время. Как мы можем это гарантировать? Легко - ставим ватчдог, который будет срабатывать, если время выполнения программы превысит 5мс. Данный ватчдог будет возвращать систему в безопасное состояние - в моем случае это отключение всех выходов и ресет микроконтроллера.

В итоге что мы имеем? Либо гарантированное реальное время ЛИБО безопасное состояние. Все, других вариантов нет.

А вопрос насколько часто система будет вываливаться в безопасное состояние как раз зависит от качества софта. В идеале - никогда.


Данный ответ работает и для ПЛК. Если в вашем ПЛК не срабатывает ватчдог и он не вываливается в безопасное состояние, значит его программа выполняется за детерминированное время.

Автор: AlexandrY Oct 30 2017, 06:46

Говорите уже своими словами.
Вотчдог - это авария.
Рушится обмен на всех шинах. Все слэйвы уходят в ступор, появляется непредсказуемая пауза, теряются состояния процессов, прерываются записи на носители и т.д. и т.п.
У вас же такая навороченная программа, работает по всем мыслимым интерфейсам.
И представьте, вам спец приходит и заявляет - у нас жесткий риалтайм, но если что, то все может рухнуть, зато надежно.

В ПЛК не вотчдог, а набор штатных сигналов о нарушениях на шинах связи и проч. проверки. О реальном вотчдоге там нигде ни слова!

Автор: mantech Oct 30 2017, 07:25

Вы можете гарантировать на 100% безотказность ваших программ в неблагоприятных условиях и в режиме 24\7 ?
И если да, то на основании чего, мне очень интересно?
А если нет - то в чем тогда их преимущество ?

Автор: gosha-z Oct 30 2017, 07:34

Безотказность - нет, уменьшить вероятность возникновения аварийных ситуаций - да. Ключевое слово - Functional safety.

Автор: mantech Oct 30 2017, 07:51

Правильно, и в любом случае без ватчдога не обойтись.

Автор: gosha-z Oct 30 2017, 07:53

Весь вопрос в том - что рвать WDog'ом. Поэтому и исповедуется мысль отделять mission-critical части от user interface

Автор: syoma Oct 30 2017, 08:27

И? Реальное время надо уважать. Иначе это будет очередная IoT поделка, коих сегодня развелось очень много.


Можете почитаете доки? Во всех ПЛК, что я видел, есть Watchdog, как программные - следящие за выполнением отдельных задач, так и аппаратные.

Автор: AlexandrY Oct 30 2017, 08:53

Эт вы уже стали играть терминами. Я в такие игры не играю.

Автор: k155la3 Oct 30 2017, 21:21

>> В любом нормально спроектированном софте не возможно, и это факт!

Можно было бы попытаться дать гарантию безошибочности (100 %, или хотябы 9.999 ), если бы весь "продукт" был свой, доморощенный.
до последнего бита и проводка.
1. Читаем errata на ВСЕ что используется из комплекующих, и пытаемся ЭТО предусмотреть в коде.
2. Читаем errata, и "мечтаем", что там моежт появиться в следующей ревизии (но глючек уже в этой).
3. Неоткрытая элементарная частица из Вселенной влетает в ГЛАВНЫЙ РЕГИСТР системы и все рушится.
(одна надежда, что по вероятности ОНО не затронет WD).

Автор: Kabdim Oct 31 2017, 08:21

Странно что никто еще не упомянул про http://electronix.ru/redirect.php?http://www.sigops.org/sosp/sosp09/papers/klein-sosp09.pdf. Если хочется безошибочности - нужно доказывать отсутствие ошибок, вот такая вот почти тавтология.

Автор: AlexandrY Oct 31 2017, 09:51

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

Автор: Kabdim Oct 31 2017, 10:41

Вы не смогли зайти на http://electronix.ru/redirect.php?https://github.com/seL4/l4v?

Автор: syoma Oct 31 2017, 10:52

Ну вообще-то известно, что каждая 9-ка такой гарантии увеличивает стоимость разработки на 100%. Т.е достичь гарантии в 99.9% по сравнению с 99% будет стоить, как новая разработка и так далее. Но мне это и не нужно - в моем проекте в этом случае дешевле угробить оборудование и возместить убытки, чем пытаться защититься от таких сбоев.

Автор: AlexandrY Oct 31 2017, 11:45

Имеете какое-то отношение к этому проекту или просто купились на фразу - "все формально проверено"?
Только взглянул на спецификацию и чуть крыша не съехала.
Вы напрмер можете человеческим языком объяснить что такое higher-order logic?
Чем эти сектанты там вообще занимаются?

Автор: Kabdim Oct 31 2017, 12:05

Если осилите http://electronix.ru/redirect.php?https://hol-theorem-prover.org/, то скорее всего вам не потребуются объяснения. Эти "сектанты" называются прикладными математиками.

Автор: AlexandrY Oct 31 2017, 12:27

Даже не собираюсь.
Изъян этого подхода очевиден. Ребята выдвигают принципиально неосуществимое условие - полностью формализовать спецификацию.

А реальному программису надо хотя бы узнать как в действительности работает API.
Само изучение API превращается в исследование. Так же с аппаратными ресурсами.
"Прикладные математики" здесь отдыхают.

Автор: Kabdim Oct 31 2017, 13:06

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

Автор: mantech Oct 31 2017, 14:10

Даже в этом случае такой гарантии не дадите, если только не мигание светодиодом через программную задержку.

Люди даже в "hellо world" умудряются ошибки вывода в терминал делать...

Автор: Студент заборстроительного Oct 31 2017, 17:18

Потому что "Задача покрытия" относится к задачам NP-класса. Поэтому в общем виде не решается за обозримое время

Автор: AlexandrY Oct 31 2017, 19:31

Не, не то.
Они тестировали спецификацию, а не программу.
Представляете!? Есть чудаки которые сначала пишут спецификацию, тестируют ее каким-то образом с хаскелем, и только потом делают из нее программу.
Но ту программу уже не тестируют.
Эт все равно как если б вы для ваших соленоидов сначала придумали диаграммы состояний и переходов между ними с кучей всяких условий и таймингов, а потом решили проверить нет ли там дидлоков в этой диаграмме.
До реальной программы еще как до луны, но куча работы уже проделана, можете идти требовать надбавку.

Автор: Kabdim Nov 1 2017, 08:34

Ну хватит уже фантазировать о том что не осилили. Это уже какое-то болезненное себялюбие - высасывание контраргументов из фантазий.

Ну и вы я так понимаю статьи не читали, но мнение имеете?

Автор: AlexandrY Nov 1 2017, 08:53

Вы сами-то докажите что что-то поняли?
От вас только ссылки. Такие мы и сами вам можем тонну отгрузить.

Автор: Kabdim Nov 1 2017, 09:04

Если бы вы прочитали первую ссылку, вас бы не пришлось отправлять в раздел 4.3. Но с учетом того что вы не осилил даже это, я в обсуждении с вами в серьезном ключе смысла не вижу. Вы ведь всё равно будете фантазировать любую фигню лишь бы сделать вид что это не вы "не ослили", а "авторы дураки".

Автор: AlexandrY Nov 1 2017, 09:42

Не то чтобы авторы дураки, но скорее не ориентируются в теме те кто дает ссылки на такие работы.
Скажем можете ли вы объяснить зачем нам вот такое доказательство - http://electronix.ru/redirect.php?https://github.com/seL4/l4v/tree/master/proof/infoflow?
Т.е. как его применить программисту embedded шлюза между Ethernet и SPI ?

Автор: Kabdim Nov 1 2017, 09:51

Так насчет вашего первого контраргумента что C код не совпадает с верифицируемым, вы признаете что его придумали?

Автор: AlexandrY Nov 1 2017, 10:40

Нет, конечно.
Если бы действительно читали документ на который ссылаетесь, то знали бы что они сделали код для x86 и его даже не думали проверять.
Да и для ARM они не указали платформу на которой прогоняли код. Это все симуляция.
По ходу это кажется я вам объясняю, как там все устроено.

Автор: Kabdim Nov 1 2017, 10:55

Увольте, ваша фантазия конечно интересная , но я уже прочитал ту статью и многое из ссылок.

Автор: syoma Nov 1 2017, 10:59

Народ все это интересно, но может стоит обсуждать в отдельной теме? Так как к моей теме я не вижу отношения.

Автор: AlexandrY Nov 1 2017, 11:07

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


Ага, теперь сами признайтесь, я прав?

Автор: Студент заборстроительного Nov 3 2017, 03:51

А какие проблемы-то? (я к вопросу темы)
Фоновый поток не реалтайм, а приоритетные потоки - реалтайм.
Тут нет никакой проблемы.
А проблема в том, чтобы при наличии вытесняющей многозадачности низкоприоритетным потокам тоже гарантировать пусть и бОльшее, чем высокоприоритетным потокам, но ГАРАНТИРОВАННОЕ время реакции.

Это проблема хоть и сложней, но вполне решаема.
Я в разработанной мной RTOS её решил

Автор: mantech Nov 3 2017, 07:11

Кто мешает делать критичные ко времени задачи на прерываниях? Никогда проблем с этим не было...

Автор: AlexandrY Nov 3 2017, 08:19

С ваши подходом можно и Windows 10 считать RTOS.
У меня она еще ни разу не зависала, и гарантированно за час откликается на любое событие.

Чем гарантирует время реакции? Своим честным словом?

Автор: mantech Nov 3 2017, 08:57

Да вам везет, у меня винда хоть редко, да зависнет, или ФС слетит при некорректном завершении...

Автор: AlexandrY Nov 3 2017, 09:32

Это не зависания оси, это переход в сервисный режим.
Десктопная винда может себе это позволить, она ж работает под управлением пользователя.
А встроенная винда спокойно обошла бы этот момент.

Автор: syoma Nov 3 2017, 10:55

Ну хотя бы доступ к ресурсам железа, не?

Автор: Pavia Nov 3 2017, 14:39

Для AlexandrY

И каким же образом она гарантирует реальное время? Неужели честным словом Билла Гейтса? - мне правда интересно.
Никогда с реальным временем не работал. А как другие гарантируют?


То что они приходят неизвестно когда и в не своё время. Хотя это можно отрегулировать выше стоящей системой. Как следствие состояние системы неизвестно и окромя как выставить собственный флаг в прерывание вы более ничего не можете. Затем вы должны выйти из прерывания. И если это ОС с вытесняющей многозадачностью, то она должна при первом возможном случае вернуться к обработке прерывания, но уже в определённом состоянии:
а) откладываем текущую и начинаем драйверную задачу.
б) дождаться APC и втиснуть прерывание.
с) синхронизироваться с основным циклом секвенсера.

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

Автор: Студент заборстроительного Nov 3 2017, 15:21

Если поток прерываний слишком большой, он "забьёт" более низкоприоритетные, но все равно реал-таймовые задачи.

Я пошёл по пути гарантированного тайм-слота для задач с приоритетами класса 2


С цитированием по внимательней будьте.
Я так понял, это Вы к вот этому:

А не к тому, что процитировали

Изучив десятки RTOS, теорию их построения и перепробовав различные варианты построения RTOS я в конце концов вообще я отказался от использования прерываний.
Посколько с ними трудно динамически менять приоритет прерываний как тебе заблагорассудится и жесткий реалтайм для всех потоков трудно реализовать.
Точнее у меня работал только одно прерывание. Таймерное.
Все остальные прерывания работали по механизму поллинга их флагов.
Да получился большой оверхед. В том смысле, что процессор почти 70% времени проводил в таймерном прерывании.

Ну и что?
Проблему решил просто: взял проц с более высокой (на 500% выше чем нужно для моих задач) тактовой. И что? сейчас процессоры стоят дешевле грязи. А вот софт к ним стоит огого. Поэтому лучше купить проц подороже, но сэкономить на софте

Зато реализация RTOS получилась очень простой, красивой и надёжной. И жесткий реалтайм получился ГАРАНТИРОВАННЫМ при вытесняющей многозадачности

Более того.
У меня не только была реализована вытесняющая многозадачность. Но и отсутствие зависания даже самых низкоприоритетных потоков.
Посколько классу низкоприоритетных потоков все равно гарантировался тайм-слот

Проблема дедлоков тоже была решена за счет выбора архитектуры построения RTOS

Таким образом у моей RTOS был только один "минус": 70% времени процессора занимал микродиспетчер, находившийся в таймерном прерывании. Т.е. на диспетчеризацию уходило 70% процессорного времени, а на выполнение "полезной работы" - всего 30%. Но с этим можно смириться. Выбрав более мощный проц

Автор: AlexandrY Nov 3 2017, 17:03

Это невозможно по логике. Подумайте еще раз над этой формулировкой. Время не резиновое.

Автор: Студент заборстроительного Nov 3 2017, 17:20

Возможно.
Я даже объяснил как.
Прочитайте несколько раз, что я написал.
Не всегда и не всем с первого раза доходит

Автор: mantech Nov 3 2017, 17:39

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

Автор: syoma Nov 3 2017, 18:17

Если говорить о многозадачности, то у меня будет http://electronix.ru/redirect.php?https://en.m.wikipedia.org/wiki/Rate-monotonic_scheduling, который как раз благодаря отсутствию операционки у меня реализуется на ура. Считаю, что тут изобретать нечего - хотя он, возможно, не самый эффективный по загрузке процессора - до 70%, зато гарантирует все то, что мне нужно.

Автор: Студент заборстроительного Nov 4 2017, 08:17

Поэтому я и пошёл по пути запрета всех прерываний кроме таймерного.
А другие прерывания опрашивал по механизму поллинга.
Я же писал: у меня проц больше 70% времени сидит в обработчике таймерного прерывания, а на "полезную работу" доступно менее 30% процессорного времени.

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


Да плевать на загрузку процессора. Он же железный, вот и пусть пашет.
Труд программиста стоит на порядки дороже чем процессорные такты.
Я когда-то болел болезнью: экономить каждый такт CPU, старался писать код так, чтобы экономить такты. А потом понял, что моё время бесценно, а процессорное стоит копейки.

Автор: Tarbal Nov 5 2017, 03:25

Фигасе!. Что за такое таймерное прерывание?
В двух словах как работает preemptive real-time операционная система. Ядро получает возможность переключить задачу при системном вызове и после обработки прерывания.
Прерывания читают из железа (и пишут в железо) и разрешает семафор достаточно высокоприоритетной задаче, которая как бы является продолжением прерывание, поскольку при выходе из прерывания обработка будет переключена на нее если исполнялясь низкоприоритетная задача, но прерывания уже не будет.
Еще раз. Бежала какая-то низкоприоритетная задача, когда возникло условие для прерывания. Скажем приняли пакет данных в регистры приемника. В прерывании эти регистры копируются в буфер, буфер ставится в очередь буферов и отпускается семафор обработчика принятого буфера. Все. Выходим из прерывания. Эта работа достаточно короткая и в прерывании больше продолжать не надо. Отпущеный семафор меняет условия для ядра и из прерывания вы выходите не в ту задачу, что исполнялясь, а в ту, которая ждала семафора, поскольку ей нечего было обрабатывать. Фактически вы продолжаете обрабатывать прием, но уже не в прерывании.
Закон. Прерывания надо предельно минимизировать. Обработчик таймера, который считает время, вообще должен инкрементировать счетчик и выйти. Ну еще пару таких же простых операций если очень нужно. И все.

Поллинг самое нехорошее решение для реал тайма.
Если писать правильно, то все будет эффективно и с маленькими затратами. Я пару лет назад пытался описать принципы написания програм реального времени, но отчего-то публика начала возмущаться моей нескромностью и топик в котором я начал описывать технику написания програм реального времени перенесли в тему общение. Как мне объяснили, что раз меня не спрашивают, то и нефиг соваться. Так что если вам интересно -- создайте тему. Скажем "Как писать программы реального времени?", а люди будут вам отвечать. Вот тогда у вас будет пища для принятия решений.

Автор: Студент заборстроительного Nov 5 2017, 07:44

Автор: AlexandrY Nov 5 2017, 08:43

Так обработчики прерываний надо рассматривать как фрагменты задач если придерживаться концепции Rate-Monotonic Scheduling ?
Я вот это не понял.
Если смотреть на них, как на фрагменты задач, то тогда ваш подход прямо нарушает принцип монолитности.
Если же прерывания не фрагменты задач, а нечто другое, то какой принцип планирования применить к обработчикам прерываний.
И не будет ли он конфликтовать с Rate-Monotonic Scheduling?
Исходим из того что обработчики прерываний в высоконагруженной встраиваемой системе исчисляются десятками и занимают больше половины процессорного времени.

Автор: syoma Nov 5 2017, 09:05

Интересный вопрос. Вот, допустим, у меня есть два CAN интерфейса, по которым в любой момент могут быть приняты данные, которые нужны одной или нескольким задачам, выполняющимся по RMS. То есть есть новые данные или их нету, задача все равно выполнится в нужное время. Таким образом задача обработчика прерывания приемника CAN - это всего лишь вытащить данные из приемного буфера и обновить нужные переменные, которые используются в задачах.
Тут есть несколько подводных камней. Если чтение из буфера и обновление переменных сделать высокоприоритетной задачей или сразу в прерывании от CAN, то может случиться так, что это произойдет во время выполнения задачи, которая использует эти переменные. У меня это решено так, что каждая задача читает свои входные переменные только один раз вначале цикла и дальше работает только с внутренними переменными. Тогда обновление входных переменных во время исполнения этой задачи не приведет к непредсказуемым результатам.
Либо как бы второй вариант - делаем обработчик буфера самым низкоприоритетным процессом, тогда он не сможет прервать выпоняющуюся задачу и испортить ей данные. Но тогда, если оставшегося времени не хватит, чтобы обработать весь входной буфер, получим ой.

Автор: mantech Nov 5 2017, 09:17

В таком режиме о энергосбережении можно забыть навсегда. В АВРках или простеньких АРМ, на частоте до 100МГц - это наверно и нафиг не нужно, но на частотах 500+ это очень заметно получается.
На счет труда программиста - для себя не вижу никакой трудности использовать прерывания, нежели изврат с поллингом, но тут дело вкуса, конечно...

Автор: Студент заборстроительного Nov 5 2017, 09:24

Какие Ваши годы. У Вас ещё всё впереди.
"О сколько нам открытий чудных..."
Трудностей нет пока задачи относительно простенькие и проц мощный. И устройство не "mission critical"
Только потом не говорите, что я Вас не предупреждал

Автор: mantech Nov 5 2017, 11:29

Своя ОС, проц мощный, работа в режиме 24\7, полет нормальный...

Спасибо, предупрежден

Автор: AlexandrY Nov 5 2017, 13:39

Тут вы сделали себе логичекую ловушку.
Если вы утверждаете, что обработчик пакетов CAN работает у вас в реальном времени, то вам не надо ничего читать в прерывании. В прерывании только взводите флаг наличия пакета.
Читаете пакет и выполняет действия связанные с ним в единой задаче активизирующейся по флагу. Нет необходимости в промежуточной буферизации.
Буферизация, а лучше ковееризация - верный признак отсутствия реального времени.
Обработчик CAN следовательно не работает у вас в реальном времени.
Итого имеем ситуацию - есть ISR который не задача, и есть задача которая не realtime.

Автор: Rst7 Nov 6 2017, 09:23

Moderator: Уважаемые, настоятельно призываю вернуть дискуссию в конструктивное русло. Иначе буду наказывать.

Автор: syoma Nov 6 2017, 09:48

Не очень понял, перефразируйте? Обработчик пакетов CAN читает пакет из приемного буфера(или почтового ящика, если так более понятно) приемника CAN, как только тот оказывается там. Других буферов нет.

Автор: AlexandrY Nov 6 2017, 10:47

Вы допустили возможность прихода нового пакета пока не обработан предыдцщий. А это и есть нарушение реального времени.
Т.е. вы на самом деле не работаете в реальном времени. У вас нет жестко специфицированного дедтайма.

Автор: one_eight_seven Nov 6 2017, 11:35

Хоть я и ваш собесденик, но нет. Это не нарушение.
Физический канал связи может быть быстрее, чем возможности по его обработке. Внутри железок, кстати, очень часто так - шина гораздо быстрее, чем подключенные к ней периферийные устройства. Но эти устройства выполняют свою функцию за вполне детерминированное время.

Так и здесь - шина CAN способна передавать данные быстрее, чем устройство успевает их обрабатывать. И это нормально: шина не является бутылочным горлышком. А вот ваша уверенность в том, что нельзя при этом принимать/передавать пакет данных, а необходимо пользоваться исключительно одиночными транзакциями - это очень странное и даже вредное убеждение.

Автор: syoma Nov 6 2017, 11:38

Не, не. Естественно, подразумевается, что пакет будет обработан до того, как придет следующий. Там всего лишь надо вытащить данные из CAN-пакета и положить их в память - работы с гулькин нос.

Автор: AlexandrY Nov 6 2017, 13:51

Тогда нарушаете принцип RMS. Задача должна быть монолитна. А у вас часть задачи в прерывании, часть в потоке. А между ними может вклиниться другая задача или прерывание.
Да что уж там, признайтесь, никакой вы RMS не используете, правда? Так просто, слышали звон.

Автор: syoma Nov 6 2017, 14:22

Я собираюсь использовать RMS. Если так хочется сделать задачу монолитной, то можно спокойно собирать все CAN-пакеты в буфер, а затем обработать их скопом в самой приоритетной задаче, не нарушая принципов RMS.
Но это все сводится к тому, как привести асинхронные задачи (такие как обработка CAN-пакетов) к синхронным - т.е. задачам в RMS. У вас есть другие решения данной проблемы?

Автор: Tarbal Nov 7 2017, 04:18

Занимаюсь задачами реального времени не один десяток лет, но никогда не слышал о необходимости делать задачи монолитными. "Откуда мол и что это за географические новости"?

Гугл тоже не в курсе:
http://electronix.ru/redirect.php?https://www.google.ca/search?dcr=0&q=Real-time+monolithic+task&spell=1&sa=X&ved=0ahUKEwixnKOTzqvXAhUrxoMKHU3ACb4QBQglKAA&biw=1427&bih=836

Автор: AlexandrY Nov 7 2017, 06:12

Ссылка в тему, спасибо.
К вопросу о монолитности задач. Это вытекает из принципа анализа RMS.
А главная вещь в том анализе - дидлайн.
Значит нет никакого смысла разбивать задачу на два этапа - сначала взять быстро ее данные, потом медленно данные обрабатывать.
Это все равно что поставить себе целью фальшивый дидлайн, а на самом деле иметь гораздо более отдаленный дидлайн. Обман самого себя.
Такие финты в анализе RMS учтены быть не могут.

По вашей ссылке я вышел на более интересную статью - http://electronix.ru/redirect.php?http://www.eecs.umich.edu/courses/eecs571/reading/rm-vs-edf.pdf
Она немного открывает глаза и кстати упоминает подход от "Студент заборстр..."

Автор: Студент заборстроительного Nov 7 2017, 18:23

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

А когда у тебя что-то серьёзное и от того, что у тебя случится дедлок или задача "чуть чуть не успеет" погибнут люди или угробится оборудование стоимостью в миллионы баксов, то вся эта блажь "красиво/не красиво" быстро уходит и остаются простые как гробовая доска железобетонные методы обеспечения надёжности.

Я тоже в своё время игрался с разными концепциями, соблазнившись их красотой, когда писал RTOS "для себя". Чисто из научного интереса.

Но когда задачи стали серьёзными ("жёсткий реалтайм" и никаких дедлоков и "не успела я" иначе будет большой бадабум), то в конце концов пришёл к описанной мной выше реализации

Автор: AlexandrY Nov 7 2017, 20:29

Как нибудь поподробней можете рассказать про свою реализацию?
Сколько задач было? Какое время цикла?

Автор: Tarbal Nov 8 2017, 00:37

Ага понятно. Дайте определение монолитной задачи или укажите где про это можно почитать.

Автор: syoma Nov 8 2017, 09:58

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

Также есть разница по

Тут опять же разные требования и разные решения обеспечения надежности.

Автор: Tarbal Nov 9 2017, 00:34

Да не слушайте вы их.
Для круто надежных разработок есть такой стандарт DO-178B.

Он обходится без чудотворных монолитных задач.

Когда 7 лет назад я работал в компании, которая для авиации делала программы, было только две операционки, которые сертифицированы под это. QNX не была к моему удивлению.
Rate Monotonic Scheduling никак операционку не заменит. Он просто отвечает на вопрос как правильно (и возможно ли) расставить приоритеты задачам, чтобы критические задачи не опаздывали. До формализации этого алгоритма делали так: ставили как подскажет интуиция, а когда выяснялось, что есть проблемы, то исправляли. Я сделал можество устройств, некоторые можно купить на ebay и у меня ни разу не возникало проблем с приоритетами.

Автор: Harbour Nov 9 2017, 02:49

Зачем изобретать, то что придумано более 20 лет назад ? Сегодня один проц (без всяких каличных Cortex-M гибридов) легко тянет обе задачи. RT супервизор счедулит RT-прерывания и RT-задачи, запуская основную ОС как самую низкоприоритетную non-RT задачу, включая все ее non-RT драйвера, в том числе и графические. Вопрос в нужном времени отклика и джиттере. Для Linux один из таких супервизоров реализован в проекте Xenomai. В комплекте идет RT drivers framework где есть и CAN. Пашет на ARM, AARCH64, NIOS, x86, PPC. Поддерживается SMP, в том числе и в RT пространстве, с разными affinity извращениями.
Данный подход позволяет реализовывать hard RT не парясь о жопообразности разработки под уникальные RTOS и наличии поддержки/драйверов под свое железо. Как известно - Linux работает везде и писать под него умеют теперь даже обезьяны, которые случайно засматривались в окна индусских программистов.

Автор: Студент заборстроительного Nov 9 2017, 03:49

Линукс это классно. Линукс - это модно
Только никто не гарантирует, что данный дистрибутив гарантирует отсутствие дедлоков, пропусков прерываний, инверсий приоритетов и пропуска дедлайнов.

Скажут только "вероятность этого мала"

А если у Вас приложения, где вероятность всего перечисленного должна быть не "мала", а "ТОЧНО равна нулю"?

Автор: mantech Nov 9 2017, 08:55

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

Автор: Tarbal Nov 10 2017, 00:42

Да ладно вам.
Вот эта штука принимает и транскодирует (и много чего другого) 32 канала видео одновременно и сделана на Линуксе:
http://electronix.ru/redirect.php?https://www.cisco.com/c/en/us/products/collateral/video/digital-receivers-decoders/datasheet-c78-736419.html

Все зависит от умения.
Одни считют, что пусть компьютер за них думает, а другие учатся.



Я даже больше скажу. Если уметь писать апликации реального времени, то всю работу будут делать периферийные устройства.
Без лишней скромности скажу, что мне иногда удавалось достичь совсем неплохих результатов на довольно скромном процессоре.
Помнится в конце 90х годов надо было сделать мобильный телефон для установки в машину на основе мотороловского StarTac. Сначала хотели делать на 68HC16, но потихоньку съехали на AVR8035. Сделали успешный телефон CMR2100, а потом на его основе сделали TMR2100. Пока я там работал тысяч сто продали. Кстати о качестве. Можете не верить, но не было баг репортов.
Кстати, чтобы два раза не вставать о времени съэкономленном на разработке.
Когда делали TMR2100, то за счет лишнего потраченного времени программистами удалось съэкономить на материалах лишние 2 миллиона долларов. И вы после этого будете утверждать, что не хотите думать как правильно программировать если есть процессоры с дурной силой?

Автор: syoma Nov 10 2017, 06:03

Извиняюсь, но это разве пример real-time в контексте данной темы?

Автор: Harbour Nov 10 2017, 18:13

Точно равна нулю только глупость человеческая, даже заточенные под RT железки ломаются. Linux, в подходе Xenomai, вообще ни на что не влияет - он может даже зависнуть или находится в tripple-fault (oops) состоянии - RT как работало так и будет продолжать работать, проверено не раз. Если хочется гарантий "5 девяток" - делается резервирование. т.е. ставится 2-3 устройства как принято везде в авиа и военке.

Автор: syoma Nov 10 2017, 18:38

На чем проверено? Примеры рабочих железяк можно?

Автор: Tarbal Nov 11 2017, 19:20

В контексте данной темы был поднят вопрос о совместимости real-time и Линукса. Это как раз и пример.

Автор: AlexandrY Nov 11 2017, 19:34

Нет, это не пример.
Покажите фото платы дивайса чтобы мы убедились что все действительно работает на одном ядре, одной шине и одном чипе памяти и без полуавтономных хардварных ускорителей протоколов.
И с временем реакции не больше 2 мкс.
Сейчас такой стандарт для жесткого риалтайма в ARM Cortex

Автор: Tarbal Nov 12 2017, 02:58

А кто вам сказал, что если используется Линукс, то все надо делать только программно? На любой системе такой подход иррационален. Я как раз и говорю о том, что надо делать систему так, чтобы все железо работало одновременно. В таком случае система становится очень эффективной. Моя цель создать устройство, а не осматривать окружающих сверху вниз с ощущением собственной крутизны. Мастерство это когда на слабой системе удается сделать крутое устройство, а не кайфовать, что супер навороченная система работает достаточно быстро, чтобы можчно было меньше думать при написании программы.

Автор: Den64 Nov 12 2017, 03:35

Что успеет ARM Cortex на 32МГц за 2мкС? Тем более с RTOS.
Всё что нужно выполнять в реальном времени, выполнять нужно в прерываниях. А медленные задачи в процессах. Тем более в RTOS бывают приоритеты процессов.
Главное чтобы RTOS быстро переключала задачи и подолгу не держала процессор с запретом прерываний.

Автор: AlexandrY Nov 12 2017, 08:58

А я так понял, что как раз о своей крутизне вы и хотите поговорить.
Но где доказательства крутизны?
Ok, я приму ее как факт, но покажите мне realtime под линуксом с 2 мкс ответом сделанный вашими руками.
В слабой системе вы сделаете слабый realtime- это закон.


Про то тут и идет речь.
Насколько укоротить прерывания и как практически назначать приоритеты задачам и прерываниям в RTOS с более чем десятком задач, многие из которых вы даже не знаете.
Еще учесть что в Cortex не так много уровней приоритетов прерываний.
Младшие Cortex-ы не рассматриваем. Берем i.MX RT для примера.

Автор: syoma Nov 13 2017, 06:30

В том-то и дело, что в моей системе рациональней весь real-time делать программно, так как в этом случае достаточно одного микроконтроллера с нужным набором периферии, что упрощает дизайн железа. Также в будущем будет легко возможно обновление прошивок с добавлением новых возможностей без модификации железа.
Также для меня я считаю мастерством, если устройство будет сделано быстро и в срок и отвечать нужным требованиям. И при этом будет разработано с использованием наличествующих программистов определенной квалификации, без привлечения крутых системщиков или знатоков RTOS. И если при этом устройство потребует мощного МК - не вижу никаких проблем с этим. Так что мастерство бывает разным.

Автор: Tarbal Nov 14 2017, 01:29

Возьмите Beaglebone там есть PRU. Это сопроцессор для аппликаций реального времени.
Когда я говорю о железе, то подразумевается то, что уже стоит на процессоре. Там ведь куча всяких периферийных устройств внутри. Для звука, видео, графики, интерфейсы разнообразные, таймеры, ШИМ, АЦП и т.д.. Я про это железо говорил.

Автор: AlexandrY Nov 14 2017, 06:25

Странный выбор. Зачем вспоминать это довольно устаревшее решение.
Есть же i.MX 6SoloX с полной поддержкой uC/OS и всеми фичами RT

Автор: mantech Nov 14 2017, 13:35

Не знаю, какие там фичи есть, но раньше в серии imx6 был более-менее рабочий platform sdk, теперь и его куда-то заныкали, везде пишут линукс-онли...

Автор: Tarbal Nov 17 2017, 02:34

А мне нравится. И буду вспоминать. Кстати они разного класса Beaglebone Cortex A8, imx6 Cortex A9.
Мне техасовская документация больше нравится. Пытался как-то осилить как конфигурировать GPIO imx53 - ниасилил. А вот в AM3715 легко пошел.
Вы пробовали читать фрискейловскую мутотень?

Автор: mantech Nov 17 2017, 09:31

GPIO у фриски - это отдельная мутотень, из цикла "найди тут логику", согласен



Решил использовать фриску (МХ6) только потому, что в нем был LVDS и недорогая плата отечественной сборки, бона уж больно кусачая была...

Автор: Harbour Nov 19 2017, 09:03

любое x86 железо не на интел чипсете )

Автор: Harbour Nov 19 2017, 10:23

фото платы - x86 мамка. время реакции на что ? прерывание ? готового ответа системы по ТЗ ?

Тупые interrupt latency/scheduling latency величиной в 2 мкс - это какой-то отстой в наши дни, для x86 Linux уже давно пробита планка в 1мкс для RT apps на стоковом ядре. А Xenomai еще быстрее.
Но вопрос не в том как быстро среагировать на прерывание, получить данные, распарсить, посчитать и отослать в сеть. Вопрос в том как быстро это можно сделать пока не сделали конкуренты. И начем уже не важно. А вариант на uCOS/FreeRTOS будет делаться годами, обрастая Linux'ом все равно, так как голая железяка никому нафиг не нужна.

Сейчас битва идет за наносекунды, но это уже спец железо. Вот фото спец-платы с которой я лично работал:

http://electronix.ru/redirect.php?http://www.colfaxdirect.com/store/pc/viewPrd.asp?idproduct=2865

сток ядро с PREEMPT_RT, сетевуха - 2 канала по 40Gbit, время реакции всей системы от прихода пакета до ответа в сеть (на границе сетевого интерфейса) - ~250 ns. Ядру приложения надо всего один такт на выдачу результата, это 5ns

Какие микросекунды ? Забудьте...

Автор: syoma Nov 19 2017, 12:40

Извините, но на ПЛИС я тоже за микросекунду все сделаю. Вопрос был о процессорах....

Автор: AlexandrY Nov 19 2017, 13:18

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

Автор: Tarbal Nov 19 2017, 16:57

В конечном счете как делать определяет цена. Разработчик должен уметь сделать работоспособную систему на самом дешевом железе. Если комбинация ПЛИС и процессора будет дешевле чем супер быстрый процессор с операционкой реального времени, то так и придется делать.

Автор: AlexandrY Nov 19 2017, 17:21

Ага, а потом копнуть поглубже и в каждой ПЛИС найти RISC ядро с RTOS. И круг замкнулся.
Нельзя RTOS заменить ПЛИС, это должен знать каждый разработчик.

Автор: mantech Nov 19 2017, 17:34

Ни о чем. Ибо такое нужно процентам 2-5 от всей массы разработок, а в большинстве своем нужен контроллер(ПЛК) который просто умеет регулировать, включать и выключать что-то, реагируя на датчики и имеющий какую-либо менюшку для настроуки или ГУЙ...И все!

Автор: Tarbal Nov 21 2017, 01:26

Да что вы наводите тень на плетень? В ПЛИС устройства, которые мы сами пишем. Эти устройства выполняют ту работу, которая критична во времени. Чего вы такой процессороцентричный. Один мой знакомый всю обработку видео 1080х1920 на ПЛИС делал без процессоров,. Такие чудеса делал, что мало не покажется.

Автор: mantech Nov 21 2017, 09:02

Чисто ради интереса, что он там с видео делал, кодеки свои писал на плисе?

Автор: Viktuar Nov 21 2017, 17:44

ИМХО это самый лучший вариант в вашем случае. Минимальная вероятность завязнуть в разработке и отладке програм и провалить сроки.
Минус только в том, что can - достаточно медленный интерфейс, но если это не проблема, то МК + application processor - самое то, просто и надежно.






А почему нет, я и сам так делал. А вообще на ПЛИС хорошо ложатся такие алгоритмы как
интерполяция цветов (debayer), коррекция дефектных пикселей, цветокоррекция, фильтрация,
автояркость/контраст, преобразование цветовых пространств и т.д. Причем для 1080х1920 все
вышеперечисленное влезет в какой-нибудь мелкий ультрмалопотребляющий lattice.

А в dsp, например, тот же debayer займет кучу процессорного времени с его ~100 млн. умножений и 100 млн. сложений на кадр.

Автор: Tarbal Nov 22 2017, 02:53

Я все это видел в 2007 году. Многого не помню. Обработка разнообразная, шумоподавление, автоподстройка контрастности, когда из темных мест вдруг проступают детали. Коррекцию цвета и много чего я уже не помню.
Но он мужик крутой. Стоял у истоков телевидения высокого разрешения.



Именно. Лучше ничего не придумали. Самые крутые видеочипы самых крутых фирм именно так и сделаны.



485 еще медленнее. На самом деле все коммуникационные устройства работают на контроллере прямого доступа к памяти, а процессор блоками пересылает, что зачастую производится переписыванием адреса из одного интерфейса в другой. Всей работы по пересылке пакета данных процессор делает переписывание пары регистров.

Автор: syoma Nov 22 2017, 06:15

Если уж разгуляться и пофантазировать, то я тоже мог бы всю свою программу запустить на ПЛИСе - там, в основном, только автоматы состояний , которые ложатся на логику легко.
Но появляется множество вопросов:
- Есть ли ПЛИСы, стоимостью с 10-баксовый STM32F?
- CAN-корки в ПЛИС дорогие, то есть надо будет ставить отдельный контроллер, так как open-sourcная реализация, насколько я знаю, нерабочая
- Поверх CAN мне надо бы CANopen, а RS485 - Modbus RTU - все мастеры. Тут, похоже ПЛИС отдыхает, либо надо будет SoftCore - процессор и делать все на нем.

ИМХО неинтересно получается.

Автор: AlexandrY Nov 22 2017, 08:56

Грех от разработчиков под ПЛИС требовать понимания сложностей софта.
У них только отфильтровать, трансформировать да переслать.

А вы как-то непоследовательны.
Сначала завели речь о неквалифицированных программистах, а тут рассуждаете, что CANopen могли бы и на автоматах сделать.
Купите уже Micrium OS, и получите там все стеки готовые и с такой документацией что даже заядлые ардуинщики поймут.
По моим прикидкам сделать самостоятельно CANopen даже не на автоматах это на пару месяцев работы для одного программиста.
RTOS с фреймворком обойдется дешевле как ни крути.

Автор: syoma Nov 22 2017, 17:01

Подумаешь,
Single Product:
OS-II / OS-III: $8,000
CAN Framework: $3,100
Can Open: $10,400
И два человеко-месяца и даже Codesys уже не кажутся чем-то дорогими.

Автор: Студент заборстроительного Nov 22 2017, 17:22

Дико плюсую.
Чем покупать чужую глючную РТОСь за 10 тыс. бакинких, в которой ты так НИКОГДА и не разберёшься до конца даже за 3 года, лучше написать свою за 2-3 месяца. Что обойдётся работодателю в 1500 баксов (твоя зарплата за 3 месяца)

Автор: mantech Nov 22 2017, 19:27

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

Автор: AlexandrY Nov 22 2017, 20:50

Это в своей не разберешься уже через 2-3 месяца.
Поскольку для своей вы такую документацию точно писать не будете.
Мануалы и справочники - вот что самое важное в оси.

Автор: Tarbal Nov 23 2017, 00:36

На самом деле того железа что есть на STM32F много на что хватает. Я недавно делал на STM32M7 устройство 16 телефонных аппаратов через USB к Линукс машине. Я вообще без операционки сделал. Взял их софт. Вообще на Кубе сгенерировал исходный проект, но это рисковано. Те проблемы, что у меня были я находил в их коде и исправлял, но это один или два раза было. На Coocox разрабатывал и отлаживал. Одна проблема была в железе -- SPI младший бит искажал. Через год это в errata появилось. Но я сделал программный SPI. Все заработало -- заказчик доволен. В форуме ARM остались вехи с моими вопросами.

Главное не пожалеть времени и подумать как сделать. Как-то надо было увеличить частоту измерения входного сигнала, который шел с радиоприемника. Устройство было на 8051 и за период передачи бита (1 миллисекунда) удавалось измерить и обработать не более 10 раз. Я хорошо подумал и нашел как измерять 100 раз за каждый из этих 10. Это помогло повысить помехоустойчивость цифрового приемника.
Однажды не было нужного переключателя (в СССР у меня такое бывало нередко) -- придумал как обойтись -- сделал автоматическое переключение. Мало того получилось еще и технологичнее -- не нужно было настраивать диапазоны, чтобы соответствовали.

Вы для начала опишите как вы планируете сделать прибор. Потом разберите каждый блок. Дорогу осилит идущий. На начальном этапе любого проекта зачастую бывает ощущение, что задача непосильна и слишком много непонятного. Сделали часть блоков и хаоса значительно меньше будет.
Я не видел, чтобы какой-нибудь проект с первого прототипа железа заработал, потому, что всего вы заранее не предусмотрите, но когда начнете, то у вас будет понимание где у вас узко и что надо делать иначе. Не думайте съэкономить на разработке железа Или начните c evaluation board.

Пока не начнете пробовать вопросы останутся, но все не так критично как кажется на начальном этапе.

Автор: Студент заборстроительного Nov 23 2017, 03:47

Не так

Автор: mantech Nov 23 2017, 07:28

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

Автор: AlexandrY Nov 23 2017, 09:21

В RTOS которые я применяю под 80 мегабайт документации. Десятки тысяч! страниц.
Ну я посмотрю каким вы станете попробовав все это запомнить.

Автор: Студент заборстроительного Nov 23 2017, 16:13

Вот поэтому и НЕТ СМЫСЛА юсать абы кем написанное УГ и глюкалово,в котором разобраться даже полжизни не хватит даже если только ртосью и будешь заниматься целыми днями.
Быстрей и проще на 2-3 месяца написать на порядки лучшую свою РТОСь

А то это уже стало классикой. Народ юсает кем-то написанные проприентарные оси, а потом воет на форумах ГОДАМИ: помогите разобраться! Никак не могу понять как это работает
Хотя сейчас даже любой подросток за 1-2 месяца вполне можно свою РТОСь написать. На порядки лучшую

Автор: mantech Nov 23 2017, 17:21

Даже если это и так, в чем я сомневаюсь, когда вы все это будете читать, и за какое время? В это время уже 2 небольших оси уже можно будет написать и отладить
ЗЫ в свое время, когда писал под винду было всего 2 книги по 300 стр. в каждой... И как-то хватало

Автор: AlexandrY Nov 23 2017, 20:07

Меня доморощенные наборы функций переключателей контекста называемые тут иногда RTOS-ами уже давно не интересуют.
RTOS - это набор софта весом не меньше 10 мег, где переключатель контеста составляет 0.001% его объема.
А 80 метров мануалов естественно я не читаю, это справочники. Кто ж их целиком читает?
Просто их наличие дает мне уверенность в сроках разработки на любую тему.

Да, чтобы начать программить под DOS-ом хватало и пары страниц. Тож операционка считалась.

Автор: Студент заборстроительного Nov 23 2017, 20:49

Вам шашечки или ехать?


Когда мауалов 80 мегов то вероятность, что там ошибки почти 100%
И вероятность что Вы при чтении такго гигантского объёма инфы упустите какой-то важный нюанс равна 100%


Когда в РТОС "не меньше 10 Мегов" вероятность что там ошибки равна 100%

Как по мне - ртос - это только ядро. И оно не может быть больше 1 килобайта (или 1000 строк кода). Так как ядро должно быть ОБОЗРИМО одним программистом. Т.е. понимание работы ядра должно умещаться в одной голове
А весь софт, который Вы тоже относите к РТОС, это просто софт.

А то так и Paint и Word можно отнести к операционной системе (что и делают малоопытные пользователи Windows считая все приложения и вспомогательные сервисы частью ОС)

Автор: DASM Nov 23 2017, 21:19

Кому то лавры bolgen os не дают покоя..

Автор: AlexandrY Nov 23 2017, 21:27

Я точно такими словами писал здесь лет 10 назад.
Нет, те времена прошли. Больше нет обозримого софта имеющего хоть какую-то ценность.
Теперь только технологические платформы.

Автор: haker_fox Nov 24 2017, 00:38

Прям-таки и любой?


А я с вами согласен! Просто ОС (в смысле переключатель контекста) конечно хороша, но когда доходит до написания реального приложения, понимаешь, что нет адекватных драйверов (SPI, UART, DMA - вроде банальные вещи, но попробуй написать качественный скоростной драйвер), и на их написание необходимо затратить время. А время стоит денег. И опыт - тоже. Поэтому наличие операционной системы с драйверами, стеками протоколов, средствами отладки и т.п. (вы, если не ошибаюсь, называете это фреймворком) очень даже приветствуется! Времена, когда для AVR мне хватало простой переключалки, а драйвера писались как-бы между делом - для меня тоже прошли. Сейчас нужен более серьёзный софт, портируемый на разные платформы, и содержащий всё, кроме ядра целевого приложения. Другими словами, мне хочется заниматься созданием именно приложения, которое реализует железяка, а не думать, а как бы написать очередной драйвер UART, который и RS-485 может, и MODBUS поддерживает. Да чтобы работало надёжно...

Автор: Tarbal Nov 24 2017, 00:42

Плюс драйверы на всякую периферию, TCP/IP, файловые системы и т.д.. Такого на коленке на сделаешь за неделю.



VxWorks наверное. Там одно натягивание на Posix чего стоило.

Автор: Студент заборстроительного Nov 24 2017, 04:06

"Технологические платформы". Красиво звучит.
Только вот в mission critical системах ты отвечаешь за каждый БИТ прошивки.
И если произойдёт катастрофа - нельзя будет всё свалить на криво написанные доки или что объём инфы был слишком большой поэтому ты что-то "забыл".
Или что это баг/глюк в стороннем компиляторе.
Отвечать все равно тебе придется.


Да ради Бога. Если Вы пишите софт управления кофемолкой или DVD-проигрывателем - то почему бы не использовать что-то готовое. И если даже что-то заглючит/зависнет катастрофы от того, что кофемолка не смолола во время кофе не произойдет.

А если пишешь что-то серьезное - приходится проверять каждый бит прошивки

Автор: haker_fox Nov 24 2017, 08:55

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

На этом форуме вы один такой. Только вы делаете "сурьёзные" вещи, где надо отвечать за каждый бит. Остальные - так, поделки ваяют на готовых осях.



Крышку зашитого проца спилить и под микроскопом? Или как-то по-другому? Вас уже просили показать ваш чудо-софт, умеющий детектировать ошибки. Правда, тогда вас звали по-другому. Но псевдонимов много, а стиль писателя остаётся неизменным: высокая надёжность, основанная на битах.

Автор: Студент заборстроительного Nov 24 2017, 16:14

Именно так. Один. Отвечает за проект в целом.
Потому что "у семи нянек дитя без глаза"©

Автор: Harbour Nov 25 2017, 19:27

Так причем тут ПЛИС ? Изначально вопрос стоял - а можно ли сделать все на Linux. Ответ - да. Так получилось что сейчас 1GHz ARM стоит < $1. В 90-ых может и был короткий период, когда MCU имели смысл - но сейчас 20xx. Плата NanoPi Neo стоит (в розницу !) $5, 4 ядра 1.2Ghz, 512Mb RAM, ethernet, etc. Железо, которым бьют себя пяткой в грудь адепты ucos больше не играет никакой роли. И дальше будет еще для них хуже. Каличные доморощенные псевдо-оси, дефективные windoze-based компиляторы (Keil привет) и их натужные бородатые писатели тупо идут лесом, так как они не только не в состоянии обеспечить конкурентно-способный цикл разработки, но и даже более или менее стабильный продукт из-за хронической деревенской безграмотности, т.е. грубо говоря - ничего кроме своей оси и ее устаревших технологий (на устаревшем же и железе) они асилилить не смогли, а время и задачи на месте как-бэ не стоят. Приходит на ум только одна пословица - "она наморщила свой узкий лобок". Про обычные ситуевины, когда, к примеру, на следующем этапе стоит задача поднять производительность в 10 раз (или, скажем в 100) речь вообще не идет, так как вдруг оказывается что a) "ннуу ... это же все переделывать надо"; "это будет очень дорого и долго"; c) "это невозможно". Поэтому рынок этих грустных и бесполезных товарищей выкидывает в мусорку, меняя на других. Можно отметить их ключевые признаки: категорическое отрицание всего, что не попадает под узкий луч приобретенного ими опыта, полное неумение учиться новому, скудоумие, отсутствие взгляда на перспективу, острая и никому нахер не нужная заточка под одну задачу (например вымершую ось), бесполезная трата бабла на их разработки, дикие сроки - и в конце, как следствие - жопа по жизни. Также обычно такие товарищи любят тусоваться на форумах, периодически доказывая свою крутизну печатая разные слова

Мое резюме простое: учите Linux и возможно будет вам счастье. Правда не всем, и не в этой жизни )

Автор: Tarbal Nov 26 2017, 05:44

Я работал под многими RTOS:
VxWorks, Integrity, Nucleus, uCOS, разными самопальными. Знаете в чем преимущество Линукса? Все что изучил идет в зачет в другом месте работы и опыт можно накапливать. С другими осями такого не получалось. Да и ширина покрытия устройств другим осям не снилось. Делать систему в рассчете на программный реалтайм как-то однобоко. Надо заставить все железо работать одновременно -- тогда на хилом процессоре можно получить неплохие результаты.
То что VxWorks натянули на Posix, в Линуксе дается естественным образом.

Автор: AlexandrY Nov 26 2017, 11:06

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

Автор: syoma Nov 26 2017, 20:10

У меня тоже такой же вопрос. Пока мы тут тихо мирно беседовали, я уже за тройку выходных запустил и шедулер вытесняющий с задачами на 2, 50 и 200 мс, и CANopen там же, все с жестким реалтаймом, а вот примеров, как такое же сделать на Линуксе и однодолларовом гигагерцовом Арме пока не увидел. А я, честно, хотел бы увидеть.

Автор: Tarbal Nov 27 2017, 02:33

То что вы делаете меня удивляет. Вот так выглядела фраза, которую вы творчески и с огоньком процитировали:
"Да и ширина покрытия устройств другим осям не снилась."
При этом мне совершенно безразлично ваше восприятие того, что я пишу. Просто хочу дать информацию тем, кто еще не имеет достаточно опыта, что существует и другой подход, который тоже неплохо представлен.
Расскажите мне какую скорость дает жесткий реал-тайм без DMA для Ethernet порта? Линуксу 1 гигабит в секунду это по силам, а как вы можете это сделать на жестком реал-тайме? DMA понадобился? Так нафиг на груди рубаху рвать. Линукс тоже так умеет и жесткий реалтайм для этого вовсе необязателен.
http://electronix.ru/redirect.php?https://www.networkworld.com/article/2333564/software/10-gigabit-ethernet-comes-to-linux-servers.html



Я вас поздравляю с успехом. Тем кому лень изучить как пользоваться DMA без жесткого реалтайма не обойтись.
CAN я в 2003 году делал на RTOS Salvo ( http://electronix.ru/redirect.php?http://www.pumpkininc.com/ ). Драйверы сам писал на PIC18 для системы управления лифтом. Кстати, чтобы два раза не вставать, привет студенту, пекущемуся о повышеных требованиях к безопасности. Там было три процессора и на одном не было встроенного CAN железа. Надо было еще и SPI драйвер писать. У меня со скоростью в принципе не возникало проблем.
Напишите на жестком реал-тайме Ethernet драйвер на жалкие 100 мегабит в секунду, которые поддержаны в самом захудалом линуксе. Да еще так, чтобы процессор не был сильно загружен. В Линуксе процессор еще и другими делами занимается.
Отчего-то суперкомпьютеры используют Линукс:
http://electronix.ru/redirect.php?https://en.wikipedia.org/wiki/Supercomputer_operating_systems
http://electronix.ru/redirect.php?https://itsfoss.com/linux-supercomputers-2017/
Чего это они? Может вы чего-то важного не знаете?

Автор: Студент заборстроительного Nov 27 2017, 03:55

Скоро светодиодом будут мигать системой с 16-ти ядерным процом на борту и 16 Гигами ОЗУ, установленной операционкой весом гигов 10.
Все к этому идет

А по поводу линукс. Нет такой системы. Точнее раньше была. И написана была лиуксом Торвальдсом. А сейчас есть целый зоопарк (их уже наверное уже больше тысячи версий) непонятно кем (поэтому за их код никто не отвечает), непонятно когда написанных операционок имеющих общее собирательное название "линукс"

Хотя между этими "лиунсками" разница порой больше, чем между жигули и экскаватором

Автор: Tarbal Nov 27 2017, 04:16

Ваш подход давно понятен. Новое изучать вы принципиально отказываетесь. Даже RTOS вам не удалось осилить.

Автор: AlexandrY Nov 27 2017, 06:34

Уже переход на личности?
Но студент пока сказал нечто более умное чем вы.
Посмотрите из чего состоит 10Gb карта- http://electronix.ru/redirect.php?https://www.cs.rice.edu/CS/Architecture/docs/willmann-hpca05.pdf
Там стоит куча CPU с огромной памятью команд на фоне ваших PIC-ов
Я почти уверен что там трудится RTOS и не одна.
RTOS-ы теперь в каждой флешке, в каждом диске, в каждом модуле.
На какой-то убогий "линукс" приходится десяток RTOS в окружающей его обвязке.
А в этой теме вопрос и стоит о специализированной обвязке.

Автор: syoma Nov 27 2017, 10:30

Блин, где Вы такие http://electronix.ru/redirect.php?http://ieeexplore.ieee.org/document/1385932/ берете? Это ж ёхтель - 2005 год. Сейчас никто на процессорах такое не делает, а ставят ПЛИСину и она вам хоть 100 Гбит с TCP оффлоадингом делает. Вот вам типовые сетевые карточки для датаценров сегодня - http://electronix.ru/redirect.php?https://www.alpha-data.com/dcp/

Автор: AlexandrY Nov 27 2017, 11:02

Копните глубже и все равно увидите RISC-и

Автор: syoma Nov 27 2017, 11:06

Нет там никаких RISCов. И вообще никаких процессоров нет. Максимум - дохлый Zync, как борд менеджмент контроллер. Вся обработка трафика - специализированными IP ядрами с прямыми интерфейсами между ними. Взгляните на референсные дизайны, как это на ПЛИСах делается.

Автор: AlexandrY Nov 27 2017, 12:09

Ну так я и взглянул.
Первая же ссылка в разделе 3rd party IP and Software Support ведет на многоядерные MIPS-ы поддерживающие стек TCP/UDP
Еще не забудьте что такие платы должны управлять сетевым менеджментом на MAC уровне.
А DSP ядра, которых там тыщи, они по вашему код из воздуха берут?
Да ни за что вы меня не убедите что линукс способен делать даже 1 Gb без костылей со всех сторон в виде вспомогательных RISC-ов.

Автор: syoma Nov 27 2017, 13:47

Если вы об этой http://electronix.ru/redirect.php?http://www.intilop.com/index.php, то может ткнете носом, где там многоядерные MIPSы? Обыкновенная логика.

Автор: mantech Nov 27 2017, 13:49

Кстати, а кто-нить подумал, что в случае линукса нужно предоставлять исходники? Хотите делиться со всеми, вашими творениями? И ворое, если слетает ФС и прочее, кто будет все восстанавливать? Клиент тоже должен обучиться всем премудростям?

Автор: one_eight_seven Nov 27 2017, 13:53

Не нужно, если ваше ПО будет взаимодействовать с ОС через GPL-прослойку. Что делают, например, AMD и NVIDIA, а также, если это не модуль ядра, а просто ПО, то и без GPL прослойки: Cadence, Mentor Graphics, Mathworks, Synopsys, и другие.


А если это случится в RTOS, то чем ситуация будет отличаться?

Я не фанат использования линупсов где надо и где не надо, но эти доводы мимо.

Автор: mantech Nov 27 2017, 14:09

Дело в том, что ртос бареметал и пр. как правило прошиты внутрь проца и обновляются бутлодырем, а так да, ничем особым не отличаются



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

Автор: AlexandrY Nov 27 2017, 14:09

Не, эт вы мне тыкнете носом кто сделал TCP стек на логике, где мы бы могли проверить, что там действительно только одна логика без программного кода и процессорного ядра.

Автор: syoma Nov 27 2017, 14:23

Ну я не знаю, как вам доказать. Вот естьhttp://electronix.ru/redirect.php?http://www.intilop.com/resources/product_briefs/25G_1K-Sess_TCP+UDP_Offload+MAC+Host_IFUltra-LowLatency(INT-25011).pdf Написано, что все сделано в hardware. Да и какой там процессор, если гарантируется задержка не более 100ns? Это только в железе, только хардкор. Сами в другом проекте на ПЛИС отрабатываем аналогичные вещи в реальном времени, только не TCP/IP, а IEC61850 Goose + SV + EtherCAT полностью в ПЛИСе без каких либо процессорных ядер, поэтому я склонен им верить. Но это другая тема.

Автор: AlexandrY Nov 27 2017, 14:31

Прочитали бы некро-статью и поняли как это делается.
Доказать то конечно не докажете. Это же закрытая технология. Вам там никто ничего расписывать не будет.
У тех ребят особый слэнг, они hardware называт все что закрыто в их дизайне.
Тогда создается ложное впечатление, что у них нет кода и следовательно нечего хакать.

Автор: RobFPGA Nov 27 2017, 14:40

Приветствую!

Вот Вам http://electronix.ru/redirect.php?https://github.com/Xilinx/HLx_Examples/tree/master/Acceleration/tcp_ip место для тык... взрыва стереотипов - чисто логика - никакого софт-процессора гы-гы-гы.

Успехов! Rob.

Автор: Студент заборстроительного Nov 27 2017, 18:03

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

Автор: Tarbal Nov 28 2017, 02:03

Еще какой дерьмовенький. Если его програмно исполнять, то точно хуже чем CAN. CAN хоть работать будет. Но недостаток обоих безусловно в том, что их придется изучать.

Ну ладно. Не осилили Ethernet. Сделайте такой реал-тайм. Видео камерy 720p надо обжать в h264 и отправить по RTP другому реал-тайм компьютеру, который и отобразит это на дисплее.
Видео самый что ни на есть реалтайм. Даже простой PAL 25 раз в секунду кадры меняются, а строки каждые 64 микросекунды. Пиксели с частотой 13.5 мегагерца. Осилит ваша крутая ось? Или без специализированного железа не обойдетесь?
Такую задачу на Линуксе я минут за 20 исполню. На малине делал.



Ну и что? Разве кто-то спорит, что используется специальное железо? Я как раз именно за такой подход к реал-тайму. Мне как разработчику системы филолетово как оно сделано. Я сам не собираюсь это разрабатывать. Моя задача сделать такую систему, чтобы она использовала все достоинства этого специального железа. А если и придется, то на ПЛИСке сделаю.

Автор: Студент заборстроительного Nov 28 2017, 04:01

Может все же на процессоре и на на линупсе?

Автор: AlexandrY Nov 28 2017, 06:12

Вы тут немного поторопились. Это не TCP/IP, а его недоделанные куски.
Да и дизайн на RTL основан.
Эт все равно что программу зашить в ПЗУ и кричать, что все сделанно на логике.


Это не ралтайм.
Видео может к клиенту придти с секундной задержкой и никто не заметит, могут выпадать кадры и т.д.
И такие референсные аппликации у TI идут исключительно под управлением RTOS DSP/BIOS.
В разы надежней работают чем под линукс.

А линукс вам скорее всего был нужен потому что либо:
а) вы не имели документации на железо ,
б) не осилили запуск RTP из lwIP либо еще что-то из промежуточного софта.

Автор: mantech Nov 28 2017, 08:30

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

А за 20 минут... При условии, что взяли 90% референса, который уже кто-то делал до вас - тогда поверю, а вот попробуйте туда "подсунуть" какую-нить доп. информацию в кадр?
И кстати да, видео не реалтайм, а стриминг, разница есть...

Автор: RobFPGA Nov 28 2017, 13:28

Приветствую!

Но при этом они даже работают - ARP адрес определяет, connect устанавливает, данные передает, ретрейны, таймауты, че еще надо?


RTL транслируется в HDL, который затем мапится в логические примитивы, (информация о которых затем зашивается в ПЗУ - облом ).
Но процессора все же нет - кто ж тогда трудится?


Вон с Марса или Розетты видео транслировали с задержкой десяток мин - и считают что это реалтиме.

Читая эту трансляцию чемпионата по длине и диаметру задаюсь вопросом о критерии "реалтайм".
Каков у каждого участника ЭТОТ (не подумаете плохого ) критерий по которому можно однозначно сказать что это rel-time ?

Удачи! Rob.

Автор: AlexandrY Nov 28 2017, 13:57

Ну так и процессор транслируется в HDL. Понимаете мысль?

А риалтайм это не о времени, а о технологии - расстановки приоритетов, декомпозиция на задачи, прогнозирование реакции на поток асинхронных событий, критерии планируемости и т.д. и т.п.
По быстродействию тоже не определились.
Я считаю, что i.MX RT уделает линукс на малине любой версии по количеству обработанных прерываний за единицу времени.
Так что мерится тут и мерится. Присоединяетесь.

Автор: RobFPGA Nov 28 2017, 14:32

Приветствую!

Ага - но процессор это же наброр регистров и логики ...


Это не реалтиме - это просто грамотный инженерный подход к проектированию системы IMHO.


Нее - я пытаюсь имеющемся у наличии инструментом парвильно распоряжатся - доставля удовольствие и себе и партнер...
Да и сейчас у меня другая весовая категория - успел за 100 нс - и ты REALtime не успел - полезай в буфер лузер и дергай за я.. прерывание reltime-щика выше Это лет 5-7 назад меня за прерывания дергали в основном в DSP.

Поэтому современный критерий reltime все ж интересно узнать.

Удачи! Rob.

Автор: AlexandrY Nov 28 2017, 15:00

Не, у вас значит не "REALtime", а просто DSP, только доступ к DSP теперь замаскирован от вас уровнем RTL.

К примеру задачей типовой риалтайм embedded системы является обслуживание 10 и более типов периферии включая интерфейсы UART, I2C, SPI, sBUS, USB, Wi-Fi, SDIO
Поверх этих интерфейсов система обеспечивает работу протоколов высокого уровня как: HTTP, MQTT, профили дивайсов USB, файловые системы, отладочные логи...
И все это должно работать когда прикладная задача позиционирует дивайс в пространстве с точностью 0.05 град c помощью кучки не самых точных электроприводов.
Умный робот-пылесос назовем это условно.

Автор: mantech Nov 28 2017, 17:06

И с какой скоростью должен реагировать этот робот? Скажем так, 50 раз в сек. частота принятия решений вполне устроит, ибо он у вас не со сверхзвуковой скоростью ездит. Следовательно реалтайм тут на уровне среднего ПЛК получается.



Зачем неточным приводам получать координаты 0.05град? Если они все равно не смогут так спозиционироваться?

Автор: AlexandrY Nov 28 2017, 17:38

На каждом движке 3-и петли обратной связи: 100, 1000, 10000 Гц. В каждой принимается какое-то решение.

Автор: syoma Nov 28 2017, 18:09

Причем я сомневаюсь, что он с этой же скоростью должен реагировать на команды по Wi-fi или отдавать туда информацию. А также на USB, если там, конечно, не камера подключена, по которой он должен ориентироваться.

Автор: RobFPGA Nov 28 2017, 19:24

Приветствую!

Продолжаем нашу трансляцию ...

Вы привели пример ЗАДАЧ и набор ИНТЕРФЕЙСОВ типичной простенькой эмбедед системы но не привели КРИТЕРИЙ по которой можно четко сказать что эта ситема relatime.
В моем буке под виндой наверно и поболее интерфейсов и протоколов будет и все рабоатет в реальном времени (намек - как мне кажется).

Удачи! Rob.

Автор: syoma Nov 28 2017, 19:32

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