Harbour 0 10 ноября, 2017 Опубликовано 10 ноября, 2017 · Жалоба Линукс это классно. Линукс - это модно Только никто не гарантирует, что данный дистрибутив гарантирует отсутствие дедлоков, пропусков прерываний, инверсий приоритетов и пропуска дедлайнов. Скажут только "вероятность этого мала" А если у Вас приложения, где вероятность всего перечисленного должна быть не "мала", а "ТОЧНО равна нулю"? Точно равна нулю только глупость человеческая, даже заточенные под RT железки ломаются. Linux, в подходе Xenomai, вообще ни на что не влияет - он может даже зависнуть или находится в tripple-fault (oops) состоянии - RT как работало так и будет продолжать работать, проверено не раз. Если хочется гарантий "5 девяток" - делается резервирование. т.е. ставится 2-3 устройства как принято везде в авиа и военке. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
syoma 1 10 ноября, 2017 Опубликовано 10 ноября, 2017 · Жалоба RT как работало так и будет продолжать работать, проверено не раз. На чем проверено? Примеры рабочих железяк можно? Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tarbal 4 11 ноября, 2017 Опубликовано 11 ноября, 2017 · Жалоба Извиняюсь, но это разве пример real-time в контексте данной темы? В контексте данной темы был поднят вопрос о совместимости real-time и Линукса. Это как раз и пример. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 11 ноября, 2017 Опубликовано 11 ноября, 2017 · Жалоба В контексте данной темы был поднят вопрос о совместимости real-time и Линукса. Это как раз и пример. Нет, это не пример. Покажите фото платы дивайса чтобы мы убедились что все действительно работает на одном ядре, одной шине и одном чипе памяти и без полуавтономных хардварных ускорителей протоколов. И с временем реакции не больше 2 мкс. Сейчас такой стандарт для жесткого риалтайма в ARM Cortex Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tarbal 4 12 ноября, 2017 Опубликовано 12 ноября, 2017 · Жалоба Нет, это не пример. Покажите фото платы дивайса чтобы мы убедились что все действительно работает на одном ядре, одной шине и одном чипе памяти и без полуавтономных хардварных ускорителей протоколов. И с временем реакции не больше 2 мкс. Сейчас такой стандарт для жесткого риалтайма в ARM Cortex А кто вам сказал, что если используется Линукс, то все надо делать только программно? На любой системе такой подход иррационален. Я как раз и говорю о том, что надо делать систему так, чтобы все железо работало одновременно. В таком случае система становится очень эффективной. Моя цель создать устройство, а не осматривать окружающих сверху вниз с ощущением собственной крутизны. Мастерство это когда на слабой системе удается сделать крутое устройство, а не кайфовать, что супер навороченная система работает достаточно быстро, чтобы можчно было меньше думать при написании программы. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Den64 0 12 ноября, 2017 Опубликовано 12 ноября, 2017 · Жалоба И с временем реакции не больше 2 мкс. Сейчас такой стандарт для жесткого риалтайма в ARM Cortex Что успеет ARM Cortex на 32МГц за 2мкС? Тем более с RTOS. Всё что нужно выполнять в реальном времени, выполнять нужно в прерываниях. А медленные задачи в процессах. Тем более в RTOS бывают приоритеты процессов. Главное чтобы RTOS быстро переключала задачи и подолгу не держала процессор с запретом прерываний. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 12 ноября, 2017 Опубликовано 12 ноября, 2017 · Жалоба Мастерство это когда на слабой системе удается сделать крутое устройство, а не кайфовать, что супер навороченная система работает достаточно быстро, чтобы можчно было меньше думать при написании программы. А я так понял, что как раз о своей крутизне вы и хотите поговорить. Но где доказательства крутизны? Ok, я приму ее как факт, но покажите мне realtime под линуксом с 2 мкс ответом сделанный вашими руками. В слабой системе вы сделаете слабый realtime- это закон. Что успеет ARM Cortex на 32МГц за 2мкС? Тем более с RTOS. Всё что нужно выполнять в реальном времени, выполнять нужно в прерываниях. А медленные задачи в процессах. Тем более в RTOS бывают приоритеты процессов. Главное чтобы RTOS быстро переключала задачи и подолгу не держала процессор с запретом прерываний. Про то тут и идет речь. Насколько укоротить прерывания и как практически назначать приоритеты задачам и прерываниям в RTOS с более чем десятком задач, многие из которых вы даже не знаете. Еще учесть что в Cortex не так много уровней приоритетов прерываний. Младшие Cortex-ы не рассматриваем. Берем i.MX RT для примера. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
syoma 1 13 ноября, 2017 Опубликовано 13 ноября, 2017 · Жалоба А кто вам сказал, что если используется Линукс, то все надо делать только программно? На любой системе такой подход иррационален. Я как раз и говорю о том, что надо делать систему так, чтобы все железо работало одновременно. В таком случае система становится очень эффективной. Моя цель создать устройство, а не осматривать окружающих сверху вниз с ощущением собственной крутизны. Мастерство это когда на слабой системе удается сделать крутое устройство, а не кайфовать, что супер навороченная система работает достаточно быстро, чтобы можчно было меньше думать при написании программы. В том-то и дело, что в моей системе рациональней весь real-time делать программно, так как в этом случае достаточно одного микроконтроллера с нужным набором периферии, что упрощает дизайн железа. Также в будущем будет легко возможно обновление прошивок с добавлением новых возможностей без модификации железа. Также для меня я считаю мастерством, если устройство будет сделано быстро и в срок и отвечать нужным требованиям. И при этом будет разработано с использованием наличествующих программистов определенной квалификации, без привлечения крутых системщиков или знатоков RTOS. И если при этом устройство потребует мощного МК - не вижу никаких проблем с этим. Так что мастерство бывает разным. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tarbal 4 14 ноября, 2017 Опубликовано 14 ноября, 2017 · Жалоба В том-то и дело, что в моей системе рациональней весь real-time делать программно, так как в этом случае достаточно одного микроконтроллера с нужным набором периферии, что упрощает дизайн железа. Также в будущем будет легко возможно обновление прошивок с добавлением новых возможностей без модификации железа. Также для меня я считаю мастерством, если устройство будет сделано быстро и в срок и отвечать нужным требованиям. И при этом будет разработано с использованием наличествующих программистов определенной квалификации, без привлечения крутых системщиков или знатоков RTOS. И если при этом устройство потребует мощного МК - не вижу никаких проблем с этим. Так что мастерство бывает разным. Возьмите Beaglebone там есть PRU. Это сопроцессор для аппликаций реального времени. Когда я говорю о железе, то подразумевается то, что уже стоит на процессоре. Там ведь куча всяких периферийных устройств внутри. Для звука, видео, графики, интерфейсы разнообразные, таймеры, ШИМ, АЦП и т.д.. Я про это железо говорил. Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 14 ноября, 2017 Опубликовано 14 ноября, 2017 · Жалоба Возьмите Beaglebone там есть PRU. Это сопроцессор для аппликаций реального времени. Странный выбор. Зачем вспоминать это довольно устаревшее решение. Есть же i.MX 6SoloX с полной поддержкой uC/OS и всеми фичами RT Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 54 14 ноября, 2017 Опубликовано 14 ноября, 2017 (изменено) · Жалоба Странный выбор. Зачем вспоминать это довольно устаревшее решение. Есть же i.MX 6SoloX с полной поддержкой uC/OS и всеми фичами RT Не знаю, какие там фичи есть, но раньше в серии imx6 был более-менее рабочий platform sdk, теперь и его куда-то заныкали, везде пишут линукс-онли... Изменено 14 ноября, 2017 пользователем mantech Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Tarbal 4 17 ноября, 2017 Опубликовано 17 ноября, 2017 · Жалоба Странный выбор. Зачем вспоминать это довольно устаревшее решение. Есть же i.MX 6SoloX с полной поддержкой uC/OS и всеми фичами RT А мне нравится. И буду вспоминать. Кстати они разного класса Beaglebone Cortex A8, imx6 Cortex A9. Мне техасовская документация больше нравится. Пытался как-то осилить как конфигурировать GPIO imx53 - ниасилил. А вот в AM3715 легко пошел. Вы пробовали читать фрискейловскую мутотень? Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 54 17 ноября, 2017 Опубликовано 17 ноября, 2017 · Жалоба Пытался как-то осилить как конфигурировать GPIO imx53 - ниасилил GPIO у фриски - это отдельная мутотень, из цикла "найди тут логику", согласен :laughing: А вот в AM3715 легко пошел. Решил использовать фриску (МХ6) только потому, что в нем был LVDS и недорогая плата отечественной сборки, бона уж больно кусачая была... Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Harbour 0 19 ноября, 2017 Опубликовано 19 ноября, 2017 · Жалоба На чем проверено? Примеры рабочих железяк можно? любое x86 железо не на интел чипсете ;)) Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Harbour 0 19 ноября, 2017 Опубликовано 19 ноября, 2017 · Жалоба Нет, это не пример. Покажите фото платы дивайса чтобы мы убедились что все действительно работает на одном ядре, одной шине и одном чипе памяти и без полуавтономных хардварных ускорителей протоколов. И с временем реакции не больше 2 мкс. Сейчас такой стандарт для жесткого риалтайма в ARM Cortex фото платы - x86 мамка. время реакции на что ? прерывание ? готового ответа системы по ТЗ ? Тупые 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 Какие микросекунды ? Забудьте... Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
