syoma 1 19 ноября, 2017 Опубликовано 19 ноября, 2017 · Жалоба Сейчас битва идет за наносекунды, но это уже спец железо. Вот фото спец-платы с которой я лично работал: http://www.colfaxdirect.com/store/pc/viewP...?idproduct=2865 сток ядро с PREEMPT_RT, сетевуха - 2 канала по 40Gbit, время реакции всей системы от прихода пакета до ответа в сеть (на границе сетевого интерфейса) - ~250 ns. Ядру приложения надо всего один такт на выдачу результата, это 5ns Какие микросекунды ? Забудьте... Извините, но на ПЛИС я тоже за микросекунду все сделаю. Вопрос был о процессорах.... Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 19 ноября, 2017 Опубликовано 19 ноября, 2017 · Жалоба Тупые interrupt latency/scheduling latency величиной в 2 мкс - это какой-то отстой в наши дни, для x86 Linux уже давно пробита планка в 1мкс для RT apps на стоковом ядре. А Xenomai еще быстрее. Но вопрос не в том как быстро среагировать на прерывание, получить данные, распарсить, посчитать и отослать в сеть. Вопрос в том как быстро это можно сделать пока не сделали конкуренты. И начем уже не важно. А вариант на uCOS/FreeRTOS будет делаться годами, обрастая Linux'ом все равно, так как голая железяка никому нафиг не нужна. Боюсь вы не в курсе дела. Для таких плат вы не то что схемы не имеете, а даже структуры ядра не знаете. Поэтому ваши догадки о скорости обработки прерываний я серьезно принимать не могу. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tarbal 4 19 ноября, 2017 Опубликовано 19 ноября, 2017 · Жалоба Извините, но на ПЛИС я тоже за микросекунду все сделаю. Вопрос был о процессорах.... В конечном счете как делать определяет цена. Разработчик должен уметь сделать работоспособную систему на самом дешевом железе. Если комбинация ПЛИС и процессора будет дешевле чем супер быстрый процессор с операционкой реального времени, то так и придется делать. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 19 ноября, 2017 Опубликовано 19 ноября, 2017 · Жалоба В конечном счете как делать определяет цена. Разработчик должен уметь сделать работоспособную систему на самом дешевом железе. Если комбинация ПЛИС и процессора будет дешевле чем супер быстрый процессор с операционкой реального времени, то так и придется делать. Ага, а потом копнуть поглубже и в каждой ПЛИС найти RISC ядро с RTOS. И круг замкнулся. Нельзя RTOS заменить ПЛИС, это должен знать каждый разработчик. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 49 19 ноября, 2017 Опубликовано 19 ноября, 2017 · Жалоба Сейчас битва идет за наносекунды, но это уже спец железо. Вот фото спец-платы с которой я лично работал: http://www.colfaxdirect.com/store/pc/viewP...?idproduct=2865 сток ядро с PREEMPT_RT, сетевуха - 2 канала по 40Gbit, время реакции всей системы от прихода пакета до ответа в сеть (на границе сетевого интерфейса) - ~250 ns. Ядру приложения надо всего один такт на выдачу результата, это 5ns Какие микросекунды ? Забудьте... Ни о чем. Ибо такое нужно процентам 2-5 от всей массы разработок, а в большинстве своем нужен контроллер(ПЛК) который просто умеет регулировать, включать и выключать что-то, реагируя на датчики и имеющий какую-либо менюшку для настроуки или ГУЙ...И все! Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tarbal 4 21 ноября, 2017 Опубликовано 21 ноября, 2017 · Жалоба Ага, а потом копнуть поглубже и в каждой ПЛИС найти RISC ядро с RTOS. И круг замкнулся. Нельзя RTOS заменить ПЛИС, это должен знать каждый разработчик. Да что вы наводите тень на плетень? В ПЛИС устройства, которые мы сами пишем. Эти устройства выполняют ту работу, которая критична во времени. Чего вы такой процессороцентричный. Один мой знакомый всю обработку видео 1080х1920 на ПЛИС делал без процессоров,. Такие чудеса делал, что мало не покажется. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 49 21 ноября, 2017 Опубликовано 21 ноября, 2017 · Жалоба Один мой знакомый всю обработку видео 1080х1920 на ПЛИС делал без процессоров,. Такие чудеса делал, что мало не покажется. Чисто ради интереса, что он там с видео делал, кодеки свои писал на плисе? Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Viktuar 0 21 ноября, 2017 Опубликовано 21 ноября, 2017 · Жалоба Привет. Собственно вопрос из области начинающих по архитектуре процессорной системы. Делаем новый проект и возник вопрос. С одной стороны есть программа, работающая в жестком реальном времени с коммуникацией, через 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 22 ноября, 2017 Опубликовано 22 ноября, 2017 · Жалоба Чисто ради интереса, что он там с видео делал, кодеки свои писал на плисе? Я все это видел в 2007 году. Многого не помню. Обработка разнообразная, шумоподавление, автоподстройка контрастности, когда из темных мест вдруг проступают детали. Коррекцию цвета и много чего я уже не помню. Но он мужик крутой. Стоял у истоков телевидения высокого разрешения. А почему нет, я и сам так делал. А вообще на ПЛИС хорошо ложатся такие алгоритмы как интерполяция цветов (debayer), коррекция дефектных пикселей, цветокоррекция, фильтрация, автояркость/контраст, преобразование цветовых пространств и т.д. Причем для 1080х1920 все вышеперечисленное влезет в какой-нибудь мелкий ультрмалопотребляющий lattice. А в dsp, например, тот же debayer займет кучу процессорного времени с его ~100 млн. умножений и 100 млн. сложений на кадр. Именно. Лучше ничего не придумали. Самые крутые видеочипы самых крутых фирм именно так и сделаны. ИМХО это самый лучший вариант в вашем случае. Минимальная вероятность завязнуть в разработке и отладке програм и провалить сроки. Минус только в том, что can - достаточно медленный интерфейс, но если это не проблема, то МК + application processor - самое то, просто и надежно. 485 еще медленнее. На самом деле все коммуникационные устройства работают на контроллере прямого доступа к памяти, а процессор блоками пересылает, что зачастую производится переписыванием адреса из одного интерфейса в другой. Всей работы по пересылке пакета данных процессор делает переписывание пары регистров. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
syoma 1 22 ноября, 2017 Опубликовано 22 ноября, 2017 · Жалоба Если уж разгуляться и пофантазировать, то я тоже мог бы всю свою программу запустить на ПЛИСе - там, в основном, только автоматы состояний , которые ложатся на логику легко. Но появляется множество вопросов: - Есть ли ПЛИСы, стоимостью с 10-баксовый STM32F? - CAN-корки в ПЛИС дорогие, то есть надо будет ставить отдельный контроллер, так как open-sourcная реализация, насколько я знаю, нерабочая - Поверх CAN мне надо бы CANopen, а RS485 - Modbus RTU - все мастеры. Тут, похоже ПЛИС отдыхает, либо надо будет SoftCore - процессор и делать все на нем. ИМХО неинтересно получается. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 22 ноября, 2017 Опубликовано 22 ноября, 2017 · Жалоба Если уж разгуляться и пофантазировать, то я тоже мог бы всю свою программу запустить на ПЛИСе - там, в основном, только автоматы состояний , которые ложатся на логику легко. Но появляется множество вопросов: - Есть ли ПЛИСы, стоимостью с 10-баксовый STM32F? - CAN-корки в ПЛИС дорогие, то есть надо будет ставить отдельный контроллер, так как open-sourcная реализация, насколько я знаю, нерабочая - Поверх CAN мне надо бы CANopen, а RS485 - Modbus RTU - все мастеры. Тут, похоже ПЛИС отдыхает, либо надо будет SoftCore - процессор и делать все на нем. Грех от разработчиков под ПЛИС требовать понимания сложностей софта. У них только отфильтровать, трансформировать да переслать. А вы как-то непоследовательны. Сначала завели речь о неквалифицированных программистах, а тут рассуждаете, что CANopen могли бы и на автоматах сделать. Купите уже Micrium OS, и получите там все стеки готовые и с такой документацией что даже заядлые ардуинщики поймут. По моим прикидкам сделать самостоятельно CANopen даже не на автоматах это на пару месяцев работы для одного программиста. RTOS с фреймворком обойдется дешевле как ни крути. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
syoma 1 22 ноября, 2017 Опубликовано 22 ноября, 2017 · Жалоба Купите уже Micrium OS, и получите там все стеки готовые и с такой документацией что даже заядлые ардуинщики поймут. Подумаешь, Single Product: OS-II / OS-III: $8,000 CAN Framework: $3,100 Can Open: $10,400 И два человеко-месяца и даже Codesys уже не кажутся чем-то дорогими. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Студент заборстроительного 0 22 ноября, 2017 Опубликовано 22 ноября, 2017 · Жалоба Дико плюсую. Чем покупать чужую глючную РТОСь за 10 тыс. бакинких, в которой ты так НИКОГДА и не разберёшься до конца даже за 3 года, лучше написать свою за 2-3 месяца. Что обойдётся работодателю в 1500 баксов (твоя зарплата за 3 месяца) Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 49 22 ноября, 2017 Опубликовано 22 ноября, 2017 · Жалоба Подумаешь, Single Product: OS-II / OS-III: $8,000 CAN Framework: $3,100 Can Open: $10,400 И два человеко-месяца и даже Codesys уже не кажутся чем-то дорогими. Какие хорошие ценники! Если честно, чего все так в этот кан уперлись, что в нем такого особенного, ну протолкнули бошевцы его в автомашинную автоматизацию, дальше то что? Если не для машин делать системы, вполне 485й устраивает в большинстве случаев, если надо быстро - эзернет. Все доступно, открыто и не надо килобаксы платить... Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 22 ноября, 2017 Опубликовано 22 ноября, 2017 · Жалоба Дико плюсую. Чем покупать чужую глючную РТОСь за 10 тыс. бакинких, в которой ты так НИКОГДА и не разберёшься до конца даже за 3 года, лучше написать свою за 2-3 месяца. Что обойдётся работодателю в 1500 баксов (твоя зарплата за 3 месяца) Это в своей не разберешься уже через 2-3 месяца. Поскольку для своей вы такую документацию точно писать не будете. Мануалы и справочники - вот что самое важное в оси. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться