| |
 Основной цикл или обработчик прерываний, Что лучше утяжелять? |
|
|
|
|
 Oct 4 2005, 04:46
|
Профессионал
Группа: Свой
Сообщений: 1 432
Регистрация: 7-12-04
Из: Новосибирск
Пользователь №: 1 371
|
Кто какими критериями пользуется выбирая место размещения вызовов функций? В главном цикле, обработчике прерываний или по условию из глав. цикла.
У меня в программе есть функции которые имеет смысл вызывать при прерываниях: АЦП, УАРТ,.... если они будут в глав. цикле - увеличится длительность цикла. если в обработчике, то длительность обработки, если по условию, то нужно больше создавать программных флагов (по условию). Кто как решает?
--------------------
OrCAD, Altium,IAR, AVR....
|
|
|
|
|
|
|
 |
Ответов
|
|
Oct 5 2005, 01:17
|
Участник
Группа: Свой
Сообщений: 26
Регистрация: 28-07-04
Пользователь №: 406
|
Если не жалко отдать 5-10% циклов на overhead планировщика (зависит от количества задач и частоты переключенич контекстов) то однозначно RTOS. Даже для AVR. В результате будет проще спланировать приоритеты, порядок доступа к ресурсам и т.д. Очень рекомендую uC/OS (www.micrium.com). Порт для AVR у них есть.
А если по сути вопроса - в обработчиках прерываний лучше делать как можно меньше. По быстрому обработать железо и выставить флаг. Основной цикл проверит флаг (и его приоритет) и передаст управление функции. Если все делать в ISR то real-time реакция системы может стать плохопредсказуемой.
|
|
|
|
|
|
|
|
Feb 13 2006, 11:40
|
Частый гость
Группа: Свой
Сообщений: 100
Регистрация: 19-01-05
Из: Москва
Пользователь №: 2 064
|
Цитата(Olxx @ Oct 5 2005, 04:17)  А если по сути вопроса - в обработчиках прерываний лучше делать как можно меньше. По быстрому обработать железо и выставить флаг. Основной цикл проверит флаг (и его приоритет) и передаст управление функции. Если все делать в ISR то real-time реакция системы может стать плохопредсказуемой. Если обработку событий делать в прерываниях, то предсказуемость как раз будет полная. Т.е. это и будет жесткий Real-Time. А вот Interrupt Latency возрастет. Вопрос в том, чем пожертвовать...
|
|
|
|
|
|
|
|
Feb 14 2006, 07:32
|
Adept
Группа: Свой
Сообщений: 3 469
Регистрация: 6-12-04
Из: Novosibirsk
Пользователь №: 1 343
|
Цитата(defunct @ Feb 14 2006, 03:15) Цитата(TMX @ Feb 13 2006, 13:40)
Если обработку событий делать в прерываниях, то предсказуемость как раз будет полная. Т.е. это и будет жесткий Real-Time.
А вот Interrupt Latency возрастет.
Вопрос в том, чем пожертвовать...
Не скажите, предсказуемость наоборт нарушится. Чем больше Latency Time тем дальше система отдаляется от Real Time. Это как посмотреть. Коллега TMX совершенно правильно заметил, что если все делать в прерываниях, то будет жесткий real-time. Но реакция на события со стороны задач (процессов/тредов) ухудшится. И весь вопрос только лишь состоит в том, чему отдать предпочтение. Так что real-time не ухудшится, он просто будет другим. Какой вариант выбрать - зависит от целевой задачи проекта.
--------------------
«Отыщи всему начало, и ты многое поймёшь» К. Прутков
|
|
|
|
|
|
|
|
Feb 14 2006, 12:08
|
кекс
Группа: Свой
Сообщений: 3 825
Регистрация: 17-12-05
Из: Киев
Пользователь №: 12 326
|
Цитата(dxp @ Feb 14 2006, 09:32) Это как посмотреть. Коллега 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 будет выше всех остальных прерываний, тогда вообще нельзя спрогнозировать реакцию системы на другие события.. Я хочу сказать, что разумно не прибегать к крайностям, а найти компромисс, между полной обработкой событий в прерываниях и полностью отложенной обработкой событий в основном цикле программы.
Сообщение отредактировал defunct - Feb 14 2006, 12:20
|
|
|
|
|
|
Сообщений в этой теме
 arttab Основной цикл или обработчик прерываний Oct 4 2005, 04:46 Andy Mozzhevilov Цитата(arttab @ Oct 4 2005, 09:46)Кто какими ... Oct 4 2005, 05:09 Born Если в прерываниях не используютчя таймеры (то ест... Oct 4 2005, 05:24 arttab мк AVR. и операционка отпадает Oct 4 2005, 05:31 Andy Mozzhevilov Цитата(arttab @ Oct 4 2005, 10:31)мк AVR.... Oct 4 2005, 05:36 Evgeny_CD Цитата(Andy Mozzhevilov @ Oct 4 2005, 09:36)м... Oct 5 2005, 08:50 dxp Цитата(Evgeny_CD @ Oct 5 2005, 14:50)Цитата(A... Oct 5 2005, 10:44 upc2 Цитата(arttab @ Oct 4 2005, 08:31)мк AVR.... Oct 4 2005, 06:58 kons Я эту проблему решал (на AVR же) путем введения тр... Oct 4 2005, 07:21 dxp Цитата(kons @ Oct 4 2005, 13:21)Я эту проблем... Oct 4 2005, 12:34 defunct Цитата(kons @ Oct 4 2005, 09:21) Идея в с... Feb 10 2006, 08:26 kons На AVR (mega103/128). Только RTOS - несколько гром... Oct 4 2005, 13:59 arttab Спасибо за ваши мнения. Интересный вопрос я задал.... Oct 5 2005, 03:55 Seishel релиз простой, если вам необходимо мгновенно обраб... Feb 9 2006, 15:46 TMX ЦитатаНе скажите, предсказуемость наоборт нарушитс... Feb 14 2006, 07:41 dxp Цитата(TMX @ Feb 14 2006, 13:41) кооперат... Feb 14 2006, 08:18 TMX Цитата(dxp @ Feb 14 2006, 11:18) proc, вр... Feb 14 2006, 09:53
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|
