Зачем изобретать, то что придумано более 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 работает везде и писать под него умеют теперь даже обезьяны, которые случайно засматривались в окна индусских программистов.

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

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

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

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

Да ладно вам.
Вот эта штука принимает и транскодирует (и много чего другого) 32 канала видео одновременно и сделана на Линуксе:
https://www.cisco.com/c/en/us/products/coll...c78-736419.html

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



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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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



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

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

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

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

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

http://www.colfaxdirect.com/store/pc/viewP...?idproduct=2865

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

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

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

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

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

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

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

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

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

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






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

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

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



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



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

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

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

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

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

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

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

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

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

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

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

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

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

Не так

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

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

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

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

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

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

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

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


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


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

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

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

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

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

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


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

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



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

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


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

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

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

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



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

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