Перейти к содержанию
    

Запуск RTOS поверх более приоритетного кода

11 минут назад, Quantum1 сказал:

Но это очень стабильное время, я ж говорю +-1...2 такта максимум, оно никуда не плавает, поэтому его спокойно можно точно учитывать. Но это очень много т.к. у RM47, прерывания хитрые там висит куча защит(они для промышленности и автоиндустрии) и как прерывания, так и внутренние шины медленные. На stm32 быстрее бегать должно)

Я вообще-то писал не про время входа в свой ISR, а про случай, когда ваше срочное прерывание возникло в тот момент когда уже только начался вход/выход в другой ISR. И писал это не про ARM-ы с переключением состояний FIQ/IRQ, а про Cortex-M с его NVIC (STM32). Никакой стабильности там быть не может по определению. А будет джиттер в десятки тактов (опять же - Cortex-M).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

On 3/27/2024 at 9:06 PM, jcxz said:

Я вообще-то писал не про время входа в свой ISR, а про случай, когда ваше срочное прерывание возникло в тот момент когда уже только начался вход/выход в другой ISR. И не про ARM-ы с перключением состояний FIQ/IRQ, а про Cortex-M с его NVIC (STM32). Никакой стабильности там быть не может по определению. А будет джиттер в десятки тактов (опять же - Cortex-M).

Так что cortex -m что -r,  что -a.   Это ж всё ARM ))) но теперь понятно, вы про  сравнение nvic и fiq/irq.

 

Изменено пользователем Quantum1

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

4 минуты назад, Quantum1 сказал:

Так что cortex -m что -r,  что -a.   Это ж всё ARM ))) но теперь понятно, вы про  сравнение nvic и fiq/irq

Всё а не всё. Всё-таки CPU с FIQ/IRQ гораздо шустрее реагируют на прерывания, чем Cortex-M с NVIC.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

3 часа назад, Quantum1 сказал:

Допустим на том же RM47(у STM-ов тоже разделение есть, но я не помню какое) шина разделена на несколько грубо говоря секторов(кросс-мультиплексирование), на одном секторе висит одна периферия, на другом другая, на третьем DMA, на четвертой еще RAM ну и т.д. Если нет пересечения то паралельные потоки на одной шине друг друга вообще не чувствуют

Если так удачно случилось, что периферия и доступы не пересекаются (физически или система построена так, чтобы гарантировать отсутствие таких пересечений во времени) - то это, несомненно, благотворительно повлияет на детерминизм, но не сведет предсказуемость задержек к 100%. И тут тогда уже придется не абстрагироваться, а называть конкретный тип CPU и штудировать его возможности. Реально критичные ко времени процессы выполняются на аппаратном уровне - ПЛИСами или возможностями периферии. CPU тут лишь как связующее звено для управления такой периферией. Исходят из расчета на достаточную производительность CPU с запасом, чтобы, например, успеть подготовить данные для отправки на эту самую "быструю" периферию.

Попытка ориентироваться на такты CPU была хорошей практикой в простых МК типа PIC/AVR - вспомним программаторы USB 1.0 на AVR-ках, там времянка ногодрыжного формирования всех USB-сигналов как раз сделана на ассемблере с учетом определенной частоты CPU и CPI инструкций. Этот способ никак не годится для "толстых" микроконтроллеров и тем более Application CPU, хоть даже Real-Time Cortex-R. В последнем ядре, безусловно, есть свои механизмы, но они не гарантируют никаких +/- 1..2..5 тактов.

Цитата

а это как? Это ж прямая потеря данных. LDM в любом случае выполнится

Выполниться то выполнится. Если в CPU не поддерживаются прерываемые LDM/STM, то кирдык капут. Если такая операция начала шинную транзакцию, то возникшее прерывание будет ждать ее завершения. В Cortex-M вопрос прерываемости/перезапуска этих инструкций implementation-defined. Стоит ли игра свеч?

Цитата

А есть в FreeRTOS функционал выделения ему только конкретных прерываний? Допустим полностью запретить FIQ, и разрешить несколько IRQ конкретных(допустим от периферии). 

Для ARM (настоящих, а не Cortex-M, т.к. этот профиль настоящим ARM не является), в которых из CPU торчит только FIQ/IRQ, нет таких разделений - я заглянул в порт FreeRTOS под Cortex-A9 - запрет прерываний, реализуемый критической секцией, реализуется выключением и FIQ, и IRQ.

Цитата

т.е. в ее ядре нет обязательного функционала какой-нибудь сторожевой собаки?))

В ядре ОСРВ? Нет, конечно. С чего ей там быть?🙂 Да и как она должна тогда выглядеть, чтобы всем подходила и всегда работала исправно?

ОСРВ лишь гарантирует, что реакция на некое воздействие произойдет за какое-то гарантированное время. Это время с запасом должно покрывать время всяких переключений контекстов, шинных блокировок CPU и других "непрошенных" задержек. Критичные к задержке (тем более в области десятков - под сотню тактов CPU) выполнения механизмы должны быть сделаны железно, а не программно.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

On 3/27/2024 at 10:23 PM, Arlleex said:

Если так удачно случилось, что периферия и доступы не пересекаются (физически или система построена так, чтобы гарантировать отсутствие таких пересечений во времени) - то это, несомненно, благотворительно повлияет на детерминизм, но не сведет предсказуемость задержек к 100%. 

А в этом и есть искусство разработчика, максимально эффективно и экономно выбрать и hard, и soft ресурсы для решения задачи. Или если выбирать нельзя, извернуться и решить задачу имеющимися. А то сейчас много кодописов "ОЙ! В этой библиотеке AVR, нет функции включения лампочки/открывания дверей, я что теперь в регистры и даташиты что ли лезть должен?? фу-фу-фу я ж програмист высокоуровневый! Я хочу задачи решать, а не в этих ваших битах ковыряться.. Пойду возьму Малинку, накачу Linux, там это есть... и вооще это IoT, модно и современно, C то уже такое себе, хочу на Rust писать....  ассемблер??? вы че совсем, я что на пенсионера похож? человек способен только на 10% лучше компилятора написать...."  и прочее бредовое ко-ко-ко....

 

On 3/27/2024 at 10:23 PM, Arlleex said:

Реально критичные ко времени процессы выполняются на аппаратном уровне - ПЛИСами или возможностями периферии. CPU тут лишь как связующее звено для управления такой периферией. Исходят из расчета на достаточную производительность CPU с запасом, чтобы, например, успеть подготовить данные для отправки на эту самую "быструю" периферию.

Абсолютно в точку!! Я сам очень люблю ПЛИС + многоядерный CPU. Но поголовное использование такого не всегда оправдано, к сожалению, так как тащит много накладных расходов как в разработке так и в стоимости изделия. Конечно когда нужен  реал-тайм для управления радиолокатором, то тут конечно без вариантов - ПЛИС)) А если это какой-то пром. прибор где например тоже осуществляется сканирование, но допустим оптическим дефлектором(где не нужно много вычислений), его управление вешается на таймеры, работу которых нужно корректировать каждые 10мкс, т.е. реал-тайм полный, но вычисления, спокойно можно сделать в первые 5 мкс (что бы за остальные 5 мкс периферия спокойно приняла новые значение и подготовилась к новому циклу). Прервались в начале на 0-ой мкс, посчитали, что надо за 3-5 мкс, и дальше софт может работать с тем что выходит из реал-таймовой части, и/или курить бамбук и заниматься любыми прикладными не реал-таймовыми задачами что послать на сервер, там дисплей какой то обслужить и т.д.  .. Это реал-тайм? ДА! потому что мы обязаны принять решения до следующих 10 мкс. Нужен ли тут ПЛИС, нет - он избыточен.

 

 

 

 

On 3/27/2024 at 10:23 PM, Arlleex said:

В последнем ядре, безусловно, есть свои механизмы, но они не гарантируют никаких +/- 1..2..5 тактов.

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

Изменено пользователем Quantum1

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

On 3/27/2024 at 10:23 PM, Arlleex said:

В ядре ОСРВ? Нет, конечно. С чего ей там быть?🙂 Да и как она должна тогда выглядеть, чтобы всем подходила и всегда работала исправно?

да хоть по классике - прерывание по системному таймер(везде есть), хоть внешняя микрушка с window-WDT, тоже простая штука. RTOS ведь по идеалогии не имеет права повиснуть... по краней мере я от нее этого жду)))) может и напрасно)))

Изменено пользователем Quantum1

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

3 hours ago, Quantum1 said:

RTOS ведь по идеалогии не имеет права повиснуть...

Дайте, пожалуйста, описание такой идеологии. Насколько я помню, ОСРВ даёт лишь некоторые гарантии временных характеристик, да предоставляет сервисы для межпроцессного взаимодействия.

3 hours ago, Quantum1 said:

по краней мере я от нее этого жду)))) может и напрасно)))

Возможности конкретной ОСРВ описаны в документации на неё. Ни FreeRTOS, ни scmRTOS, с которыми я работаю, не предоставляют сервисов для работы со сторожевым таймеров.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

8 часов назад, jcxz сказал:

Точно такие же сказки - максимальное время активации задачи во FreeRTOS == 900нс.

А где говорилось про FreeRTOS? Эта RTOS самая тормозная из всех подобных, есть решения побыстрее. И даже если попасть на прерывание, критическую секцию, это даст пару сотен нс "джиттера", совершенно не критично и того же порядка величины. Т.ч. вполне можно говорить о какой-то детерминированности (гарантированности) времени реакции на событие. Обработчики прерываний в этом подходе, разумеется, нужно  делать как можно более короткими, выполняющими самый минимум работы: получил событие -- взвёл сигнал, пихнул в очередь и т.п.

7 часов назад, jcxz сказал:

Всё а не всё. Всё-таки CPU с FIQ/IRQ гораздо шустрее реагируют на прерывания, чем Cortex-M с NVIC.

Расскажите это, например, Cortex-A9 с GIC, у которого вход в IRQ занимает пару сотен тактов (на тактовой CPU 400 МГц задержка от внешнего события, до попадания в обработчик прерывания от него занимает порядка 450 нс -- специально исследовал этот вопрос, снимал времянки осциллографом, очень удивлялся поначалу, пока не понял, почему так).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

On 3/28/2024 at 3:18 AM, haker_fox said:

Дайте, пожалуйста, описание такой идеологии. Насколько я помню, ОСРВ даёт лишь некоторые гарантии временных характеристик, да предоставляет сервисы для межпроцессного взаимодействия.

Возможности конкретной ОСРВ описаны в документации на неё. Ни FreeRTOS, ни scmRTOS, с которыми я работаю, не предоставляют сервисов для работы со сторожевым таймеров.

RTOS это ж про системы с высокой надёжностью, всякие сертификаты там имеют как подразумевает что любое действие прогнозируемо , в том числе сбой.

Видел сети вот такое удачное определение: 

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

On 3/28/2024 at 4:55 AM, dxp said:

Расскажите это, например, Cortex-A9 с GIC, у которого вход в IRQ занимает пару сотен тактов (на тактовой CPU 400 МГц задержка от внешнего события, до попадания в обработчик прерывания от него занимает порядка 450 нс -- специально исследовал этот вопрос, снимал времянки осциллографом, очень удивлялся поначалу, пока не понял, почему так).

Кстати очень полезная информация, благодарю! На A9 ни разу не замерял это время, а он есть в Zynq 7000, иногда его использую. А в каком чипе ваш A9 стоял, и если не сложно от чего там поподробнее там прерывание было?

Изменено пользователем Quantum1

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

23 minutes ago, Quantum1 said:

RTOS это ж про системы с высокой надёжностью, всякие сертификаты там имеют как подразумевает что любое действие прогнозируемо , в том числе сбой.

Но речь идёт о высокой надёжности ОСРВ, а не аппаратного обеспечения. Потому что разработчики ОСРВ не могут нести ответственность за ту аппаратную платформу, на которой их продукт используется. Под аппаратной платформой я понимаю не архитектуру процессора, а созданный на его базе продукт. Поэтому прогнозировать разработчики ОСРВ здесь уже ничего не могут, т.к. даже восстановление после сбоя на каждой платформе может занимать разное количество времени в зависимости от реализации.

Не имея знаний об аппаратной платформе, а их может быть большое количество (мобильный телефон, стиральная машина, частотный привод лифта и т.д. и т.п.), невозможно и заложить в ОСРВ желаемый Вами функционал. Ровно, как и снабдить дистрибутив ОСРВ драйверами для платформы. Хотя подобные попытки и предпринимались. Но, как правило, возможности таких драйверов крайне скромны, и не отвечают требованиям конечного потребителя, который их всё равно пишет сам по причине уникальных задач, решаемых его аппаратной платформой.

30 minutes ago, Quantum1 said:

Видел сети вот такое удачное определение: 

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

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

Поэтому следует читать определения, даваемые уважаемыми специалистами в конкретной области. "Удачное" же определение лишь говорит о Вашей внутренней предрасположенности к данной форумулировке, как наиболее точно отражающей Ваши желания и запросы. А желания и запросы не всегда удовлетворяются реальностью.

Теперь вернёмся к "Вашему" определению. Там написано "вне зависимости от своего состояния и окружения". Можно сразу задать вопросы: если в окружении будут проблемы с питанием, ОСРВ должна работать? Если питание исчезнет совсем? Про своё состояние тоже можно уточнить: если дала сбой плашка памяти SDRAM или контроллер памяти был настроен ошибочно, и данные в ней повреждены, в том числе структуры самой ОСРВ, она должна реагировать предсказуемо? Очевидно, что нет. В этом случае обязан отреагировать сторожевой таймер и перезагрузить систему, давшую сбой. Но этот таймер не относится к ОСРВ точно так же, как и надёжный блок питания, обеспечивающий аппаратную платформу питанием.

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

38 минут назад, Quantum1 сказал:

На A9 ни разу не замерял это время, а он есть в Zynq 7000, иногда его использую. А в каком чипе ваш A9 стоял, и если не сложно от чего там поподробнее там прерывание было?

А вот как раз на Zynq-7000 это и было. 🙂 Прерывания пробовал разные -- от внешней ноги и от таймера.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1) Почитайте Mastering the FreeRTOS Richard Barry. Есть на сайте FreeRTOS.

Ядро ARM позваляет делать прерывания вне ОС.

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

Прерывания, которые вызывают API функции ОС, должны быть в ОС.

В файле FreeRTOSConfig.h сконфигурируй должным образом:

configKERNEL_INTERRUPT_PRIORITY,

configMAX_SYSCALL_INTERRUPT_PRIORITY,

configMAX_API_CALL_INTERRUPT_PRIORITY
 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

On 3/28/2024 at 11:26 AM, haker_fox said:

Теперь вернёмся к "Вашему" определению. Там написано "вне зависимости от своего состояния и окружения". Можно сразу задать вопросы: если в окружении будут проблемы с питанием, ОСРВ должна работать? Если питание исчезнет совсем? Про своё состояние тоже можно уточнить: если дала сбой плашка памяти SDRAM или контроллер памяти был настроен ошибочно, и данные в ней повреждены, в том числе структуры самой ОСРВ, она должна реагировать предсказуемо? Очевидно, что нет. В этом случае обязан отреагировать сторожевой таймер и перезагрузить систему, давшую сбой. Но этот таймер не относится к ОСРВ точно так же, как и надёжный блок питания, обеспечивающий аппаратную платформу питанием.

Да я с вами и не спорю, что это мои хотелки! И они могут не отражаться в реальности.

Под реакцию на состояние, я имел ввиду только поведение кода. ИИП никак не относится к этому.

Допустим пользовательский таск захотел залезть и потереть настройки самой системы без спец разрешения, ОС должна ему сказать низя-низя!   Кстати в Zynq Ultrascale, есть великолепная вещь -  защита аппаратная областей адресов, можно принудительно ограничить какому то ядру область памяти, и только туда он может ходить, если пытается в другие залезть - его во первых шлют лесом, во вторых могут вызвать прерывание на ошибку.  Отказоустойчивая ОС по идеи должна тоже такое делать, но софтово.

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

Опять же повторюсь! Это мои хотелки.

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

Заранее извиняюсь, я не с кем не спорю, просто всегда считал, что раз называется ОС да ещё и реал-тайм с сертификатами, то там ворох защит от сбоев и неправильного юзер ПО есть.... Ан нет....

Изменено пользователем Quantum1

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

5 minutes ago, Quantum1 said:

просто всегда считал, что раз называется ОС да ещё и реал-тайм с сертификатами, то там ворох защит от сбоев и неправильного юзер ПО есть.... Ан нет....

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

On 3/28/2024 at 11:29 AM, dxp said:

А вот как раз на Zynq-7000 это и было. 🙂 Прерывания пробовал разные -- от внешней ноги и от таймера.

Тогда трижды благодарю)))) че то для 400 МГц, 450 нс действительно это прямо совсем печаль-печальная....

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...