Подтвердить что ты не робот

Метод опроса или прерывания

Когда следует использовать метод опроса и когда следует использовать метод на основе прерываний? Существуют ли сценарии, в которых оба могут быть использованы?

4b9b3361

ОТВЕТЫ

Ответ 1

Если интересующее событие:

  • Асинхронный
  • Срочное
  • Нечасто

тогда обработчик на основе прерываний будет иметь смысл.

Если интересующее событие:

  • Синхронный (т.е. вы знаете, когда ожидать его в небольшом окне)
  • Не срочно (т.е. медленный интервал опроса не имеет вредных последствий)
  • Частые (т.е. большинство ваших циклов опроса создают "хит" )

тогда опрос может быть лучше подходит.

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

Ответ 2

Следует избегать опроса, если это возможно, поскольку он обычно изливает много циклов ЦП (если только вы не собираетесь опросить вас в течение короткого времени или (b) вы можете позволить себе спать в течение разумного времени в ваш цикл опроса). Недостаток процессорных циклов плохой не только с точки зрения производительности, но и приводит к увеличению потребления энергии, что вполне может быть проблемой для встроенных приложений с батарейным питанием.

Ответ 3

При принятии решения о опросе или прерывании вам необходимо полностью понять природу события, которое вы пытаетесь выполнить, и ваш ответ на него.

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

В этом примере процедура прерывания реагирует на лазерный луч, который становится ясным и настраивается для события, где он блокируется:

   BEAM_INTR_EN = TRUE;   /*re-enable the beam interrupts*/

   /*Set the beam interrupt for the next clear to blocked event*/
   BEAM_INTR_EDGE = CLEAR_TO_BLOCKED;
   BEAM_INTR_FLAG = FALSE; /*Clear the interrupt*/

Есть 2 слабые точки этого кода: 1) Если лазерный луч снова заблокирован до того, как флаг прерывания очищен (BEAM_INTR_FLAG = FALSE;). Прерывание будет пропущено, и код будет не синхронизирован с состоянием лазерного луча.

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

Самый простой способ исправить 1) заключается в двойной проверке после того, как вы настроили прерывание, если оно произошло, а затем принудительно прервать. Чтобы исправить 2) переместите включение прерываний после двойной проверки:

   /*Set the beam interrupt for the next clear to blocked event*/
   BEAM_INTR_EDGE = CLEAR_TO_BLOCKED;
   BEAM_INTR_FLAG = FALSE; /*Clear the interrupt*/

   /*Double check beam state to see if it has already gone blocked*/
   if (BEAM_STATE == BEAM_BLOCKED)
   {
      BEAM_INTR_FLAG = TRUE; /*Force the interrupt to re-enter the ISR after exiting*/
   }
   BEAM_INTR_EN = TRUE;    /*re-enable the beam interrupts*/

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

В принципе:

   Set the edge to detect the next interrupt event
   Clear the interrupt flag
   if (the event has already occurred)
   {
      Set the interrupt flag to force the interrupt
   }
   Enable the interrupt

Если время ответа на событие должно быть последовательным (например, 1 мс +/- 10 после того, как линия ввода высока, передайте сигнал события), тогда прерывания обычно лучше всего.

Если время ответа на событие должно быть в течение определенного времени (например, в пределах 1 мс линии ввода, идущей высоко, передайте сигнал события), тогда лучше было бы прерывать.

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

Прерывания также хороши для того, чтобы позволить процессорам переходить в режимы с низким энергопотреблением (sleep/idle и т.д.), ожидая чего-то.

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

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

void fnInitialiseSystem(void)
{
   if (MODE_INPUT == MODE_A) /*First polling of the MODE_INPUT*/
   {
      PR2 = PR2_MODE_A;
   }
   else
   {  
      PR2 = PR2_MODE_B;
   }
   OpenTimer2( TIMER_INT_ON &
               T2_PS_1_1     &
               T2_POST_1_8   );

   if (MODE_INPUT == MODE_A) /*Second polling of the MODE_INPUT*/
   {
      CurrentMode = MODE_A;
      PROBE_INT_EDGE = CLEAR_TO_BLOCKED;
   }
   else
   {  
      CurrentMode = MODE_B;
      PROBE_INT_EDGE = BLOCKED_TO_CLEAR;
   }
}

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

Например, при отключении деактивации коммутатора достаточно регулярно проверять коммутатор (каждые 1 мс?), и если несколько из них (например, 16) различаются (переключатель закрыт) из отфильтрованной версии (переключатель открыт), то обновлять результат и выполнять требуемое действие. Будьте осторожны с сигнальным сглаживанием, колебательный сигнал может выглядеть стабильным!

Примером использования опроса и прерываний является, опять же, использование ввода, который не изменяется часто, но шумно, когда он это делает. Тем не менее, опять же, это хороший пример: код может настроить прерывание, чтобы проверить изменение состояния коммутатора, когда происходит прерывание, тогда коммутатор может регулярно проверяться до тех пор, пока состояние коммутатора не станет "стабильным" (либо изменено государство или обратно к тому, что это было). Это дает преимущество низкой обработки накладных расходов, когда ничего не происходит, и фильтрации шума, когда что-то происходит.

Ответ 4

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

Ответ 5

Вот несколько интересных ссылок, которые я натолкнулся, анализируя методы опроса и прерывания - http://web.engr.oregonstate.edu/~traylor/ece473/lectures/interrupts.pdf - Очень интересная ссылка http://www.atarimagazines.com/compute/issue149/60_Interrupts_made_easy.php
http://www.electro-tech-online.com/micro-controllers/8440-interrupt-vs-polling.html http://www.microchip.com/forums/m397196-print.aspx http://www.cs.huji.ac.il/course/2006/67630/Lectures/interrupts.pdf http://sunsite.nus.edu.sg/LDP/LDP/tlk/node86.html

Надеюсь, что это будет полезно.

Ответ 6

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

Ответ 7

В принципе, режим опроса используется в случае, если режим прерывания недоступен из-за некоторых аппаратных или программных соображений. Таким образом, режим прерывания более предпочтителен с точки зрения энергопотребления, производительности и т.д. (Согласен с Полом R). Режим опроса также может использоваться при прототипировании, для ядер, не требующих периферии, и для некоторых целей тестирования.

Ответ 8

Прерывания предпочтительнее, когда требуется низкая латентность. Если вы опросите какое-то условие N раз в секунду, то в среднем вы обнаружите это условие во времени на половину 1/N после того, как оно действительно произошло.

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

Ответ 9

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

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

Ответ 10

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

  • Внешние и внутренние источники синхронизации инициируют прерывания - это критически важно для так что мы можем синхронизировать их.
  • Входящие последовательные сообщения вызывают прерывания. Получение FIFO должно обслуживаться до переполнения.
  • Исходящие сообщения вызывают прерывания, когда FIFO частично пуст - он должен быть перезаполнен до того, как он будет переполнен.
  • ISF устанавливает семафоры, опрошенные в фоновом режиме. Это имеет 2 преимущества:
    • Вычисление, необходимое для обработки входящих событий, может быть длительным; если бы он остался в ISR, он мог бы задержать другие ISR за пределы их срока службы.
    • События могут быть секвенированы. Например, цикл опроса может гарантировать, что вычисление X всегда происходит между сбором данных АЦП и анализом входящих сообщений, даже если иногда сообщение приходит немного раньше ожидаемого.

Ответ 11

Режим опроса может быть полезен в системах с высокочастотными событиями, когда служебные данные, связанные с входом и выходом обработчиков прерываний, используют больше циклов ЦП, чем просто опрос. Например, опрос может использоваться в IP-маршрутизаторе, чтобы максимизировать пропускную способность ЦП, доступную для обработки пакетов.

Ответ 12

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

Ответ 13

Гораздо лучше пойти с Interrupt based design по сравнению с polling based, потому что опрос основан на недостатке в том смысле, что он ожидает, что данные будут возвращены в каждом опросе. Теперь вы можете сказать, что я обойду этот случай, когда один опрос вернет мне ошибку, но почему хешь тратит все циклы циклов процессора на что-то, когда он может также вернуть ошибку?? И ожидать, что опрос может оказаться неудачным, - это практический сценарий продукта.

Interrupt based designs имеют еще больший смысл, когда в одном опросе имеется много уровней функций. Для меня это обычная практика: продолжаете ли вы постоянно спрашивать (опроса) своего друга каждый день, есть ли у него информация, которая вам нужна, или просто скажите ему, что interrupt меня, когда у вас есть необходимая мне информация. Я думаю, что мы поступаем правильно в повседневной жизни, но не понимаем.

Но interrupt based architectures при реализации требует четкого понимания publish-subscribe design principle. И, когда это делается в доменах приложений, они требуют, чтобы часть кода, отправляющая прерывания, была действительно хорошо написана. Это хорошо, поскольку оно сжимает сложность и в одном месте.

В дополнение к выше следуют другие преимущества, которые обеспечивает беспроблемная архитектура на основе опроса:

  • Asynchrounous
  • Хорошо подходит в случае редких событий/обновлений
  • Обновление только при наличии доступных сценариев
  • Улучшенная обработка и управление ошибками
  • Лучшее использование циклов процессора
  • Лучшее время работы от батареи mgmt
  • Удерживает слушателей от сложности ниже

Всякий раз, когда вы проектируете sw, и у вас есть этот выбор, вы всегда должны выбрать дизайн interrupt на основе polling, потому что дизайн на основе interrupt может заполнить для polling ситуацию с использованием прослушивателей но дизайн, основанный на опросах, никогда не сможет выполнить требования, требующие дизайна на основе interrupt.

Ниже приведена краткая сравнительная матрица:

                     -INTERRUPT-      -LOOP-
Speed                  fast            slow
Eficiency              good            poor
CPU waste              low             high
multitasking           yes             no
complexity             high            low
debugging              +/- easy        easy
critical in time       excellent       poor
code bloat             low impact      high impact

Ответ 14

Видите, у нас есть 5 основных методологий: 1) Слепой ЦП проверяет данные каждые x мс. Контрольный контакт ETC 12. 2) Опрос (занят/ожидание) Процессор всегда проверяет и ожидает поднятия флага, как UART поднимает флаг после передачи пакета. Навсегда проверяя флаг Регистр. (Лучшее время отклика), но процессор не может выполнить что-либо еще. 3) Прерывание: ЦП работает нормально, если происходит прерывание, ЦП переключит контекст на ISR. если на штыре 18 виден падающий край, выполните ISR (1). Неплохое время отклика и процессор может делать все что угодно, пока ISR не активен. Делайте это с помощью срочных приложений, которые вы не знаете, когда это может произойти. 4) Периодический опрос: процессор делает свое дело, но каждые мс секунды проверяет вывод 11. Слепой ничего не делает между ними. Худшее время отклика, а не срочные приложения, делайте это, когда вы не доверяете оборудованию, которое вызовет прерывание. он может быть создан с использованием прерывания по таймеру. 5) Прямой доступ к памяти. Расширенный интерфейс взаимодействия. Переносит данные прямо из/в память. Вход будет считан в память напрямую. Вывод будет записан из памяти напрямую. Оба используют контроллер.