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

Из конструктивной критики Вашего решения могу сказать только:
вместо Undef mode определенно лучше использовать SVC (и быстрее переключение, и адекватный обработчик undef abort'а в системе останется), конфликт с ОС, которая наверняка использует SVC для своих нужд, решается подменой SWI вектора переходом на обработчик АЦП перед вызовом SWI, и его восстановлением после окончания обработки. Если треды тоже работают в SVC тогда можно и стек вручную переключить не так и накладно:



а если нет, тогда вообще никаких проблем - просто увеличте SVC стек в стартапе.

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

Проспался, и понял о чём речь. В 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 тормозит только треды, и ни одного важного прерывания или события. И всё это требует рамы меньше, чем в любом другом варианте реализации алгоритма. И соответственно выдаёт больше производительности в каких-нибуть у.е. вычислений (например допустимая частота сигналов АЦП) по сравнению с другим вариантом реализации при одинаковой тактовой процессора.

Это может быть и не задача операционной системы, а вернемся к приставке 'псевдо' задача - тот-же софтово взводимый обработчик IRQ с наивысшим приоритетом или любой другой exception. Что примерно Вы и сделали, только утверждаете, что это назывется "вложенные FIQ"

О чем я все время и говорю - вложенные прерывания в абсолютно подавляющеи большинстве случаев есть заплатка для плохо спроектированных систем. При этом причины по которым система спроектированы плохо значения не имеют. Причем проектирование системы и большинство системных проблем начинается с постановки задачи. В Вашем случае заказчик принес откуда-то какую-то железку и захотел всего больше в разы. И Вы это сделали ВСЕМИ ДОСТУПНЫМИ СРЕДСТВАМИ.

Любой другой exception не вызывается из FIQ, не говорите глупостей. Если же вызовется, то в нём все FIQи будут запрещены. По поводу софтового варианта уже ответил singlskv, что вариант однозначно хуже вложенных FIQ. Если Вы так не считаете, то укажите конкретные недостатки моего варианта (nested FIQ) и достоинства SoftIRQ применительно к моей проге.


Опять 25. Как это ещё назвать, если обёртка обработчика на 100% аналогична вложенным IRQ (за искл. разрешения FIQ, а не IRQ) ?

Вот кастрированная обёртка:


Я одну вещь понять не могу. Изначально я хотел чтобы вложенный FIQ работал на стеке IRQ с запрещёнными IRQ. Насколько я знаю архитектуру ARMа, так можно. Единственное ограничение - не влетать в текущий режим если в обработчике используется LR (когда прога на Си). Прямо в этой обёртке (при заходе во вложенный FIQ) меняю режим с 0x9b (Undef) на 0x92 (IRQ) и где-то (пока непонятно где) улетаю в Data Abort. То есть первый уровень вне аборта я вижу - в макросе portSAVE_CONTEXT(), а дальше пока не отследил. Теряюсь в догадках - почему?

Где Вы у меня видели "из"? Я писал "после". После КОРОТКОГО обработчика FIQ, если надо продолжить что-то делать без привлечения задачи операционной системы и без затрат времени на переключения контекста операционной системой.

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

Exception (за искл. FIQ и IRQ) можно вызвать только "из", а не "после". Поэтому остаётся только SoftIRQ без вариантов.

Полностью согласен.

В начале топа Вы пытались меня критиковать даже без знания каких-либо нюансов алгоритма. Давайте продолжим. Я уже много подробностей рассказал. Даже готов согласиться на ооочень тормознутую реакцию на сигнал от АЦП. Только расскажите какие конкретно приемущества мне сулит отказ от вложенных FIQ ?


Ну я же только что привёл прекрасный наглядный пример использования софтового IRQ для подгрузки данных при проигрывании файлов. Такие характеристики, которые он обеспечивает не достичь никаких другим способом. Или у Вас есть другие решения?


Ага. Будда лучше всех
Конкретные примеры в студию.

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

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

Щас придумал идеальную аналогию в понятиях ОС для определения вложенных прерываний. Это как "на лету" создающийся тред максимального приоритета именно в момент когда он понадобился. Он прерывает все другие треды, но не мешает прерываниям. Вложенными делают обычно тяжёлые прерывания. Этот признак делает аналогию ещё более точной. Когда тред полностью выполнил алгоритм, то он самоликвидируется И больше не тратит процессорного времени до очередного события.

Об этом я самого начала и говорю, начиная с поста №5 если перечитаете . Теперь Вы четко поставили задачу. Для ее решения "вкладывать прерывания" совершенно не обязательно. Как и проектировать "тяжелые прерывания"

Dear GetSmart !

-во-первых:

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

- во-вторых:

Не стоит, даже в пылу полемики, заявлять:

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

Поверте, эти "вышеотписавшиеся" понимают "все хитрости ядра" намного лучше нас с Baми...

"Лучше поздно, чем никогда"

Создавать "когда понадобился" - это неоптимально по производительности - создание задачи выполняется относительно долго. А вот создать высокоприоритетный поток заранее и перевести его в ожидание некоторого события - самое оно. В прерывании сделать только самые-самые необходимые действия и активировать ожидаемое событие.


Именно


Немного не так - "засыпает" на новом ожидании события. И при этом точно так же не тратит ни такта процессорного времени. Создание/ликвидация более времязатратны и по ресурсам никакого выигрыша не дадут.

Вы будете удивлены, но маленькие ОСи переключают контекст очень быстро. Самая медленная из мной тестированных - uC/OS, со всеми наворотами (учет времени исполнения задачи, счетчик переключений контекста, вызов "рюшечных" колбеков) на SAM7S@48MHz (я думаю быстродействие LPC23@24 сравнимо) переключалась примерно за 14мкс - это полное время смены контекста, если выходить из прерывания - то это время располовиниться. То есть, задержка обработки данных по сравнению с моментом обработки в самом прерывании составит всего 7мкс - это менее 20 процентов от Ваших 40мкс. SCMrtos - в два раза быстрее, TNKernel тоже можно ускорить до этих цифр. Никто не говорит, что временнЫх издержек нет, они есть, но, как правило, незначительные, и эту цену часто стОит заплатить за архитектурную простоту и другие удобства.

А взяли бы уже достпуный Cortex-M3 ( LPC1768 вроде, кстати пнисовместимый с 2368) и получили бы аппаратные вложенные прерывания и pendsv - примерно то что у вас сейчас получилось.