[TMX 0]

А если по сути вопроса - в обработчиках прерываний лучше делать как можно меньше. По быстрому обработать железо и выставить флаг. Основной цикл проверит флаг (и его приоритет) и передаст управление функции. Если все делать в ISR то real-time реакция системы может стать плохопредсказуемой.

Если обработку событий делать в прерываниях, то предсказуемость как раз будет полная. Т.е. это и будет жесткий Real-Time.

А вот Interrupt Latency возрастет.

Вопрос в том, чем пожертвовать...

[defunct 0]

Если обработку событий делать в прерываниях, то предсказуемость как раз будет полная. Т.е. это и будет жесткий Real-Time.

А вот Interrupt Latency возрастет.

Вопрос в том, чем пожертвовать...

 

Не скажите, предсказуемость наоборт нарушится.

Чем больше Latency Time тем дальше система отдаляется от Real Time.

[dxp 50]

Если обработку событий делать в прерываниях, то предсказуемость как раз будет полная. Т.е. это и будет жесткий Real-Time.

А вот Interrupt Latency возрастет.

Вопрос в том, чем пожертвовать...

 

Не скажите, предсказуемость наоборт нарушится.

Чем больше Latency Time тем дальше система отдаляется от Real Time.

Это как посмотреть. Коллега TMX совершенно правильно заметил, что если все делать в прерываниях, то будет жесткий real-time. Но реакция на события со стороны задач (процессов/тредов) ухудшится. И весь вопрос только лишь состоит в том, чему отдать предпочтение. Так что real-time не ухудшится, он просто будет другим. Какой вариант выбрать - зависит от целевой задачи проекта.

[TMX 0]

Не скажите, предсказуемость наоборт нарушится.

Чем больше Latency Time тем дальше система отдаляется от Real Time.

:) "Ничего я на это не скажу, а только отвечу..."

Жесткое РВ, это когда можно рассчитать время обработки события, максимальное и минимальное. И все.

Большое это время или маленькое - не имеет значения. Для ПИД рег. температуры печи и 100 мс достаточно, а для обработки изображения и мкс не хватит. Главное, что разработчик может сказать: "событие Х будет обработано в течение времени не более Y" - это и есть жесткое РВ. Возможны варианты, типа, "событие Х начнется обрабатываться через время не более Y", или "событие Х в среднем обрабатывается через время Y" (мягкое РВ).

Вывод: Interrupt Latency есть важный показатель качества, но не влияет на собственно РВ.

Если у Вас есть другие соображения - предлагаю обсудить отдельно, поскольку это, в общем, не относится к теме.

По теме:

Если надо быстро, то на AVR можно попробовать сделать следующее:

1. Использовать вложенные прерывания (типа в обработчике UART разрешать прерывания от ADC или, например, обработку протокола осуществлять в обработчике прерывания от UART, но с разрешенными прерываниями). Этот подход - самый экономный по ресурсам и с наименьшей реакцией, может применяться если нет спорадических событий. Требует внимательности - стек и т.п.

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

На будущее, думаю, лучше изучить какую-либо RTOS:

вытесняющие:

scmRTOS или uCOS или C kernel или XMK

кооперативные:

Salvo, JacOS, proc

другие :)

Nesos

Успехов!

[dxp 50]

кооперативные:

Salvo, JacOS, proc

другие :)

Nesos

Успехов!

proc, вроде, всегда вытесняющей была.

[TMX 0]

proc, вроде, всегда вытесняющей была.

И осталась, собственно, моя ошибка...

[defunct 0]

Это как посмотреть. Коллега TMX совершенно правильно заметил, что если все делать в прерываниях, то будет жесткий real-time. Но реакция на события со стороны задач (процессов/тредов) ухудшится. И весь вопрос только лишь состоит в том, чему отдать предпочтение. Так что real-time не ухудшится, он просто будет другим. Какой вариант выбрать - зависит от целевой задачи проекта.

Если не возражаете, давайте посмотрим на это так:

пусть есть обработчик прерывания X, который при определенных условиях выполняется за N секунд и обеспечивает RT реакцию на событие X при Tx(время реакции) <= 10*N, и есть обрабочик прерывания Y который выполняется за время M < N секунд, и тоже не нарушает требования к RT при Ty <= N.

 

Если обработку выполнять непосредственно в обработчких прерывания и при одновременном возбуждении прерываний X и Y "победит" обработчик прерывания X, то система перестанет быть RT, т.к. реакция на второе событие будет Ty = N + M.

 

А если формирование события X будет частым, и приоритет прерывания X будет выше всех остальных прерываний, тогда вообще нельзя спрогнозировать реакцию системы на другие события..

 

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

Изменено 14 февраля, 2006 пользователем defunct