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

[zltigo]

Далее высокоприоритетный тред будет

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

А теперь я расскажу историю до вчерашнего дня....

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

[GetSmart]

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

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

Что примерно Вы и сделали, только утверждаете, что это назывется "вложенные FIQ"

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

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

Код

#define NESTED_FIQ

void AdcIntr_Wrapper()
{
    asm("MOV    R8,#0xe0000000        \n\t"        // 0xE0070000 = T2IR
        "ORR    R8,#0x00070000        \n\t"
        "LDR    R9,[R8, #0]           \n\t"
        "ANDS   R9,R9,#0xff           \n\t"
        "BEQ    adc9                  \n\t"
        "STR    R9,[R8, #0]           \n\t"        // сбрасываю все флаги в T2IR
.... Вывод в DAC
        "SUBS   PC,LR,#4              \n\t"

#ifdef NESTED_FIQ
   "adc9:STMDB  SP!,{R0,LR}           \n\t"
        "MVN    LR,#~0xFFFFFF00       \n\t"
        "MOV    R0,#" STRINGFY(1 << ADC0_INT) "\n\t"
        "STR    R0,[LR,#0xFFFFF014-0xFFFFFF00] \n\t"    // VICIntEnClr = (1 << ADC0_INT);
        "MRS    R0,SPSR               \n\t"
        "MSR    CPSR_c,#0x9b          \n\t"        // Undef_Mode + Disable IRQ + Enable FIQ
        "STMDB  SP!,{R0-R3,R12,LR}    \n\t");
#else
   "adc9:STMDB  SP!,{R0-R3,LR}        \n\t");
#endif

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

#ifdef NESTED_FIQ
    asm("LDMIA  SP!,{R0-R3,R12,LR}    \n\t"
        "MSR    CPSR_c,#0xD1          \n\t"        // FIQ_Mode + Disable IRQ + Disable FIQ
        "MSR    SPSR_all,R0           \n\t"
        "MVN    LR,#~0xFFFFFF00       \n\t"
        "MOV    R0,#" STRINGFY(1 << ADC0_INT) "\n\t"
        "STR    R0,[LR,#0xFFFFF010-0xFFFFFF00] \n\t"    // VICIntEnable = (1 << ADC0_INT);
        "LDMIA  SP!,{R0,LR}           \n\t"
        "SUBS   PC,LR,#4              \n\t");
#else
    asm("LDMIA  SP!,{R0-R3,LR}        \n\t"        // эпиолог для FIQ
        "SUBS   PC,LR,#4              \n\t");
#endif
}

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

[singlskv]

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

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

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

[GetSmart]

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

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

Прогу (а точнее обе обёртки 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 вновь их не разрешит. А реальных бонусов этого варианта я не вижу.

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

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

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

[defunct]

Только кто и когда будет "на лету" его подменять мне не понятно. Внутри FIQ он будет подменяться?

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

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

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

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

[GetSmart]

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

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

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

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

Dear GetSmart !
-во-первых:
Вы сделали замечательный проект и нашли элегантное решение.

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

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

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

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

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

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

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

Пост #5

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

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

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

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

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

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

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

[VslavX]

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

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

Меня больше волнуют высокие конечные характеристики полученной системы.

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

[GetSmart]

Возможно у Вас и есть сложности с пониманием "всех процессов на уровне ядра/асма",

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

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

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

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

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

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

И если он дошёл до этой вершины, то респект ему и уважуха

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

[VslavX]

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

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

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

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

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

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

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

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

[GetSmart]

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

Это типа как "Я попробовал наркотик и отказался. Другим просто запрещаю пробовать"
Шютка. Все совпадения с действительностью вымышленные. Шютку немедленно забыть

Ключевое слово я выделил, остальное ИМХО ерунда.

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

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

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

Тут Вы неправы. Всё началось с "заявления" zltigo.

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

Нет, Вы сразу написали:

если уж понадобились вложенные прерывания, то в консерватории что-то не так - где-то "главный консерватор" провтыкал.

Даже не зная подробностей алгоритма.

[VslavX]

Ключевое слово я выделил, остальное ИМХО ерунда.

Это Вы просто с этой "ерундой" в по-настоящему сложных проектах не сталкивались. Когда этой "ерунды" становится достаточно много, мнение о ней меняется существенно.

Нет, Вы сразу написали:

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

Даже не зная подробностей алгоритма.

А какие тут подробности? Про минимизацию "джиттера" на DAC - принимается (с оговоркой что в 99% случаев 48кГц на линейных 10 битах оно нафиг никому не нужно), использовать FIQ для DAC - приемлемо, если уж не можем позволить нормальную аппаратуру. Но какого подвязывать этот же FIQ на ADC? Все равно ж реалтаймовым является только момент захвата - а он у Вас, скорее всего, стартует по таймеру, посмотреть/обработать результаты можно и позже, не обязательно в хендлере прерывания. В итоге имеем невразумительный свитч на входе в FIQ обработчик, и рассказы про борьбу против оверхеда. Ну, попробуйте убедить нас что без привязки ADC на FIQ - ну никак, пока это совсем неочевидно (мне, по крайней мере).

[GetSmart]

Ну, попробуйте убедить нас что без привязки ADC на FIQ - ну никак, пока это совсем неочевидно (мне, по крайней мере).

Внешний мультиплексор

...(с оговоркой что в 99% случаев 48кГц на линейных 10 битах оно нафиг никому не нужно)...

Я тестировал, да и вообще баловался. На 44100 музон гонял на хорошей колонке. Не отличить от того, что у меня из компа играет.

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

Как же мелко Вы скатились. Уже буквы в тексте подменяете, лишь бы смысл изменить "под себя"

[VslavX]

Внешний мультиплексор

И что? Какой именно мукс - сколько-во-сколько?

Я тестировал, да и вообще баловался. На 44100 музон гонял на хорошей колонке. Не отличить от того, что у меня из компа играет.

Шутите? Или у Вас настолько паршивенькие колонки? Отожралось минимум 30дБ диндиапазона от реальных 60дБ и никакой разницы? "Не верю" ©