Так причем тут ПЛИС ? Изначально вопрос стоял - а можно ли сделать все на 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 и возможно будет вам счастье. Правда не всем, и не в этой жизни )

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

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

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

То что вы делаете меня удивляет. Вот так выглядела фраза, которую вы творчески и с огоньком процитировали:
"Да и ширина покрытия устройств другим осям не снилась."
При этом мне совершенно безразлично ваше восприятие того, что я пишу. Просто хочу дать информацию тем, кто еще не имеет достаточно опыта, что существует и другой подход, который тоже неплохо представлен.
Расскажите мне какую скорость дает жесткий реал-тайм без DMA для Ethernet порта? Линуксу 1 гигабит в секунду это по силам, а как вы можете это сделать на жестком реал-тайме? DMA понадобился? Так нафиг на груди рубаху рвать. Линукс тоже так умеет и жесткий реалтайм для этого вовсе необязателен.
https://www.networkworld.com/article/233356...ux-servers.html



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

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

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

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

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

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

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

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

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

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

Если вы об этой ссылке, то может ткнете носом, где там многоядерные MIPSы? Обыкновенная логика.

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

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


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

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

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



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

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

Ну я не знаю, как вам доказать. Вот есть даташит Написано, что все сделано в hardware. Да и какой там процессор, если гарантируется задержка не более 100ns? Это только в железе, только хардкор. Сами в другом проекте на ПЛИС отрабатываем аналогичные вещи в реальном времени, только не TCP/IP, а IEC61850 Goose + SV + EtherCAT полностью в ПЛИСе без каких либо процессорных ядер, поэтому я склонен им верить. Но это другая тема.

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

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


Вот Вам TCP/IP_offload место для тык... взрыва стереотипов - чисто логика - никакого софт-процессора гы-гы-гы.

Успехов! Rob.

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

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

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



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

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

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


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

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

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

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

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


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


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


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

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

Удачи! Rob.

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

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

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


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


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


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

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

Удачи! Rob.

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

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

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



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

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

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

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


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

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

Удачи! Rob.

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