Посвящается 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


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

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

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

Я полагаю(не видя конечно Вашей проги целиком) что вариант с взведением IRQ из FIQ ничем не хуже.
Если посчитать все накладные расходы на переключение режимов то джиттер скорее всего будет примерно одинаков.
Если посчитать общую загрузку проца, то мой вариант будет просто лучше т.к. издержки одного лишнего IRQ
будут существенно меньше чем расходы на все переключения режимов/контекстов.
Остается только скорость реакции на событие посчитанное по данным АЦП,
если так важна скорость то конечно нужно использовать не SoftIRQ а взводить высокоприоритетное переферийное,
ну и конечно не иметь слишком длинных других IRQ.

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

Считайте:
__asm{ swi ADC_HandlerId }

Не понял Вашей глубокой мысли...

На джиттер влияет только время пребывания в FIQ, поэтому расходы на переключение из любого режима обратно в FIQ не волнуют, т.к. на джиттер они не влияют.
А переключение из FIQ в SVC делается __одной__ приведенной выше командой, т.е. приведенное и есть __все__ накладные расходы на переключение режимов, влияющие на джиттер.
SVC режим можно заранее подготовить так как требуется для наименьшего джиттера - запретить в нем IRQ и разрешить FIQ.

SWI используется FreeRTOSом. Так просто (без накладных раскодов) скорее всего не получится. Проще может получиться применить "Undef Instruction" для "влёта" в исключение. Кроме того, при "влёте" флаг FIQ наследуется из текущего режима, его нельзя предустановить.

А то что я предложил выше читали? - подменить SWI вектор, вызвать SWI, затем воcстановить системный вектор.

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

Да действительно, это плохо, доп расходы...

О скорости реакции можете пока не думать. Я почти уверен, что все остальные показатели будут только хуже.

Прогу (а точнее обе обёртки Nested) я уже представил. Этого вполне достаточно чтобы посчитать джиттер и накладные расходы. Хочу уточнить, что на входе в nested FIQ стоит развилка, которая будет там стоять во всех вариантах, и даже в Вашем. А дальнейшие телодвижения для входа в nested FIQ (и освобождение уровня FIQ) занимают всего 7 тактов + 1 запись в VIC. Единственное, что я не продумал, а щас Вы косвенно предложили - это вариант когда в FIQ от АЦП вообще ничего не делается (даже АЦП не считывается), только взводится флаг SoftIRQ и сразу на выход. Он мог бы оказаться лучше. Но там затык в том, что нужно убрать FIQ активность от АЦП, чтобы на выходе из FIQ снова в него не влететь. То есть внутри FIQ АЦП нужно сделать VICIntEnClr = (1 << ADC0_INT) как у меня щас реализовано и ещё выставить флаг в VICSoftInt. При этом даже стек FIQ задействовать не нужно. Посчитал. Это может сработать, но только если запись слова в VIC занимает не более 2 тактов. (как в раму) В чём я очень сомневаюсь. Иначе джиттер будет больше. Накладные расходы тоже будут не меньше в SoftIRQ. У меня же щас реально ничего лишнего не делается. Если не согласны - пишите конкретно что, а то разговор беспредметный.

Всё окончательно взвесил. Нет. Вариант с SoftIRQ однозначно хуже. Потому, что при влёте в FIQ могут быть запрещены IRQ и при "перенаправлении" запроса на SoftIRQ оно может ещё долго не вызываться, пока тот, кто запретил IRQ вновь их не разрешит. А реальных бонусов этого варианта я не вижу.


Читал конечно. Только кто и когда будет "на лету" его подменять мне не понятно. Внутри FIQ он будет подменяться? Подмена вообще, не менее "грязное" действие, чем Undef. Этот вектор должен быть уже восстановлен в норму, когда управление вернётся на уровень тредов.

Сообщение отредактировал GetSmart - Nov 16 2009, 04:25

Да, внутри FIQ:
- Заходите в FIQ,
- определяете какой обработчик надо запустить;
- читаете текущий SWI вектор;
- прописываете ваш обработчик в SWI вектор;
- вызываете SWI (IRQ запрещены, ОС не может вызывать SWI);
- по окончанию обработки возвращаетесь в FIQ и восстанавливаете старый SWI вектор.
- возвращаетесь в user тред с восстановленным вектором.

По этой схеме можете не один АЦП обработчик откладывать, а сколько угодно.


В сравнении с Undef это нормальная практика, RTX для тяжелых процов (больше одного кора) постоянно колбасит SWI вектор в run-time. Не удивлюсь если и FreeRTOS тоже этим не брезгует. Но ОСы обитают на IRQ уровне, поэтому почему бы нам не воспользоваться тем же механизмом, на уровень выше.

Всё это "кривляние" заметно тормознутей простых вложенных FIQ (7 тактов + 1 запись в VIC). Действий для SWI потребуется больше. В чём смысл?

Там, где я выделил, будут запрещены FIQ & IRQ. Перед разрешением FIQ нужно будет сбросить запрос в VIC ( VICIntEnClr = (1 << ADC0_INT) ) и разрешить FIQ в CPSR. Только после этого будут доступны Fast FIQ.


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


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


Не поверю! Т.к. вышеотписавшиеся предлагали заведомо неэффективные решения. И некоторые из них постоянно тычут своей ДОГМОЙ всем в лицо. Когда ей тыкали других мне было всё равно. Но когда меня обвинили в косяке компилятора, который генерит неправильный эпилог nested, то это был уже перебор. И теперь я вышел на тропу войны
Прочитайте пость #4 и если Вы такой "корректный", то высскажете zltigo что он имеет право заявлять, а что нет.
Тыкание этой догмой мешает молодым умам думать и полноценно выбирать варианты, предоставленные ядром или системой. Возможно, в определённом возрасте уже не хочется совсем думать, но это личные дела кого-то.


Поздравляю, ловушка захлопнулась

Пост #5

0% объективности. Вложенные прерывания 100% есть и со 100% надобностью.



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


Отлично, что операционные системы дошли до минимума возможностей, на которые способны вложенные прерывания и само ядро ARM. Но делать так, всё равно что через заднепроходное отверстие. То есть я верю, что многие так делают, особенно когда речь идёт о мультиплатформенности. Хотя в большинстве случаев это делают из-за догмы или из-за сложности понимания всех процессов на уровне ядра/асма. Для мультиплатформенности и я бы так сделал. Но у меня не тот случай. Меня больше волнуют высокие конечные характеристики полученной системы. А ядро ARM и "вложенность" предоставляют программисту куда большие возможности с меньшим оверхедом. Кроме того, главный для меня критерий - я немного прог делаю под ОСью и не собираюсь к ней привязываться. И именно вложенные прерывания я могу одинаково использовать хоть с осью, хоть без неё. Можно провести ещё аналогию, что вложенные прерывания - это аналогичная фича, как реализованная в ОСи, но без самой ОСи, просто на уровне ядра.

Сообщение отредактировал GetSmart - Nov 16 2009, 05:57

Вариант 100% нерабочий.
Нельзя аппаратно залетать в режим, в котором уже могла работать прога. Иначе у неё затрутся SPSR и LR. В SVC может находиться прога, перед тем как её прервёт FIQ и если из FIQ она опять аппаратно переключится в SVC, то кердык. Когда я предлагал работать на стеке SVC, то я имел ввиду программное переключение в режим SVC. При программном переключении SPSR и LR не затираются. Для этого меняется буквально один байт в обёртке вложенных FIQ. Но опять же чтобы быть уверенным нужно перечитать порт LPC2300 и проверить где и как ОСь работает в SVC режиме. Насколько я поверхностно слышал в соседней ветке, FreeRTOS использует стек SVC только до старта тредов, а дальше он пропадает без дела. И было бы разумно задействовать его для вложенных прерываний.

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

Возможно у Вас и есть сложности с пониманием "всех процессов на уровне ядра/асма", а для большинства "вышеотписавшихся" - это уже пройденный этап. В период "до использования ОС" у меня получалось "поднимать" 2 проекта в месяц из продуктовой линейки. Я писал проекты примерно как Вы сейчас нам рассказываете - "очень круто, высочайшие характеристики, красота-то какая", но я больше ничего не успевал - была очередь плат на запуск и дополнительно "висели" запросы на доработки от прикладников - цейтнот хронический, мягко говоря. C переходом на ОС и выстраиванием портируемой архитектуры моя работа ускорилась в разы. Теперь отделы PCB и прикладники просто не успевают - цейтнот ушел к ним, а у меня появилось время для разработки полезных модулей типа RNDIS, например.


В-о-о-от. Работа ради работы. А меня больше волнуют _достаточные_ характеристики. Достигнутые за минимальное время и минимальные усилия. Один из самых существенных моментов экономии сил и времени - повторное использование кода. А финты, типа вложенных прерываний, это повторное использование усложняют.

Конкретно где? Демагогию не разводИте.


Что за ерунда. Один раз отшлифовал обёртки и пользуйся 100 раз без изменений. Ведь начинка "псевдотреда" не меняется, хоть в режиме вложенного прерывания, хоть в режиме треда. Какое и куда там тратится время разработки, пожалуйста поконкретней?


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

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


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

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

"Хотя в большинстве случаев это делают из-за догмы или из-за сложности понимания всех процессов на уровне ядра/асма". Это кто написал? А ничего сложного-то там и нету - давно уже все осознано, попробовано и отложено в сторону. Я сразу написал - использовать вложенные прерывания можно, догмы никакой нет. Но, имхо, архитектурно оптимальнее - вынести сложную обработку в тред, потом это будет проще отлаживать/модифицировать/портировать/поддерживать. Если Вы к этому выводу еще не пришли - Ваше право, больше ничем помочь не могу.


Это у Вас один простенький проект. Попробуйте стек IrDA до уровня IrCOMM без многопоточной ОС сделать. Я - делал, но особой гордости не испытываю - под ОС оно намного проще и красивей получилось бы. А потом перенести его с ARM на AVR, а потом на MSP. Вопросов нет - все делается, но какими силами.


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


Да критика в-общем-то не столько против вложенных прерываний, сколько против заявлений - "все чудаки, один я д'Артаньян".

Кто так строит, кто так строит? (ЦЭ)

Что стоило изменить частоту дискретизации WAV-файла (для приведения к частоте семплирования АЦП) на ходу (без всяких фильтров, все равно 99.9% людей никакой разницы не услышит). Стоило бы это копейки:




А вы тут начали ругань, наброс гуано на вентиляторы и фаллосометрию