[syoma 1]

Вы допустили возможность прихода нового пакета пока не обработан предыдцщий.

Не, не. Естественно, подразумевается, что пакет будет обработан до того, как придет следующий. Там всего лишь надо вытащить данные из CAN-пакета и положить их в память - работы с гулькин нос.

[AlexandrY 3]

Не, не. Естественно, подразумевается, что пакет будет обработан до того, как придет следующий. Там всего лишь надо вытащить данные из CAN-пакета и положить их в память - работы с гулькин нос.

Тогда нарушаете принцип RMS. Задача должна быть монолитна. А у вас часть задачи в прерывании, часть в потоке. А между ними может вклиниться другая задача или прерывание.

Да что уж там, признайтесь, никакой вы RMS не используете, правда? Так просто, слышали звон.

[syoma 1]

Тогда нарушаете принцип RMS. Задача должна быть монолитна. А у вас часть задачи в прерывании, часть в потоке. А между ними может вклиниться другая задача или прерывание.

Да что уж там, признайтесь, никакой вы RMS не используете, правда? Так просто, слышали звон.

Я собираюсь использовать RMS. Если так хочется сделать задачу монолитной, то можно спокойно собирать все CAN-пакеты в буфер, а затем обработать их скопом в самой приоритетной задаче, не нарушая принципов RMS.

Но это все сводится к тому, как привести асинхронные задачи (такие как обработка CAN-пакетов) к синхронным - т.е. задачам в RMS. У вас есть другие решения данной проблемы?

[Tarbal 4]

Я собираюсь использовать RMS. Если так хочется сделать задачу монолитной, то можно спокойно собирать все CAN-пакеты в буфер, а затем обработать их скопом в самой приоритетной задаче, не нарушая принципов RMS.

Но это все сводится к тому, как привести асинхронные задачи (такие как обработка CAN-пакетов) к синхронным - т.е. задачам в RMS. У вас есть другие решения данной проблемы?

 

Занимаюсь задачами реального времени не один десяток лет, но никогда не слышал о необходимости делать задачи монолитными. "Откуда мол и что это за географические новости"?

 

Гугл тоже не в курсе:

https://www.google.ca/search?dcr=0&q=Re...427&bih=836

[AlexandrY 3]

Занимаюсь задачами реального времени не один десяток лет, но никогда не слышал о необходимости делать задачи монолитными. "Откуда мол и что это за географические новости"?

 

Гугл тоже не в курсе:

https://www.google.ca/search?dcr=0&q=Re...427&bih=836

Ссылка в тему, спасибо.

К вопросу о монолитности задач. Это вытекает из принципа анализа RMS.

А главная вещь в том анализе - дидлайн.

Значит нет никакого смысла разбивать задачу на два этапа - сначала взять быстро ее данные, потом медленно данные обрабатывать.

Это все равно что поставить себе целью фальшивый дидлайн, а на самом деле иметь гораздо более отдаленный дидлайн. Обман самого себя.

Такие финты в анализе RMS учтены быть не могут.

 

По вашей ссылке я вышел на более интересную статью - Rate Monotonic vs. EDF: Judgment Day

Она немного открывает глаза и кстати упоминает подход от "Студент заборстр..."

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

Она немного открывает глаза и кстати упоминает подход от "Студент заборстр..."

Подход очень зависит от того, ГДЕ будет использоваться RTOS.

Одно дело в управлении кофемолкой, то там можно гнаться за красотой реализации, использовать какие-то новомодные концепции тащась от собственной крутости.

Вообще по разному можно выпендриваться.

 

А когда у тебя что-то серьёзное и от того, что у тебя случится дедлок или задача "чуть чуть не успеет" погибнут люди или угробится оборудование стоимостью в миллионы баксов, то вся эта блажь "красиво/не красиво" быстро уходит и остаются простые как гробовая доска железобетонные методы обеспечения надёжности.

 

Я тоже в своё время игрался с разными концепциями, соблазнившись их красотой, когда писал RTOS "для себя". Чисто из научного интереса.

 

Но когда задачи стали серьёзными ("жёсткий реалтайм" и никаких дедлоков и "не успела я" иначе будет большой бадабум), то в конце концов пришёл к описанной мной выше реализации

[AlexandrY 3]

Но когда задачи стали серьёзными ("жёсткий реалтайм" и никаких дедлоков и "не успела я" иначе будет большой бадабум), то в конце концов пришёл к описанной мной выше реализации

Как нибудь поподробней можете рассказать про свою реализацию?

Сколько задач было? Какое время цикла?

[Tarbal 4]

Ссылка в тему, спасибо.

К вопросу о монолитности задач. Это вытекает из принципа анализа RMS.

А главная вещь в том анализе - дидлайн.

Значит нет никакого смысла разбивать задачу на два этапа - сначала взять быстро ее данные, потом медленно данные обрабатывать.

Это все равно что поставить себе целью фальшивый дидлайн, а на самом деле иметь гораздо более отдаленный дидлайн. Обман самого себя.

Такие финты в анализе RMS учтены быть не могут.

 

По вашей ссылке я вышел на более интересную статью - Rate Monotonic vs. EDF: Judgment Day

Она немного открывает глаза и кстати упоминает подход от "Студент заборстр..."

 

Ага понятно. Дайте определение монолитной задачи или укажите где про это можно почитать.

 

[syoma 1]

погибнут люди или угробится оборудование стоимостью в миллионы баксов,

Все-таки не стоит мешать эти вещи. Потому, что тут очень разные требования к обеспечению надежности и соответственно решения.

 

Также есть разница по

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

Тут опять же разные требования и разные решения обеспечения надежности.

[Tarbal 4]

Все-таки не стоит мешать эти вещи. Потому, что тут очень разные требования к обеспечению надежности и соответственно решения.

 

Также есть разница по

 

Тут опять же разные требования и разные решения обеспечения надежности.

 

Да не слушайте вы их.

Для круто надежных разработок есть такой стандарт DO-178B.

 

Он обходится без чудотворных монолитных задач.

 

Когда 7 лет назад я работал в компании, которая для авиации делала программы, было только две операционки, которые сертифицированы под это. QNX не была к моему удивлению.

Rate Monotonic Scheduling никак операционку не заменит. Он просто отвечает на вопрос как правильно (и возможно ли) расставить приоритеты задачам, чтобы критические задачи не опаздывали. До формализации этого алгоритма делали так: ставили как подскажет интуиция, а когда выяснялось, что есть проблемы, то исправляли. Я сделал можество устройств, некоторые можно купить на ebay и у меня ни разу не возникало проблем с приоритетами.

[Harbour 0]

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

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

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

 

Если все это реализовывать на одном процессоре, то получается, что надо использовать RTOS, что требует определенных программистских навыков и не нравится то, что это уменьшает защиту системы от внешних хакерских атак. Если из-за Ethernetа зависнет основная программа - это будет очень-очень плохо. Т.е. в результате увеличиваем затраты на разработку, делаем сложную программу, но уменьшаем стоимость железа.

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

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

 

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

 

Зачем изобретать, то что придумано более 20 лет назад ? Сегодня один проц (без всяких каличных Cortex-M гибридов) легко тянет обе задачи. RT супервизор счедулит RT-прерывания и RT-задачи, запуская основную ОС как самую низкоприоритетную non-RT задачу, включая все ее non-RT драйвера, в том числе и графические. Вопрос в нужном времени отклика и джиттере. Для Linux один из таких супервизоров реализован в проекте Xenomai. В комплекте идет RT drivers framework где есть и CAN. Пашет на ARM, AARCH64, NIOS, x86, PPC. Поддерживается SMP, в том числе и в RT пространстве, с разными affinity извращениями.

Данный подход позволяет реализовывать hard RT не парясь о жопообразности разработки под уникальные RTOS и наличии поддержки/драйверов под свое железо. Как известно - Linux работает везде и писать под него умеют теперь даже обезьяны, которые случайно засматривались в окна индусских программистов.

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

Как известно - Linux работает везде и писать под него умеют теперь даже обезьяны, которые случайно засматривались в окна индусских программистов.

Линукс это классно. Линукс - это модно

Только никто не гарантирует, что данный дистрибутив гарантирует отсутствие дедлоков, пропусков прерываний, инверсий приоритетов и пропуска дедлайнов.

 

Скажут только "вероятность этого мала"

 

А если у Вас приложения, где вероятность всего перечисленного должна быть не "мала", а "ТОЧНО равна нулю"?

Изменено 9 ноября, 2017 пользователем Студент заборстроительного

[mantech 35]

Как известно - Linux работает везде и писать под него умеют теперь даже обезьяны, которые случайно засматривались в окна индусских программистов.

 

А вы не заметили, что эти обезьяны даже близко не подходят к написанию драйверов уровня ядра, да и просто не пишут на си, а больше на питонах, пхп, и вообще, башах всяких... Что это за "программирование" - отдельный вопрос. Но таки да - линукс - это модно, а я не модный

[Tarbal 4]

Линукс это классно. Линукс - это модно

Только никто не гарантирует, что данный дистрибутив гарантирует отсутствие дедлоков, пропусков прерываний, инверсий приоритетов и пропуска дедлайнов.

 

Скажут только "вероятность этого мала"

 

А если у Вас приложения, где вероятность всего перечисленного должна быть не "мала", а "ТОЧНО равна нулю"?

 

Да ладно вам.

Вот эта штука принимает и транскодирует (и много чего другого) 32 канала видео одновременно и сделана на Линуксе:

https://www.cisco.com/c/en/us/products/coll...c78-736419.html

 

Все зависит от умения.

Одни считют, что пусть компьютер за них думает, а другие учатся.

 

Зачем изобретать, то что придумано более 20 лет назад ? Сегодня один проц (без всяких каличных Cortex-M гибридов) легко тянет обе задачи. RT супервизор счедулит RT-прерывания и RT-задачи, запуская основную ОС как самую низкоприоритетную non-RT задачу, включая все ее non-RT драйвера, в том числе и графические. Вопрос в нужном времени отклика и джиттере. Для Linux один из таких супервизоров реализован в проекте Xenomai. В комплекте идет RT drivers framework где есть и CAN. Пашет на ARM, AARCH64, NIOS, x86, PPC. Поддерживается SMP, в том числе и в RT пространстве, с разными affinity извращениями.

Данный подход позволяет реализовывать hard RT не парясь о жопообразности разработки под уникальные RTOS и наличии поддержки/драйверов под свое железо. Как известно - Linux работает везде и писать под него умеют теперь даже обезьяны, которые случайно засматривались в окна индусских программистов.

 

Я даже больше скажу. Если уметь писать апликации реального времени, то всю работу будут делать периферийные устройства.

Без лишней скромности скажу, что мне иногда удавалось достичь совсем неплохих результатов на довольно скромном процессоре.

Помнится в конце 90х годов надо было сделать мобильный телефон для установки в машину на основе мотороловского StarTac. Сначала хотели делать на 68HC16, но потихоньку съехали на AVR8035. Сделали успешный телефон CMR2100, а потом на его основе сделали TMR2100. Пока я там работал тысяч сто продали. Кстати о качестве. Можете не верить, но не было баг репортов.

Кстати, чтобы два раза не вставать о времени съэкономленном на разработке.

Когда делали TMR2100, то за счет лишнего потраченного времени программистами удалось съэкономить на материалах лишние 2 миллиона долларов. И вы после этого будете утверждать, что не хотите думать как правильно программировать если есть процессоры с дурной силой?

[syoma 1]

Да ладно вам.

Вот эта штука принимает и транскодирует (и много чего другого) 32 канала видео одновременно и сделана на Линуксе:

https://www.cisco.com/c/en/us/products/coll...c78-736419.html

Извиняюсь, но это разве пример real-time в контексте данной темы?