Высшая степень вложенности Real/Soft FIQ/IRQ Опции

[GetSmart]

Посвящается zltigo и прочим противникам вложенности прерываний

Только что закончил прикручивать звук в и без того сложный проект под FreeRTOS на LPC2368. Звук - это воспроизведение WAV с MicroSD карточки. Работа с SD сделана на основе исходников ffsample.zip (elm-chan.org).

1. Вложенные FIQ
Звук (вывод в DAC) пришлось весить на FIQ для того, чтобы он не тормозился программой и осью. Но на FIQ уже висело АЦП и переносить его на IRQ было нельзя. Сначала поставил в начале обработчика проверку откуда источник FIQ и развилку на два обработчика. Всё вроде работало. Но при воспроизведении синуса 48000 Гц на осциллографе (да и в динамике) были искажения из-за того, что проц долго находился в FIQ от АЦП. Пришлось исхитряться и делать вложенные FIQ, работающие в режиме и на стеке Undefined Instruction. Работать в режиме FIQ и отрабатывать другие FIQ нельзя (по крайней мере в известных мне компиляторах), т.к. компиляторы используют регистр LR для своих целей. А обработчик FIQ для АЦП у меня имеет очень сложный алгоритм и переписывать его на асм желания не было. Только пролог и эпилог на асме. Вот если бы была опция (атрибут функции), которая запрещала использовать LR внутри функции, то это было бы реально. На асме (асм-обработчике) такое сделать вообще без проблем.

2. Вложенные Software IRQ
Звук в FIQе выводится из двух буферов по 256 байт. Пока один буфер выводится, второй должен успеть обновить данные из SD карточки. Для заполнения этого буфера было выбрано прерывание IRQ со средним приоритетом, вызываемое софтовым способом. То есть как только внутри FIQ произошёл вывод последнего сэмпла из буфера то сразу же записывается (не OR-ится!) бит в VICSoftInt. Далее уровень FIQов продолжает работать с максимальной латентностью не замечая что происходит на более низких уровнях (IRQ,System и прочие). Если на выходе из FIQ есть приоритетные IRQ, то они отрабатываются. Если их нет, то срабатывает софтовое IRQ для подгрузки данных. В начале софтового обработчика сбрасывается флаг софтового прерывания через VICSoftIntClear (не AND-ится!) и происходит переключение в режим и на стек Undefined. То есть я сделал так, что все вложенные прерывания (FIQ & IRQ) работают в режиме и на стеке Undefined Instruction, чтобы они не потребляли "без спросу" стек тредов. Вобщем внутри этого обработчика происходила подгрузка данных и установка флага готовности данных. Затем переключение обратно в IRQ, восстановление регистров, SPSR и окончательный выход в тред или на ещё менее приоритетное прерывание.

Тред при этом, отвечающий за воспроизведение WAV, почти ничего не делает, только запускает воспроизведение и ждёт окончания, вызывая delay(). Всё остальное происходит "автоматически". А софтовое IRQ обеспечивает максимальную латентность подгрузки новых данных.

LPC2368 @ 24MHz легко справляется с воспроизведением 56000 Гц звука в реальном времени из файла на MicroSD без каких-либо глюков. Глюки появляются на 64000. Но и это не предел, если доработать Ченовский исходник так, чтобы там не было лишнего копирования, то 64000 без проблем. Если ещё убрать конвертацию WAV данных при воспроизведении и копировать (через DMA) прямо в буфер, использующийся в FIQ, то и думаю 80000 реально достичь. И это при том, что модуль воспроизведения WAV использует только 1 КБ данных (буферА) в раме плюс стек Undef. Без вложенности таких параметров никогда не достичь. Если поллить флаг подгрузки данных из треда, то он отъест слишком много времени проца, будет иметь самый высокий приоритет и от силы будет поспевать подгружать данные для звука в 10000 Гц. А садить подгрузку данных в невложенное IRQ тоже не выход, т.к. прога там достаточно долго сидит, и множество других, более приоритетных прерываний "заткнутся" и работа девайса нарушится.

Программа в нормальном режиме почти постоянно переключается между пятью режимами ARM-ядра (System, Supervizor, IRQ, FIQ, Undefined) и прекрасно себя чувствует

На картинке - воспроизведение синуса со вложенными FIQ, на нижней - с обычными FIQ. Вместе с FIQ от АЦП.


Пример пролога/эпилога Nested Software IRQ для CW 1.7

Код

static    void WavIntr_Wrapper() __attribute__((naked));
    void WavIntr();            // без static - для стандартной передачи параметров (меньшего сохранения регистров извне)

// софтверное прерывание (VICSoft...), работает в режиме и на стеке Undefined Instruction
static void WavIntr_Wrapper()
{
    asm(  "STMDB    SP!,{R12,LR}        \n\t"        // 8 байт на стеке IRQ, плюс xx байт на стеке Undefined
            "MVN      LR,#~0xFFFFFF00        \n\t"
            "MOV      R12,#" STRINGFY(1 << RES1_INT) "\n\t"
            "STR      R12,[LR,#0xFFFFF01C-0xFFFFFF00] \n\t"    // VICSoftIntClear = (1 << RES1_INT);
            "MRS      R12,SPSR        \n\t"
            "MSR      CPSR_c,#0x1b        \n\t"        // Undef_Mode + Enable IRQ + Enable FIQ
            "STMDB    SP!,{R0-R3,R12,LR}    \n\t");

    WavIntr();            // должна объявляться глобально, без static

    asm(  "LDMIA    SP!,{R0-R3,R12,LR}    \n\t"
            "MSR      CPSR_c,#0x92        \n\t"        // IRQ_Mode + Disable IRQ + Enable FIQ
            "MSR      SPSR_all,R12        \n\t"
            "MVN      LR,#~0xFFFFFF00        \n\t"
//          "MOV      R12,#" STRINGFY(1 << RES1_INT) "\n\t"
//          "STR      R12,[LR,#0xFFFFF01C-0xFFFFFF00] \n\t"    // VICSoftIntClear = (1 << RES1_INT);
            "STR      LR,[LR]            \n\t"        // VICAddress = xx; (сброс приоритетов IRQ)
            "LDMIA    SP!,{R12,LR}        \n\t"
            "SUBS     PC,LR,#4        \n\t");
}

Ещё родилась идея вместо Undef использовать и работать на Supervizor-е. Для этого надо бы внимательно изучить порт LPC2300 FreeRTOS.

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

Сообщение отредактировал GetSmart - Nov 13 2009, 07:32

[zltigo]

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

Обычное дело, сначала в виде аргументов постулаты "было нельзя" и абстрактно написанные "сложные алгоритмы". Потом конечно берем кувалду и начинаем выкручиваться из ситуации куда сами и залезли. Обычное дело . Подходим к делу не удивили.
И вообще в описанном Вами случае собственно вложенности-то и нет - есть очевидная разбивка ранее не продуманного обработчика прерывания на собственно обработчик прерывания и псевдопроцесс продолжения обработки. Собственно чем и доказали, что без вложенные обработчики без надобности, если думать системно - поздравляю!

[GetSmart]

...на собственно обработчик прерывания и псевдопроцесс продолжения обработки

Я извиняюсь, но что такое "псевдопроцесс продолжения обработки" ?
Нельзя ли то же самое, но сформулировать конкретней?

[zltigo]

Нельзя ли то же самое, но сформулировать конкретней?

Можно. Уберите приставку 'псевдо'. Останется процесс обработки. Все в терминах операционных систем. Вы просто организовали процесс НЕ средствами операционной системы, по этой причине я и назвал его 'псевдопроцесс'. Но суть осталась - вложенного прерывания нет - произведена оптимизация обработчика FIQ прерывания и часть его вынесена из этого обработчика. Так и надо строить системы БЕЗ вложенных прерываний.

[GetSmart]

Можно. Уберите приставку 'псевдо'. Останется процесс обработки. Все в терминах операционных систем. Вы просто организовали процесс НЕ средствами операционной системы, по этой причине я и назвал его 'псевдопроцесс'. Но суть осталась - вложенного прерывания нет - произведена оптимизация обработчика FIQ прерывания и часть его вынесена из этого обработчика. Так и надо строить системы БЕЗ вложенных прерываний.

Проспался, и понял о чём речь. В FIQ ADC нужно по-быстрому скидывать данные в кольцевой (например, ну или в два обычных) буфер. И по-быстрому выходить из FIQ. Далее высокоприоритетный тред будет анализировать указатели RD + WR для буфера и обрабатывть новые поступившие данные. Хорошо. Это простой, классический, но не самый эффективный алгоритм. По сравнению с моим имеет множество недостатков и ни одного достоинства ИМХО.
Список недостатков:
1. Нет вложенности FIQ (казалось бы бонус), из-за чего латентность FIQ DAC уменьшается, а джиттер увеличивается почти в 2 раза, т.к. нет разрешения FIQов по середине обработчика (при вложенных есть).
2. Требуется буфер в раме размером на максимально возможный интервал работы других тредов, пока управление не вернётся к треду, разгребающему буфер. Пускай даже я соглашусь на тормознутую реакцию на событие, но буфер в раме требуется немалый.
3. Кол-во вычислений над оцифрованными данными будет одинаковое, но без nested FIQ будет лишнее сохранение/ восстановление данных в буфере. Плюс очень (черезмерно?) частый анализ RD WR указателей. То есть очевидна пустая трата процессорного времени тогда, когда её можно избежать.
4. Во время воспроизведения WAV у меня тормозятся именно треды (у них может упасть производительность в 4 раза например) и не тормозится ни одного важного прерывания, вот в чём фишка! А если тормозятся треды, то и тот приоритетный тред, который разгребает данные от АЦП тоже затормозится и либо потеряет данные, либо буфер ему потребуется в 4 раза больший.

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

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

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

А теперь я расскажу историю до вчерашнего дня. Есть заказчик. У него был девайс, который что-то заложенное в нём умел делать. Появился я, и первым делом поднял производительность АЦП в 3..5 раз, плюс стабильность частоты и джиттера и прочие бонусы. Затем возник вопрос - а можно ли ещё сделать это... И когда я сделал в параллель ко всему, что девайс умеет ещё и качественное воспроизведение WAV абсолютно не задев тайм-критичные характеристики пробора, то у заказчика просто челюсть отпала. Как я уже указывал, воспроизведение WAV тормозит только треды, и ни одного важного прерывания или события. И всё это требует рамы меньше, чем в любом другом варианте реализации алгоритма. И соответственно выдаёт больше производительности в каких-нибуть у.е. вычислений (например допустимая частота сигналов АЦП) по сравнению с другим вариантом реализации при одинаковой тактовой процессора.