Сейчас битва идет за наносекунды, но это уже спец железо. Вот фото спец-платы с которой я лично работал:
http://www.colfaxdirect.com/store/pc/viewP...?idproduct=2865
сток ядро с PREEMPT_RT, сетевуха - 2 канала по 40Gbit, время реакции всей системы от прихода пакета до ответа в сеть (на границе сетевого интерфейса) - ~250 ns. Ядру приложения надо всего один такт на выдачу результата, это 5ns
Какие микросекунды ? Забудьте...

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

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

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

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

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

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

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

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

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

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

Купите уже Micrium OS, и получите там все стеки готовые и с такой документацией что даже заядлые ардуинщики поймут.

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

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