[syoma 1]

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

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

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

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

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

[AlexandrY 2]

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

Но вопрос не в том как быстро среагировать на прерывание, получить данные, распарсить, посчитать и отослать в сеть. Вопрос в том как быстро это можно сделать пока не сделали конкуренты. И начем уже не важно. А вариант на uCOS/FreeRTOS будет делаться годами, обрастая Linux'ом все равно, так как голая железяка никому нафиг не нужна.

Боюсь вы не в курсе дела.

Для таких плат вы не то что схемы не имеете, а даже структуры ядра не знаете.

Поэтому ваши догадки о скорости обработки прерываний я серьезно принимать не могу.

[Tarbal 4]

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

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

 

[AlexandrY 2]

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

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

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

[mantech 34]

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

 

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

 

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

 

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

 

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

[Tarbal 4]

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

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

 

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

[mantech 34]

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

 

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

[Viktuar 0]

Привет. Собственно вопрос из области начинающих по архитектуре процессорной системы. Делаем новый проект и возник вопрос.

С одной стороны есть программа, работающая в жестком реальном времени с коммуникацией, через CAN, SPI и RS485. Это основная функция системы.

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

...

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

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

 

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

 

ИМХО это самый лучший вариант в вашем случае. Минимальная вероятность завязнуть в разработке и отладке програм и провалить сроки.

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

 

 

 

 

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

 

А почему нет, я и сам так делал. А вообще на ПЛИС хорошо ложатся такие алгоритмы как

интерполяция цветов (debayer), коррекция дефектных пикселей, цветокоррекция, фильтрация,

автояркость/контраст, преобразование цветовых пространств и т.д. Причем для 1080х1920 все

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

 

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

[Tarbal 4]

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

 

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

Но он мужик крутой. Стоял у истоков телевидения высокого разрешения.

 

А почему нет, я и сам так делал. А вообще на ПЛИС хорошо ложатся такие алгоритмы как

интерполяция цветов (debayer), коррекция дефектных пикселей, цветокоррекция, фильтрация,

автояркость/контраст, преобразование цветовых пространств и т.д. Причем для 1080х1920 все

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

 

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

 

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

 

ИМХО это самый лучший вариант в вашем случае. Минимальная вероятность завязнуть в разработке и отладке програм и провалить сроки.

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

 

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

[syoma 1]

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

Но появляется множество вопросов:

- Есть ли ПЛИСы, стоимостью с 10-баксовый STM32F?

- CAN-корки в ПЛИС дорогие, то есть надо будет ставить отдельный контроллер, так как open-sourcная реализация, насколько я знаю, нерабочая

- Поверх CAN мне надо бы CANopen, а RS485 - Modbus RTU - все мастеры. Тут, похоже ПЛИС отдыхает, либо надо будет SoftCore - процессор и делать все на нем.

 

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

 

 

[AlexandrY 2]

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

Но появляется множество вопросов:

- Есть ли ПЛИСы, стоимостью с 10-баксовый STM32F?

- CAN-корки в ПЛИС дорогие, то есть надо будет ставить отдельный контроллер, так как open-sourcная реализация, насколько я знаю, нерабочая

- Поверх CAN мне надо бы CANopen, а RS485 - Modbus RTU - все мастеры. Тут, похоже ПЛИС отдыхает, либо надо будет SoftCore - процессор и делать все на нем.

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

У них только отфильтровать, трансформировать да переслать.

 

А вы как-то непоследовательны.

Сначала завели речь о неквалифицированных программистах, а тут рассуждаете, что CANopen могли бы и на автоматах сделать.

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

По моим прикидкам сделать самостоятельно CANopen даже не на автоматах это на пару месяцев работы для одного программиста.

RTOS с фреймворком обойдется дешевле как ни крути.

 

 

 

[syoma 1]

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

Подумаешь,

Single Product:

OS-II / OS-III: $8,000

CAN Framework: $3,100

Can Open: $10,400

И два человеко-месяца и даже Codesys уже не кажутся чем-то дорогими.

[Студент заборстроительного 0]

Дико плюсую.

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

[mantech 34]

Подумаешь,

Single Product:

OS-II / OS-III: $8,000

CAN Framework: $3,100

Can Open: $10,400

И два человеко-месяца и даже Codesys уже не кажутся чем-то дорогими.

 

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

[AlexandrY 2]

Дико плюсую.

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

Это в своей не разберешься уже через 2-3 месяца.

Поскольку для своей вы такую документацию точно писать не будете.

Мануалы и справочники - вот что самое важное в оси.