реклама на сайте
подробности

 
 
9 страниц V  « < 7 8 9  
Reply to this topicStart new topic
> Real-time и не-real-time - в одном флаконе или раздельно?
syoma
сообщение Nov 19 2017, 12:40
Сообщение #121


Профессионал
*****

Группа: Свой
Сообщений: 1 643
Регистрация: 14-02-07
Из: наших, которые работают за бугром
Пользователь №: 25 368



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

Извините, но на ПЛИС я тоже за микросекунду все сделаю. Вопрос был о процессорах....
Go to the top of the page
 
+Quote Post
AlexandrY
сообщение Nov 19 2017, 13:18
Сообщение #122


Mentor
******

Группа: Модераторы
Сообщений: 5 457
Регистрация: 19-01-05
Пользователь №: 2 050



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

Боюсь вы не в курсе дела.
Для таких плат вы не то что схемы не имеете, а даже структуры ядра не знаете.
Поэтому ваши догадки о скорости обработки прерываний я серьезно принимать не могу.
Go to the top of the page
 
+Quote Post
Tarbal
сообщение Nov 19 2017, 16:57
Сообщение #123


Профессионал
*****

Группа: Свой
Сообщений: 1 292
Регистрация: 21-05-10
Пользователь №: 57 439



Цитата(syoma @ Nov 19 2017, 16:40) *
Извините, но на ПЛИС я тоже за микросекунду все сделаю. Вопрос был о процессорах....

В конечном счете как делать определяет цена. Разработчик должен уметь сделать работоспособную систему на самом дешевом железе. Если комбинация ПЛИС и процессора будет дешевле чем супер быстрый процессор с операционкой реального времени, то так и придется делать.
Go to the top of the page
 
+Quote Post
AlexandrY
сообщение Nov 19 2017, 17:21
Сообщение #124


Mentor
******

Группа: Модераторы
Сообщений: 5 457
Регистрация: 19-01-05
Пользователь №: 2 050



Цитата(Tarbal @ Nov 19 2017, 18:57) *
В конечном счете как делать определяет цена. Разработчик должен уметь сделать работоспособную систему на самом дешевом железе. Если комбинация ПЛИС и процессора будет дешевле чем супер быстрый процессор с операционкой реального времени, то так и придется делать.

Ага, а потом копнуть поглубже и в каждой ПЛИС найти RISC ядро с RTOS. И круг замкнулся. biggrin.gif
Нельзя RTOS заменить ПЛИС, это должен знать каждый разработчик.
Go to the top of the page
 
+Quote Post
mantech
сообщение Nov 19 2017, 17:34
Сообщение #125


Профессионал
*****

Группа: Участник
Сообщений: 1 697
Регистрация: 16-08-12
Из: Киров
Пользователь №: 73 143



Цитата(Harbour @ Nov 19 2017, 13:23) *
Сейчас битва идет за наносекунды, но это уже спец железо. Вот фото спец-платы с которой я лично работал:

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

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

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


Ни о чем. Ибо такое нужно процентам 2-5 от всей массы разработок, а в большинстве своем нужен контроллер(ПЛК) который просто умеет регулировать, включать и выключать что-то, реагируя на датчики и имеющий какую-либо менюшку для настроуки или ГУЙ...И все!
Go to the top of the page
 
+Quote Post
Tarbal
сообщение Вчера, 01:26
Сообщение #126


Профессионал
*****

Группа: Свой
Сообщений: 1 292
Регистрация: 21-05-10
Пользователь №: 57 439



Цитата(AlexandrY @ Nov 19 2017, 21:21) *
Ага, а потом копнуть поглубже и в каждой ПЛИС найти RISC ядро с RTOS. И круг замкнулся. biggrin.gif
Нельзя RTOS заменить ПЛИС, это должен знать каждый разработчик.


Да что вы наводите тень на плетень? В ПЛИС устройства, которые мы сами пишем. Эти устройства выполняют ту работу, которая критична во времени. Чего вы такой процессороцентричный. Один мой знакомый всю обработку видео 1080х1920 на ПЛИС делал без процессоров,. Такие чудеса делал, что мало не покажется.
Go to the top of the page
 
+Quote Post
mantech
сообщение Вчера, 09:02
Сообщение #127


Профессионал
*****

Группа: Участник
Сообщений: 1 697
Регистрация: 16-08-12
Из: Киров
Пользователь №: 73 143



Цитата(Tarbal @ Nov 21 2017, 04:26) *
Один мой знакомый всю обработку видео 1080х1920 на ПЛИС делал без процессоров,. Такие чудеса делал, что мало не покажется.


Чисто ради интереса, что он там с видео делал, кодеки свои писал на плисе?
Go to the top of the page
 
+Quote Post
Viktuar
сообщение Вчера, 17:44
Сообщение #128





Группа: Новичок
Сообщений: 3
Регистрация: 18-12-16
Пользователь №: 94 676



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

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


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




Цитата(mantech @ Nov 21 2017, 09:02) *
Чисто ради интереса, что он там с видео делал, кодеки свои писал на плисе?


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

А в dsp, например, тот же debayer займет кучу процессорного времени с его ~100 млн. умножений и 100 млн. сложений на кадр.
Go to the top of the page
 
+Quote Post
Tarbal
сообщение Сегодня, 02:53
Сообщение #129


Профессионал
*****

Группа: Свой
Сообщений: 1 292
Регистрация: 21-05-10
Пользователь №: 57 439



Цитата(mantech @ Nov 21 2017, 13:02) *
Чисто ради интереса, что он там с видео делал, кодеки свои писал на плисе?


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

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

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


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

Цитата(Viktuar @ Nov 21 2017, 20:44) *
ИМХО это самый лучший вариант в вашем случае. Минимальная вероятность завязнуть в разработке и отладке програм и провалить сроки.
Минус только в том, что can - достаточно медленный интерфейс, но если это не проблема, то МК + application processor - самое то, просто и надежно.


485 еще медленнее. На самом деле все коммуникационные устройства работают на контроллере прямого доступа к памяти, а процессор блоками пересылает, что зачастую производится переписыванием адреса из одного интерфейса в другой. Всей работы по пересылке пакета данных процессор делает переписывание пары регистров.
Go to the top of the page
 
+Quote Post
syoma
сообщение Сегодня, 06:15
Сообщение #130


Профессионал
*****

Группа: Свой
Сообщений: 1 643
Регистрация: 14-02-07
Из: наших, которые работают за бугром
Пользователь №: 25 368



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

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

Go to the top of the page
 
+Quote Post
AlexandrY
сообщение Сегодня, 08:56
Сообщение #131


Mentor
******

Группа: Модераторы
Сообщений: 5 457
Регистрация: 19-01-05
Пользователь №: 2 050



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

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

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


Go to the top of the page
 
+Quote Post
syoma
сообщение Сегодня, 17:01
Сообщение #132


Профессионал
*****

Группа: Свой
Сообщений: 1 643
Регистрация: 14-02-07
Из: наших, которые работают за бугром
Пользователь №: 25 368



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

Подумаешь,
Single Product:
OS-II / OS-III: $8,000
CAN Framework: $3,100
Can Open: $10,400
И два человеко-месяца и даже Codesys уже не кажутся чем-то дорогими.
Go to the top of the page
 
+Quote Post
Студент заборстр...
сообщение Сегодня, 17:22
Сообщение #133


Частый гость
**

Группа: Участник
Сообщений: 130
Регистрация: 16-09-17
Пользователь №: 99 334



Дико плюсую.
Чем покупать чужую глючную РТОСь за 10 тыс. бакинких, в которой ты так НИКОГДА и не разберёшься до конца даже за 3 года, лучше написать свою за 2-3 месяца. Что обойдётся работодателю в 1500 баксов (твоя зарплата за 3 месяца)
Go to the top of the page
 
+Quote Post
mantech
сообщение 57 минут назад
Сообщение #134


Профессионал
*****

Группа: Участник
Сообщений: 1 697
Регистрация: 16-08-12
Из: Киров
Пользователь №: 73 143



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


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

9 страниц V  « < 7 8 9
Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 22nd November 2017 - 20:25
Рейтинг@Mail.ru


Страница сгенерированна за 0.01267 секунд с 7
ELECTRONIX ©2004-2016