2017-02-06 14 views
0

Как вы можете гарантировать, что латентность прерывания не будет превышать определенное значение, если могут быть другие переменные и факторы, связанные с оборудованием?Что делает поведение RTOS предсказуемым?

+0

Название спрашивает одно, тело спрашивает другое. Задержка прерывания не связана конкретно с поведением RTOS и в значительной степени не зависит от него. Так что совершенно не ясно, что вы просите. Кажется, это два отдельных вопроса. Я бы дал ответ, но я не знаю, на какой вопрос обращаться. – Clifford

ответ

1

Аппаратная задержка предсказуема. Он не обязательно должен быть постоянным, но он определенно ограничен - например, запись прерывания обычно составляет 12 циклов, но иногда это может занять 15 циклов.

RTOS латентность предсказуема. Он также не является постоянным, но, к примеру, вы можете быть уверены, что RTOS не блокирует прерывания дольше 1000 циклов в любое время. Обычно он блокирует их в течение гораздо более коротких периодов времени, но не дольше, чем указано.

Если только ваше приложение не делает что-то странное (например, while (1); в потоке с наивысшим возможным приоритетом), то латентность всей системы будет представлять собой суммарную задержку аппаратного обеспечения и задержку RTOS.

Важным фактом здесь является то, что использование оперативной системы реального времени для записи приложения не является единственным требованием для приложения также быть в режиме реального времени. В вашем приложении вы должны убедиться, что ограничения в реальном времени не нарушены. Основная работа RTOS - это NOT. Постарайтесь сделать это, чтобы не вводить случайные/непредсказуемые задержки.

Как правило, наиболее важной из «предсказуемых» вещей в RTOS является то, что выполняется поток с наивысшим приоритетом, который не заблокирован. Период. В GPOS (например, на вашем настольном компьютере, в планшетах или в смартфонах) это неверно, поскольку планировщик активно предотвращает головокружительные потоки с низким приоритетом, позволяя им работать некоторое время, даже если есть более важные что делать прямо сейчас. Это делает поведение приложения непредсказуемым, потому что в один прекрасный день он может реагировать в пределах 10us, а на другой день он может реагировать в течение 10 секунд, потому что планировщик решил, что это отличный момент для сохранения журналов на жесткий диск или, возможно, для сбора мусора ,

В качестве альтернативы вы можете думать, что для RTOS латентность находится в диапазоне от микросекунд, может быть, миллисекунды. Для GPOS максимальная латентность, вероятно, будет чем-то вроде десятков секунд.

+0

Благодарим вас за ответ. «В вашем приложении вы должны убедиться, что ограничения в реальном времени не нарушены», каковы эти ограничения? Можете ли вы привести пример, чтобы подтолкнуть точку ко мне? –

+1

@FebinSunny - если вашему приложению требуется латентность от 1 мс, тогда вы можете нарушить это ограничение, если вы ставите критические зоны (путем отключения прерываний или приостановки планировщика), которые длиннее этого. Вы также можете нарушить их, назначив неверные приоритеты для потоков (так что самый важный поток не имеет наивысшего приоритета). Как правило, вам необходимо выполнить какой-то анализ (например, монотонный анализ скорости), чтобы убедиться, что сроки выполнены. RTOS только делает это возможным. –

+0

Другими словами, ключевой мерой определения «реальной тайности» RTOS является изменчивость периодичности цикла для завершения. Обычно это называется джиттером. Чем выше джиттер, тем ниже детерминированный характер RTOS. – endTunnel