[jcxz 184]

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

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

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

[Quantum1 1]

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.

 

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

[jcxz 184]

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

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

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

[Arlleex 131]

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) выполнения механизмы должны быть сделаны железно, а не программно.

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

[Quantum1 1]

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 тактов.

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

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

[Quantum1 1]

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

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

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

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

[haker_fox 60]

3 hours ago, Quantum1 said:

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

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

3 hours ago, Quantum1 said:

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

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

[dxp 34]

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

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

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

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

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

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

[Quantum1 1]

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 стоял, и если не сложно от чего там поподробнее там прерывание было?

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

[haker_fox 60]

23 minutes ago, Quantum1 said:

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

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

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

30 minutes ago, Quantum1 said:

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

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

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

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

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

 

 

[dxp 34]

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

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

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

[dOb 8]

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

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

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

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

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

configKERNEL_INTERRUPT_PRIORITY,

configMAX_SYSCALL_INTERRUPT_PRIORITY,

configMAX_API_CALL_INTERRUPT_PRIORITY
 

[Quantum1 1]

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

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

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

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

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

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

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

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

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

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

[haker_fox 60]

5 minutes ago, Quantum1 said:

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

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

[Quantum1 1]

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

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

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