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

[GetSmart]

Взято из другой темы

А кто нибудь посчитал расходы на вложенные прерывания - именно для ARM7 ? IMHO если убрать весь этот оверхед - окажется что вложенных прерываний и не надо .
Если уж обработчик такой тяжелый что жрет много времени - не проще ли перекинуть большую его часть на обычный уровень!
А для совсем критических вещей есть же FIQ - два уровня IRQ, FIQ вполне достаточно.

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

Ещё из другой темы

Вложенные прерывания - гениальная весчь в умелых руках. Не надо ля-ля
А вложенные софтовые прерывания - вообще наше всё!

Нет В 99% тяжелая кувалда используемая неумелыми руками во исполнение принципа "а чего-тут думать - трясти вкладывать надо"

------------
Маленькая поправка первого поста. Синуса 48000 ==> следует читать Синуса 750 Гц при сэмплировании (FIQом) 48000.

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

[zltigo]

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

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

[VslavX]

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

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

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

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

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

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

[defunct]

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

В новых LPC по прежнему нет DMA для АЦП?!

[GetSmart]

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

Поражаюсь чьей-то глупости необъективности.
А теперь пожалуйста конкретней - что значит "ранее не продуманного обработчика" ?
Заранее предупреждаю. Разделение алгоритма на IRQ/FIQ/треды проектировал лично я. Могу обосновать каждую песчинку алгоритма. С Вашей стороны пока вижу только пространственные сравнения и никакой конкретики. Если я пишу "было нельзя" значит было нельзя весить на IRQ. IRQ внутри FreeRTOS не обеспечивает необходимой латентности для оцифровки нужных сигналов. Причём тут постулаты? Ни откуда я не "выкручивался". Может я не знаю более "гениального" решения? Подскажите. Посмотрим.

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

48 КГц моно для качественного воспроизведения звуковых файлов на одном динамике. 8кГц 8 бит - ховно и прошлый век. Принудительно делать 8кГц 8 бит в системе, которая способна воспроизводить 48 КГц удел слабаков.

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

[defunct]

Разделение алгоритма на IRQ/FIQ/треды проектировал лично я. Могу обосновать каждую песчинку алгоритма.

Обоснуйте необходимость вешать обработчик ADC на FIQ.

[GetSmart]

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

Сложный, не значит долгий. Сложный - это сложный, долгий - это долгий. Если посмотрите на осциллограмму, то увидите, что в FIQ АЦП прога висит по-разному, но максимум 40 мкс. Это не много для прерываний вообще, но много для FIQ DAC, что явилось объективной причиной для реализации вложенности. Переносить алгоритм в тред = затормозить его (алгоритм) или проц (все другие алгоритмы) на порядок. Либо отнять ещё лишнюю память для буферов, увеличить размер кода и прочее. В моей реализации процессор не делает ничего лишнего, чего не надо делать. Это как два варианта - 1. в нужный момент вызвать софтовое прерывание и 2. в треде максимального приоритета тупо поллить флаг, ожидая когда же он установится, тратя напрасно процессорное время.

Обоснуйте необходимость вешать обработчик ADC на FIQ.

Чтобы переключения контекстов FreeRTOS и критические секции не вызывали пауз в оцифровке сигналов (а там 14 каналов) и по возможности иметь минимально возможный джиттер.

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

[defunct]

Чтобы переключения контекстов FreeRTOS и критические секции не вызывали пауз в оцифровке сигналов (а там 14 каналов) и по возможности иметь минимально возможный джиттер.

Т.е. DMA для ADC в LPC23xx нет. Тогда обоснуйте выбор камня.
SAM7 с DMA для ADC полностью избавил бы Вас от джиттера, и от необходимости работы с железом ADC после инициализации вообще, сделал бы возможным обрабатывать данные с АЦП в самой низкоприоритетной задаче вашего RTOS'а.

[GetSmart]

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

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

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

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

[defunct]

Зачем мне заведомо проигрышное по производительности и ресурсоёмкости решение? Никак не могу понять,

А с чего вы взяли что оно по производительности более проигрышное и ресурсоемкое?
У меня к примеру на SAM7X (частота меньше, нет LPCшного MAM - отсюда thumb код, нет peripheral FIFO как в LPC у всего кроме EMAC ) делается тоже что и у вас только вывод 44.1kHz не моно, а стерео (DAC на PWM)... АЦП шлепает себе с нулевым джиттером на 44.1ksps на канал, по данным с АЦП считается fft в реалтайм, накладываются фильтры... Есть еще ethernet и fs... ну и там 232-й, 485-й, часики и прочая мелочь.
~50% ресурсов проца свободно, вложенными прерываниями там и не пахнет.

[GetSmart]

А с чего вы взяли что оно по производительности более проигрышное и ресурсоемкое?

Потому, что в LPC23xx АЦП не подключён к DMA. И реализовать свой алгоритм вы не сможете. И аргумент ваш мимо кассы. Моя оценка была не вашему алгоритму/девайсу, а предложенному VslavX. Если сделать именно так, как он указал на LPC2368, то будет именно так, как я оценил. Поэтому приводить алгоритм, реализованный на другом камне в той ситуации, в которой я работаю не вижу разумного смысла.

АЦП шлепает себе с нулевым джиттером на 44.1ksps на канал

Сколько там возможно разных каналов от АЦП скидывать в DMA? У меня снаружи проца стоит ещё мультиплексор. Внутри FIQа приходится ещё менять адрес на нём.

[VslavX]

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

Сильное заявление. После него даже и отвечать как-то неудобно...

[GetSmart]

Сильное заявление. После него даже и отвечать как-то неудобно...

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

[defunct]

Сколько там возможно разных каналов от АЦП скидывать в DMA? У меня снаружи проца стоит ещё мультиплексор. Внутри FIQа приходится ещё менять адрес на нём.

Все имеющиеся, а имеется 8. DMA поочереди читает данные с enabled каналов.

[GetSmart]

Все имеющиеся, а имеется 8. DMA поочереди читает данные с enabled каналов.

Отлично. Даже SAM ситуацию не спасёт. Остаётся единственно правильное решение

[defunct]

Отлично. Даже SAM ситуацию не спасёт. Остаётся единственно правильное решение

"Ну помогай Вам Бох" © Никифоровна
Мультиплексор внешний поставили, а счетчик внешний для автоматической смены адреса по пульсу таймера который тактирует АЦП слабо поставить?

[zltigo]

Поражаюсь чьей-то глупости необъективности.

Это я произнесено, как я понимаю, исключительно по той причине, что на, повторяю:

....в описанном Вами случае собственно вложенности-то и нет - есть очевидная разбивка (skip) обработчика прерывания на собственно обработчик прерывания и псевдопроцесс продолжения обработки.

ответить-то по существу и нечего.

[GetSmart]

Мультиплексор внешний поставили, а счетчик внешний для автоматической смены адреса по пульсу таймера который тактирует АЦП слабо поставить?

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

[singlskv]

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

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

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

[GetSmart]

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

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

[zltigo]

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

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

[GetSmart]

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

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

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

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

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

[defunct]

Не поверите, но у каналов есть ещё приоритеты опроса и они опрашиваются совсем не по порядку.

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

Что такое умеет делать ОС применительно к моему случаю о чём я не знаю?

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

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

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

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

[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

[singlskv]

Именно так.

Понятно, то есть необходимы 3 уровня старшинства прерываний
IRQ, FIQ с разрешенным "Fast" FIQ и сам "Fast" FIQ
тогда наверное вложенные прерывания необходимы

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

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

хотя с другой стороны, кто Вам мешает рассчет перенести не в тред а в SoftIRQ ?
и иметь просто FIQ с двумя короткими ветками
или так тоже будет недостаточно оперативно ?

З.Ы. Если SoftInt слишком медленно, можно и какое-нить переферийное с максимальным приоритетом взводить...
прямо из FIQ АЦП

[defunct]

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

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

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

Код

туда
mov    r0, sp
ldr    sp, =const
stmia  sp!, {r0 ...}

и назад
ldmia  sp!, {r0 ...}
mov    sp, r0

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

[GetSmart]

хотя с другой стороны, кто Вам мешает рассчет перенести не в тред а в SoftIRQ ?
и иметь просто FIQ с двумя короткими ветками
или так тоже будет недостаточно оперативно ?

З.Ы. Если SoftInt слишком медленно, можно и какое-нить переферийное с максимальным приоритетом взводить...
прямо из FIQ АЦП

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

[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(), а дальше пока не отследил. Теряюсь в догадках - почему?

[zltigo]

Любой другой exception не вызывается из FIQ, не говорите глупостей.

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

применительно к моей проге.

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

[GetSmart]

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

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

[yuri_t]

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

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

[GetSmart]

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

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

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

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

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

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

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

[zltigo]

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

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

[GetSmart]

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

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

[zltigo]

Щас придумал...

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

[yuri_t]

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

Dear GetSmart !

-во-первых:

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

- во-вторых:

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

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

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

[VslavX]

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

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

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

Он прерывает все другие треды, но не мешает прерываниям.

Именно

Когда тред полностью выполнил алгоритм, то он самоликвидируется И больше не тратит процессорного времени до очередного события.

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

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

[KRS]

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

[singlskv]

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

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

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

[defunct]

Если посчитать все накладные расходы на переключение режимов то джиттер скорее всего будет примерно одинаков.

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

[singlskv]

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

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

[defunct]

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

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

[GetSmart]

__asm{ swi ADC_HandlerId }

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

[defunct]

SWI используется FreeRTOSом. Так просто (без накладных раскодов) скорее всего не получится.

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

Проще может получиться применить "Undef Instruction" для "влёта" в исключение.

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

Кроме того, при "влёте" флаг FIQ наследуется из текущего режима, его нельзя предустановить.

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

[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

[GetSmart]

__asm{ swi ADC_HandlerId }

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

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

[VslavX]

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

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

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

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

[GetSmart]

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

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

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

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

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

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

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

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

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

[zltigo]

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

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

[VslavX]

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

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

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

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

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

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

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

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

[Rst7]

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

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

Код

extern volatile unsigned short DAC_REG;
struct{
  unsigned long long wav_point;
  unsigned long long wav_delta;
};

voidPlayWAVsample(void)
{
  unsigned long long p=wav_point;
  p+=wav_delta;
  wav_point=p;
  DAC_REG=*((unsigned short *)(unsigned int)(p>>32));
}

CODE

// 75 voidPlayWAVsample(void)
// 76 {
voidPlayWAVsample:
PUSH {R4,R5}
// 77 unsigned long long p=wav_point;
// 78 p+=wav_delta;
// 79 wav_point=p;
LDR R2,??voidPlayWAVsample_0 ;; _A_wav_point
LDM R2,{R0,R1}
LDR R4,[R2, #+8]
LDR R5,[R2, #+12]
ADDS R0,R0,R4
ADC R1,R1,R5
STM R2,{R0,R1}
// 80 DAC_REG=*((unsigned short *)(unsigned int)(p>>32));
LDRH R0,[R1, #+0]
LDR R1,??voidPlayWAVsample_0+0x4 ;; DAC_REG
STRH R0,[R1, #+0]
// 81 }
POP {R4,R5}
BX LR ;; return
DATA
??voidPlayWAVsample_0:
DC32 _A_wav_point
DC32 DAC_REG

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

[GetSmart]

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

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

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

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

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

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

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

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

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

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

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

[zltigo]

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

Не менее странно слышать о "безосной (без операционной СИСТEМЫ!!! ) проге". Не обязательно иметь на любом контроллере операционные системы уровня uC/OS и иже с ней, но СИСТЕМНЫЙ подход должен быть, задачи прежде всего ставится терминах операционных систем и соответственно решаться, хотя собсвенно готовая универсальная система может и близко не присутствовать. Ну а если системного подхода нет, то тогда конечно "Но только в безоснойсистемной проге начинаешь по-настоящему уважать (да,да!) вложенные прерывания." Слегка уточнив в цитате буквально полслова получаем фразу с которой я абсолютно согласен . В таком случае без них действительно труба дело - думать уже нечего - "трясти надо".

[VslavX]

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

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

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

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

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

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

[zltigo]

....проверить где и как ОСь работает в SVC режиме.

FreeRTOS всегда и везде работает в SVC, естественно, кроме exception.

FreeRTOS использует стек SVC только до старта тредов, а дальше он пропадает без дела. И было бы разумно задействовать его для вложенных прерываний.

Соответственно стеков много - для каждой из задач, а "первоначальном" стеке лично у меня продолжает жить самая главная и обязательная задача 'IDLE', которая создается у меня ПЕРВОЙ, а не последней, как в оригинальной реализации FreeRTOS, ибо если ее создавать последней, то при недостатке памяти она не создастся и рухнет все. Стеки для разных режимов могут быть и объединены - у меня Abort и Undef обычно работают на одном стеке - они короткие, прозрачные и я имею уверенность, что перекрестных excеptions не будет. За одно эта область используется в качестве буфера IAP. Режимиа System/User нет вообще - указатель стека на эту-же область.

[GetSmart]

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

Я так и не понял, что это такое. Но догадываюсь, что DAC_REG это порт ЦАПа со значением на его выходе.
На ресемплинг не похоже

[GetSmart]

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

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

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

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

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

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

[Rst7]

На ресемплинг не похоже

Он и есть, только без фильтрации. В delta необходимо занести соотношение частот в формате 32.32, в point в старшие 32 бита положить указатель на семплы. Правда, немного я погорячился с short, код в таком виде нормально работает только с байтами, для слов необходим небольшой костыль -сброс младшего бита, ну это плюс один такт.

[VslavX]

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

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

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

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

[GetSmart]

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

16 в 1.

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

Дык музон и на 8 битах шикарно смотрится В том плане, что на максимальной громкости всё пучком. А вот динамический диапазон да, небольшой. Там вообще планируется аналоговая регулировка громкости прямо в подключаемом усилителе.

А колонка хорошая. Советская, с "подушкой" внутри.

[zltigo]

Дык музон и на 8 битах шикарно смотрится

К делу, конечно не относится, но 8bit музыку не заметит только глухой от рождения. Проверено в молодости и многие еще наверное помнят слово Covox. Недавно в речевом канале попытался поймать заказчика, правда искушенного, на слепом тесте отличиить 13bit от 16bit. Отличил и меня научил - шипяшие звуки имеют явно другую окраску. Что касается полосы, то львиная доля 2-3 дюймовых матюгальничков даже официально до 5KHz разве только дотягивает. Реально и этого нет. Те которые тянут больше стоят от 10 и выше баксов за штуку. Из них прилично звучащий стоил 15 и по чувствительности проигрывал массовке порядка 10dB.

[GetSmart]

Ладно, ладно, приврал На 8-битных WAV квантование слышно когда громкость звука спадает. Но музон я вообще ради прикола гонял. Это не плейер. Так, впечатление произвести на заказчика

К делу, конечно не относится, но 8bit музыку не заметит только глухой от рождения.

Особенно в наушниках. Но это к моему девайсу не относится.

[VslavX]

16 в 1.

То есть Ваши 14 каналов заведены на один вход ADC? Частоты дискретизации по-канально какие? Запуск таки от таймера или софтовый? Пока проблем особых не видно - сработал таймер, запустил АЦП, тот отработал, выдал прерывание, забрали результат, сохранили, например в кольцевом буфере и настроили внешний мукс на следующий канал. Где сложности? Если минимальный период дискретизации меньше чем "время обработки" + "max IRQ latency", то "это залет, воин" © - грубый просчет при проектировании системы.

[GetSmart]

То есть Ваши 14 каналов заведены на один вход ADC? Частоты дискретизации по-канально какие? Запуск таки от таймера или софтовый? Пока проблем особых не видно - сработал таймер, запустил АЦП, тот отработал, выдал прерывание, забрали результат, сохранили, например в кольцевом буфере и настроили внешний мукс на следующий канал. Где сложности? Если минимальный период дискретизации меньше чем "время обработки" + "max IRQ latency", то "это залет, воин" © - грубый просчет при проектировании системы.

"Не портите мне систему, пока она работает" ©

[VslavX]

"Не портите мне систему, пока она работает" ©

Ну и? Конкретные ответы-то на поставленные вопросы будут? Или "алгоритм ну очень сложный"?

[GetSmart]

... то "это залет, воин" © - грубый просчет при проектировании системы.

Меня вот эта фраза пугает. Я боюсь её передавать заказчику. Может уволить

Тем более внутри FreeRTOS я точно не знаю чему равна "max IRQ latency"

...В итоге имеем невразумительный свитч на входе в FIQ обработчик, и рассказы про борьбу против оверхеда.

Да нет там оверхеда, несколько лишних тактов (чтение T2IR + 1) на сэмпл ЦАП - это ерунда. Там по-любому нужно сбрасывать флаги в T2IR.

По сравнению с IRQ вариантом - это ничто.

И вообще, у меня щас дела посерьёзней. Я походу баг ядра нашёл. Дубль 2 Только лень его трассировать и исследовать. Жаль за это деньги не платят.

[VslavX]

Меня вот эта фраза пугает. Я боюсь её передавать заказчику. Может уволить

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

[GetSmart]

Почувствовав запах крови...он перешёл в наступление
VslavX, Подтвердите сперва свои слова цитатами, только с учётом хронологии чужих постов и моих ответов.

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

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

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

А я обязательно отвечу на "конкретные" вопросы.
К слову, вспомнилась пестня "А ты в ответ: Я все отдам. Мадам, мадам. Падабадабадабадам..."

Лучше отгадайте загадку: программно переключаюсь из текущего режима FIQ с запрещёнными IRQ+FIQ в режим IRQ с запрещёнными IRQ и сразу улетаю на вектор 0x18 (IRQ vector). В чём причина?

[VslavX]

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

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

А я обязательно отвечу на "конкретные" вопросы.

Ото когда (и если) ответите, тады и поговорим - с цифрами "на руках".

BTW, а почему у Вас 24МГц тактовая ядра? Если используется ОС, то тактовую можно спокойно повысить до максимума. ОС очень легко позволяет реализовать энергосбережение - останавливая ядро в потоке IDLE. При этом проц всегда возьмет "сколько ему надо" в момент пиковой загрузки (теми же прерываниями) , а суммарное потребление возрастет очень незначительно.

[GetSmart]

Лучше отгадайте загадку: программно переключаюсь из текущего режима FIQ с запрещёнными IRQ+FIQ в режим IRQ с запрещёнными IRQ и сразу улетаю на вектор 0x18 (IRQ vector). В чём причина?

Вопрос решён в соседней ветке

Не будь я таким заядлым экспериментатором - никто бы так и не узнал о баге во FreeRTOS
Rst7-у респект.

VslavX, что такое BTW ?

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

[Petka]

VslavX, что такое BTW ?

By The Way = "вдогонку", "кстати", "между прочим"

[zltigo]

Не будь я таким заядлым экспериментатором - никто бы так и не узнал о баге во FreeRTOS

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

[GetSmart]

а почему у Вас 24МГц тактовая ядра? Если используется ОС, то тактовую можно спокойно повысить до максимума. ОС очень легко позволяет реализовать энергосбережение - останавливая ядро в потоке IDLE. При этом проц всегда возьмет "сколько ему надо" в момент пиковой загрузки (теми же прерываниями) , а суммарное потребление возрастет очень незначительно.

Про этот механизм я даже не знал. Я со FreeRTOSом познакомился всего пару месяцев назад. То есть при входе в прерывание проц автоматически "разгонется" без лишних задержек или эта фича всё таки создаёт лишние задержки?

И если не трудно, то хотелось бы узнать - как во FreeRTOS сделать аналог моего вложенного IRQ, то есть треда, который активизируется по событию из FIQ и прерывает все другие треды.

[VslavX]

Про этот механизм я даже не знал. Я со FreeRTOSом познакомился всего пару месяцев назад. То есть при входе в прерывание проц автоматически "разгонется" без лишних задержек или эта фича всё таки создаёт лишние задержки?

Смотреть документ "LPC23XX User manual", глава "Chapter 4: LPC23XX Clocking and power control", пункт "8.1 Idle mode".
Не знаю как там конкретно во FreeRTOS (сам я на TNKernel сижу), но там тоже должна быть задача "IDLE" - которую процессор исполняет "когда ему нечего исполнять". Вот в ней и ставите примерно такой код

Код

for(;;)  
{
   enable_interrupt();
  SC_PCON = bPCON_PM0;
}

Насчет увеличения latency_interrupt я в документации ничего не нашел, но, даже если и ядром добавляется пару тактов для выхода из IDLE, то это многократно скомпенсируется утроившейся частотой, и окончательный lanency в наносекундах будет втрое меньше.

[zltigo]

enable_interrupt();

Это явный перебор - idle c запрещенными прерываниями не бывает. Посему, ровно одна строчка...

[VslavX]

Это явный перебор - idle c запрещенными прерываниями не бывает. Посему, ровно одна строчка...

Это если система нормальная, а если ее GetSmart щаз адаптирует под себя..
Согласен, у меня под TN такой строчки нет, это я при написании поста перестраховался

[zltigo]

И если не трудно, то хотелось бы узнать - как во FreeRTOS сделать аналог моего вложенного IRQ, то есть треда, который активизируется по событию из FIQ и прерывает все другие треды.

Если чисто-тупо, то обертка с сохранением контекста и соответственно в обработчике FIQ поднятие задачи xTaskResumeFromISR() и yield()
Добавление обертки лично мне сильно не по душе, по той-же причине (тупо входим-выходим, но пользуемся редко), что и обертки для организации вложенности. Посему обертку херим, а yield() из обернутого обработчика IRQ активируемого из FIQ. Тут Вам коллеги подобное несколько раз подробно описывали. Естественно, шедулер во FreeRTOS прдвинутый и за это платится тактами. Посему, то о чем говорил я - для всемерного ускорения можете всю свою дополнительную работу прямо в обработчике IRQ написать не трогая системные сервисы вообще.

[GetSmart]

..для всемерного ускорения можете всю свою дополнительную работу прямо в обработчике IRQ написать не трогая системные сервисы вообще.

Вложенном?

[zltigo]

Вложенном?

??? Разумеется нет. Незачем. Маньяк прямо какой-то везде вложенные прерывания мерещатся.

[GetSmart]

..для всемерного ускорения можете всю свою дополнительную работу прямо в обработчике IRQ написать не трогая системные сервисы вообще.

Я чё-та не пойму. Какую тогда дополнительную работу? Подгрузку файла?

[zltigo]

Я чё-та не пойму. Какую тогда дополнительную работу?

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

[GetSmart]

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

Ну теперь понятно, что Вы отвечаете не на тот вопрос, который я задал. Я спрашивал

И если не трудно, то хотелось бы узнать - как во FreeRTOS сделать аналог моего вложенного IRQ, то есть треда, который активизируется по событию из FIQ и прерывает все другие треды.

То есть как быстро вызвать тред подгрузки файла. Событие - вывод последнего сэмпла в буфере. Вот именно этот псевдотред я бы согласился сделать честным тредом, т.к. там есть кое-что от чего пришлось отказаться сидя в прерывании.
Про то, как перенести псевдотред вложенного FIQ на уровень SoftIRQ уже 10 раз слышал, до этого сам прорабатывал и в итоге отказался. Этот вопрос можно пока не тревожить.

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

[zltigo]

Ну теперь понятно...

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

до этого сам прорабатывал ...

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

[GetSmart]

К слову.
Допустим кто-то поймёт, что вложенные прерывания делать "нельзя". И сразу станет глупее ARM Limited Которые уже аппаратно заложили в процы вложенные прерывания. Не для баловства ессно.

Сообщение отредактировал GetSmart - Jun 28 2010, 20:26

[zltigo]

Не для баловства ессно.

На самом деле это простейшее лобовое решение - пихай тупо в стек пару регистров и иди куда послали. Уже первые интеловские процессоры 8080...8086 в комплекте с 8259 были такими-же "умными". Кортексики "M", на которые Вы, как я понимаю, намекаете,они такие и есть - простые, но мускулистые убивцы восьмибитовиков. Берем старшие Cortex-A и.... ой, а куда делся такой "продвинутый" контроллер от младшеньких? Опять FIQ, IRQ..... Контроллеры по жизни предназначенные под операционки "обходятся" и без столь "полезных" вложенных прерываний.

[GetSmart]

На самом деле это простейшее лобовое решение - пихай тупо в стек пару регистров и иди куда послали. Уже первые интеловские процессоры 8080...8086 в комплекте с 8259 были такими-же "умными".

Дык тем более. Раз техническое решение, придуманное ещё на заре микропроцессоров было реализовано в очередной версии АРМов, причём в предыдущих версиях проца эту фичу приходилось делать "ручками", то это однозначно значит, что фича настолько полезная, что настало время её сделать аппаратной.

Смешно слушать "гуру", твердящих об обратном.

Сообщение отредактировал GetSmart - Jun 28 2010, 21:03

[zltigo]

Смешно слушать "гуру", твердящих об обратном.

Животик со смеху не повредите . А то я буду искренне скучать

[singlskv]

Дык тем более. Раз техническое решение, придуманное ещё на заре микропроцессоров было реализовано в очередной версии АРМов, причём в предыдущих версиях проца эту фичу приходилось делать "ручками", то это однозначно значит, что фича настолько полезная, что настало время её сделать аппаратной.

Продуманная фича это банки регистров на все уровни прерываний(например 16 штук),
то есть 16 уровней прерываний = 16 банков регистров.
И вот тут делай уже что хочешь...

[GetSmart]

Продуманная фича это банки регистров на все уровни прерываний(например 16 штук),

ИМХО такую фичу АРМовцы сделали бы, если бы она была ненакладна. Раз не сделали, значит она неоптимальна/вредна с какой-то стороны.

Берем старшие Cortex-A и.... ой, а куда делся такой "продвинутый" контроллер от младшеньких? Опять FIQ, IRQ..... Контроллеры по жизни предназначенные под операционки "обходятся" и без столь "полезных" вложенных прерываний.

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

Сообщение отредактировал GetSmart - Jun 28 2010, 22:31

[singlskv]

ИМХО такую фичу АРМовцы сделали бы, если бы она была ненакладна. Раз не сделали, значит она неоптимальна/вредна с какой-то стороны.

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