В чем разница между системой прерываний FIQ и IRQ?

ARM calls FIQ на быстрое прерывание, подразумевая, что IRQ is нормальным приоритетом. В любой реальной системе будет гораздо больше источников прерываний, чем просто два устройства, и поэтому будет некоторый внешний аппаратный контроллер прерываний, который позволяет маскировать, приоритезацию и т. д. из этих нескольких источников и который управляет линиями запроса прерывания к процессору.

в некоторой степени это делает различие между двумя режимами прерывания избыточны и многие системы не используют nFIQ вообще, или использовать его таким образом, аналогично немаскируемые (NMI) прерывания на других процессорах (хотя FIQ является программным обеспечением, маскируемым на большинстве процессоров ARM).

так почему же ARM называет FIQ "быстрым"?

1. режим FIQ имеет свои собственные выделенные банковские регистры,r8-r14. R14-это регистр ссылок, который содержит обратный адрес (+4) из FIQ. Но если ваш Обработчик FIQ может быть написан так, что он использует только r8-r13, он может воспользоваться этими банковскими регистрами двумя способами:
   • один из них заключается в том, что он не несет накладных расходов на нажатие и выскакивание любых регистров, которые используются подпрограммой службы прерываний (ISR). Это может сэкономить значительное количество циклов на входе и выходе в ISR.
   • кроме того, обработчик может рассчитывать на сохранение значений в регистрах, от одного вызова к другому, так что, например,r8 может использоваться как указатель на аппаратное устройство, и обработчик может полагаться на то же значение в r8 при следующем вызове.
2. расположение FIQ в конце таблицы векторов исключений (0x1C) означает, что если код обработчика FIQ помещен непосредственно в конец векторной таблицы, ветвь не требуется - код может выполняться непосредственно из 0x1C. Это экономит несколько циклов при входе в ISR.
3. FIQ имеет более высокий приоритет, чем IRQ. Этот означает, что когда ядро принимает исключение FIQ, оно автоматически маскирует IRQ. IRQ не может прервать обработчик FIQ. Обратное неверно-IRQ не маскирует FIQ, поэтому обработчик FIQ (если используется) может прервать IRQ. Кроме того, если запросы IRQ и FIQ выполняются одновременно, ядро сначала будет иметь дело с FIQ.

так почему же многие системы не используют FIQ?

1. код обработчика FIQ обычно не может быть записан в C-он должен быть написан непосредственно на языке ассемблера. Если вы достаточно заботитесь о производительности ISR, чтобы захотеть использовать FIQ, вы, вероятно, не захотите оставлять несколько циклов в таблице, кодируя в C в любом случае, но что более важно, компилятор C не будет производить код, который следует ограничению на использование только регистров r8-r13. Код, созданный компилятором C, совместимым с ARM ATPCS процедура вызова standard вместо этого будет использовать регистры r0-r3 для значений нуля и не будет произведите правильное cpsr восстановление кода возврата в конце функции.
2. все оборудование контроллера прерываний, как правило, находится на IRQ pin. Использование FIQ имеет смысл только в том случае, если к входу nFIQ подключен один источник прерываний с наивысшим приоритетом, а во многих системах нет одного источника с постоянным наивысшим приоритетом. Нет никакого значения, соединяющего несколько источников с FIQ, а затем имеющего приоритет программного обеспечения между ними, поскольку это удаляет почти все преимущества FIQ имеет над IRQ.

FIQ или быстрое прерывание часто называют мягкий DMA в некоторых ссылках ARM.
черт FIQ а,

1. отдельный режим с banked регистром включая стог, регистр соединения и R8-R12.
2. отдельный бит включения/выключения FIQ.
3. хвост векторной таблицы (которая всегда находится в кэше и отображается MMU).

последняя функция также дает небольшое преимущество над IRQ который должен ветвиться.

демо скорости в 'C'

некоторые процитировали сложность кодирования в ассемблере для обработки FIQ. gcc имеет аннотации для кода a FIQ обработчик. Вот пример,

void  __attribute__ ((interrupt ("FIQ"))) fiq_handler(void)
{
    /* registers set previously by FIQ setup. */
    register volatile char *src asm ("r8");  /* A source buffer to transfer. */
    register char *uart asm ("r9");          /* pointer to uart tx register. */
    register int size asm ("r10");           /* Size of buffer remaining. */
    if(size--) {
        *uart = *src++;
    }
}

это переводится на следующий почти хороший ассемблер,

00000000 <fiq_handler>:
   0:   e35a0000        cmp     sl, #0
   4:   e52d3004        push    {r3}            ; use r11, r12, etc as scratch.
   8:   15d83000        ldrbne  r3, [r8]
   c:   15c93000        strbne  r3, [r9]
  10:   e49d3004        pop     {r3}            ; same thing.
  14:   e25ef004        subs    pc, lr, #4

процедура ассемблера в 0x1c может выглядеть,

   tst     r10, #0    ; counter zero?
   ldrbne  r11, [r8]  ; get character.
   subne   r10, #1    ; decrement count
   strbne  r11, [r9]  ; write to uart
   subs    pc, lr, #4 ; return from FIQ.

настоящий UART с вероятно, есть готовый бит, но код, чтобы сделать высокую скорость мягкий DMA С FIQ будет только 10-20 инструкций. Основной код должен опросить FIQ r10 чтобы определить, когда буфер завершен. Main (код без прерывания) может передавать и настраивать banked FIQ регистрируется с помощью msr инструкция для переключения в FIQ режим и передача небанковских R0-R7 в регистры R8-R13.

типично прерывание RTOS задержка составит 500-1000 инструкций. Для Linux, это может быть 2000-10000 инструкции. Реальный DMA всегда предпочтительнее, однако, для высокочастотных простых прерываний (как передача буфера),FIQ может обеспечить решение.

как FIQ речь идет о скорости, вы не должны рассматривать это, если вы не защищены в кодировании в ассемблере (или готовы посвятить время). Ассемблер, написанный бесконечно работающим программистом, будет быстрее компилятора. Наличие GCC assist может помочь новичку.

задержка

как FIQ имеет отдельный бит маски, он почти повсеместно включен. На более ранних процессорах ARM (таких как ARM926EJ) некоторые атомарные операции должны были быть реализованы путем маскировки прерываний. Тем не менее, даже с самыми продвинутыми процессорами коры головного мозга, есть случаи, когда ОС будет маскировать прерывания. Часто время обслуживания не критично для прерывания, но время между сигнализацией и обслуживанием. Здесь, the FIQ также имеет преимущество.

слабость

на FIQ не масштабируется. Для того, чтобы использовать несколько FIQ sources, banked регистры должны быть разделены между подпрограммами прерывания. Кроме того, необходимо добавить код, чтобы определить, что вызвало прерывание/FIQ. The FIQ вообще один трюк пони.

если ваше прерывание очень сложное (сетевой драйвер, USB и т. д.), то FIQ, вероятно, делает мало смысла. Это в основном то же самое утверждение, что и мультиплексирование прерываний. The накренился регистры дают 6 бесплатных переменных для использования, которые никогда не загружайте из памяти. Регистрация быстрее, чем память. Регистры быстрее, чем L2-кэш. Регистры быстрее, чем L1-кэш. Регистры быстро. Если вы не можете написать программу, которая работает с 6 переменными, то FIQ не подходит. Примечание: Вы можете удвоить обязанность некоторый регистр с смен и поворот, которые свободны на руке, если вы используете 16-битных значений.

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

резюме

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

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

хаос уже ответил Хорошо, но дополнительная точка, не охваченная до сих пор, заключается в том, что FIQ находится в конце векторной таблицы, и поэтому обычно/традиционно просто начать рутину прямо там, тогда как вектор IRQ обычно именно так. (т. е. прыжок в другое место). Избегание этой дополнительной ветви сразу после полного тайника и контекстного переключателя-небольшое увеличение скорости.

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

другая причина в случае FIQ, меньшее количество регистра необходимо нажать в стеке, режим FIQ имеет R8 к регистрам r14_fiq

Я считаю, что это то, что вы ищете:

http://newsgroups.derkeiler.com/Archive/Comp/comp.sys.arm/2005-09/msg00084.html

по существу, FIQ будет иметь наивысший приоритет с несколькими источниками IRQ с более низким приоритетом.

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

FIQs являются более приоритетными, без сомнения, остальные моменты я не уверен..... FIQs будет поддерживать высокоскоростную передачу данных (или) обработку канала, где требуется высокая скорость обработки данных мы используем FIQs и обычно IRQs используются обычные прерывания handlling.

Это зависит от того, как мы разрабатываем обработчики прерываний, поскольку FIQ, наконец, может не понадобиться одна инструкция ветви, также у него есть уникальный набор регистров r8-r14, поэтому в следующий раз, когда мы вернемся к прерыванию FIQ, нам не нужно нажимать/всплывать стек. Конечно, это экономит некоторые циклы, но опять же не разумно иметь больше обработчиков, обслуживающих один FIQ, и да, FIQ имеет больший приоритет, но это не повод говорить, что он обрабатывает прерывание быстрее, оба IRQ / FIQ работают на одной частоте процессора, поэтому они должны быть запущены на той же скорости.

Это может быть неправильно. Все, что я знаю, это то, что FIQ означает быстрый запрос прерывания и что IRQ означает запрос прерывания. Судя по этим именам, я догадаюсь, что FIQ будет обработан(брошен?) быстрее, чем IRQ. Вероятно, это связано с дизайном процессора, где FIQ прерывает процесс быстрее, чем IRQ. Я извиняюсь, если я ошибаюсь, но обычно я занимаюсь программированием более высокого уровня, я просто предполагаю прямо сейчас.