Высшая степень вложенности 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

[_Pasha]

Звук (вывод в DAC) пришлось весить на FIQ

Если вывод по I2S, то почему не используете GPDMA? Или ЦАП не стандартный?

[GetSmart]

Если вывод по I2S, то почему не используете GPDMA? Или ЦАП не стандартный?

Вывод конкретно в DAC (периферия проца), а не в I2S. GPDMA не работает с DAC.

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

[VslavX]

Вывод конкретно в DAC (периферия проца), а не в I2S. GPDMA не работает с DAC.

Хм, мне не очень понятно зачем выводить 48кГц на 10-битный линейный DAC, да еще и моно. Обычно два класса звуковых приложений - или хотя бы минимальные стерео 48кГц/16 бит - типа простейших плееров, или уже моно 8кГц 8 бит - типа диспетчерских матюгальников/телефонной связи. Ну придумать применение моно/48кГц/10 бит конечно можно, но "ни рыба, ни мясо", ИМХО. Поставили бы уже дешевый I2S кодек, отдавали бы по GPDMA и никаких мучений.

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

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

Как мне видится решение Вашей задачи - выносится АЦП в приоритетный поток, а ЦАП - на прерывания, раз уж очень хочется и нету нормальной аппаратуры. А так как сделано сейчас - тут я согласен с zltigo - сами поставили себя в нечеловеческие условия, выкрутились и радуетесь. Замечательно, но потраченным усилиям можно только удивиться.

В-общем, я не против вложенных прерываний, все мои порты используемой TN-Kernel их поддерживают. Но, мое мнение - если уж понадобились вложенные прерывания, то в консерватории что-то не так - где-то "главный консерватор" провтыкал.

[GetSmart]

Как мне видится решение Вашей задачи - выносится АЦП в приоритетный поток, а ЦАП - на прерывания, раз уж очень хочется и нету нормальной аппаратуры. А так как сделано сейчас - тут я согласен с zltigo - сами поставили себя в нечеловеческие условия, выкрутились и радуетесь. Замечательно, но потраченным усилиям можно только удивиться.

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

Т.е. DMA для ADC в LPC23xx нет. Тогда обоснуйте выбор камня.

А кто сказал, что я девайс разрабатывал? Я разрабатывал только программу для готового девайса.
Только не делайте поспешного заявления о том, что девайс проектировал дилетант. Дело совсем не в девайсе. Дело в том, что реальный профессионал способен выжать из любого девайса 200% эффективности, тогда как пытающиеся выглядеть профессионалами будут выдавать работодателю заумные объяснения почему что-то там сделать нельзя. Вот здесь вот кодека не хватает. А любимый ход конём - а у вас процессор не той системы

[singlskv]

Решения с вложенными прерываниями имеют право на жисть, и Ваше не такое уж и плохое,
но ИМХО, оно применено в условиях когда и без него можно обойтись.
Вложенность нужна когда прерывания идут очень неравномерно, т.е. бывают ситуации что идет много
одновременно от разных источников и главное успеть зарегестрировать все(т.е. не пропустить ни одного),
ну и еще довольно быстро минимально реагировать.
У Вас же оба прерывания АЦП и ЦАП вполне себе переодичны.
Значит главное обеспечить маленький джитер вывода в ЦАП при работующем FIQ АЦП

Сложный, не значит долгий. Сложный - это сложный, долгий - это долгий. Если посмотрите на осциллограмму, то увидите, что в FIQ АЦП прога висит по-разному, но максимум 40 мкс. Это не много для прерываний вообще, но много для FIQ DAC, что явилось объективной причиной для реализации вложенности.

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

[GetSmart]

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

Сейчас средний джиттер 0.3 мкс (@24 MHz). Мне что, на каждые 10 тактов внутри FIQ вставлять проверку на флаг от таймера для DAC ? А Вы в курсе, что только чтение из T0IR занимает 8 тактов плюс ещё загрузка адреса T0IR ? У меня времени просто не останется собственно для чтения АЦП и действий над оцифрованными данными. Вот! Типичный случай из-за боязни вложенности предлагать заведомо неэффективное решение

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

Я не понимаю альтернативу. Предложите конкретный другой вариант. Что такое умеет делать ОС применительно к моему случаю о чём я не знаю?

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

[singlskv]

Сейчас средний джиттер 0.3 мкс (@24 MHz). Мне что, на каждые 10 тактов внутри FIQ вставлять проверку на флаг от таймера для DAC ? А Вы в курсе, что только чтение из T0IR занимает 8 тактов плюс ещё загрузка адреса T0IR ? У меня времени просто не останется собственно для чтения АЦП и действий над оцифрованными данными.

Вероятно я не до конца понял организацию Вашей вложенности FIQ
поэтому вопрос, FIQ ЦАП может прерываться FIQ АЦП ?

[defunct]

Вероятно я не до конца понял организацию Вашей вложенности FIQ
поэтому вопрос, FIQ ЦАП может прерываться FIQ АЦП ?

Нет, у него обработка АЦП прерывается ЦАПом.

[GetSmart]

Нет, у него обработка АЦП прерывается ЦАПом.

Именно так.

В этом наверное есть некий скрытый глубокий смысл, который я боюсь ниасилю.

Осилите Смысл только в увеличении пропускной частотной способности быстродействующих каналов при одинаковой загруженности проца (одинаковом кол-ве FIQs). Когда проц умеет аппаратно складывать значения из АЦП в раму, то можно смело оцифровывать все каналы по очереди. Правда есть минус - требуется буфер (два!), достаточно большой, чтобы тред успевал его выгребать. Но опять же, в девайсе нет никакого счётчика и опять (!) проц не той системы Поэтому заказчик/работодатель идёт в ж..у. Или я?

Я не понимаю, что мешает семплировать АЦП на одинаковой (или хотя бы кратной) частоте с ЦАПом, тогда будем иметь одно прерывание и порядок операций:

1. Вывести данные в ЦАП;
2. прочитать АЦП;
3. сменить канал;
4. записать рез-тат в приемный буфер.

Мешает заранее неизвестная частота сэмплирования в WAV файле, которая может оказаться совершенно некратной частоте сэмплирования следующего WAV файла. Во-вторых как я уже уточнил, длительнось расчётов некоторых каналов в FIQ АЦП достигает ~40 мкс. Неужели непонятно, что длительность отработки FIQ АЦП больше, чем период прерывания от ЦАП? Вашим алгоритмом можно обойти только джиттер, возникающий из-за вторичного короткого FIQа, но он бесполезен для вторичного длинного FIQа.

Опишите ваш случай вначале, а то получается разговор ни о чем.

Я не понимаю какое действие из трех перечисленных может занимать существенное время:
1. прочитать АЦП;
2. сменить канал;
3. записать результат в память.

Все три в купе @24Mhz должны занимать отсилы 1мкс.

Плюс пункт
4. расчёт оцифрованного быстродействующего канала для выявления искомого события. (40 мкс)

Повторюсь ещё раз. Этот расчёт нельзя переносить в тред, т.к. скорость реакции будет непредсказуемой или черезмерно большой.

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