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

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

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

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

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

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


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

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

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


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

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

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


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


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


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


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

Пост #5

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



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


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

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

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

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


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

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


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


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

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


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

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

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


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


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


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

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

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




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

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

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


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


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


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

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

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

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


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


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

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

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

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

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


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



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

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

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

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

16 в 1.


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

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

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

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


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

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

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

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

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

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


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

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

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

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

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

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


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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вложенном?

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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