Сталкивался ли кто-нибудь с прерываниями NVIC, не требующими вызова NVIC_ClearPendingIRQ() ?

Помнится, в начале своего знакомства с LPC176x не зная NVIC у меня прерывание таймера срабатывало в 2 раза чаще из-за отсутствия в его конце сброса пендинга. Пришлось принять за правило, ставить в конце всех прерываний NVIC_ClearPendingIRQ(). Но сейчас обнаружил в прерывании USB_IRQHandler() биоса LPC1343 тоже отсутствие сброса пендинга. Как и в проекте NXP AN11018.zip, который очень похож на код биоса.

Если кто-то знает такие тонкости сброса пендинга, подскажите, плиз.

И зачем в инициализации проекта AN11018 стоит включение тактирования таймера CT32B1, хотя в коде он не используется? Остаток от другого проекта?

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

Проверил на LPC1343. Работает. Если же в хэндлере таймера последней командой стоит TMR32B0IR = 0xff, то это прерывание завершается, но далее перестаёт вызываться. При этом другие прерывания продолжают работать.

Тогда непонятно, почему прерывание таймера LPC1768, запрограммированное на 100 гц могло вызываться 200 гц. Когда же я в его конец поставил NVIC_ClearPendingIRQ(), то оно стало вызываться с правильной частотой. Года 2-3 назад дело было и не могу точно припомнить код хэндлера. Возможно последней командой стоял сброс IR регистра таймера.

Сравниваю разные исходники из примеров Кейла, Иара, NXP и прочих.

IAR-LPC-1343-SK\VirtualCom\modules\usb_hw.c (автор Stanimir Bonev, Date April 8, 2008)

В конце USBIRQ_IRQHandler() стоит NVIC_ClrPend(NVIC_USB_IRQ);

Если прерывание не успело обработаться до прихода следующего запроса, тогда взведется Pending бит, и после выхода из прерывания программа снова в него зайдет. Если же его стереть перед выходом, то не зайдет. Пока следующий запрос не появится. Разве не так?

Хуже! (хотя описаное Вами тоже имеет место быть).
Если последней инструкцией обработчика будет команда сброса флага прерывания, то из-за конвеера/работы_NVIC_с_pending/шин_процессора
она "как бы не успевает выполниться" (т.е. сигнал дойдет до NVIC, но через несколько тактов), а по данным NVIC запрос на прерывание от
периферийного блока не сброшен - милости просим в повторное прерывание.
Но горе мне: не помню, где об этом читал((

Тогда почему об этом не заботятся в библиотечной функции? Или не предупреждают?

Наверное, пока произойдет возврат из прерывания (там же восстанавливаются регистры из стека, по-моему, говорится о 12 тактах, или о 6, если в новое прерывание улетает?), конвейер освободится.

12 тактов (на аппаратное восстановление регистров из стека) будет если нет запроса прерывания. А если новый запрос есть, или старый не успел сбросится - сработает правило Interrupt tail chaining и процессор сразу пойдет на исполнение запроса.
Что бы не было повторной обработки прерывания используют барьеры - __DSB();

Предупреждают! "Мамой клянусь" где-то читал.
Возврат из прерывания занимает 12 тактов, если только нет других разрешенных необработанных прерываний.
Если есть хоть одно, сразу вызывается обработчик без восстановления стека (т.н. Tail-chaining).

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

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

Но с NVIC могут происходить любые чудеса...

А не проще ли сбрасывать флаг сразу по входу в прерывание?
Зачем это делать перед выходом?

На MIPSы больше похоже.

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

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

Правильно ли я понимаю, что NVIC сам сбрасывает запрос/бит в регистре ISPR на выходе текущего прерывания? Или на входе?

Upd
Перепроверил сброс IR последней командой обработчика. Раньше ошибся из-за (двойной) инверсии светодиода внутри обработчика. Поставил вывод байта в УАРТ и заметил. Оказывается точно так же - прерывание вызывается два раза подряд. Прерывание таймера, настроенное на 1 Гц вызывается дважды с паузами в 1 сек. Учту, что впритык к выходу из обработчика нельзя без нопов или барьера. Спасибо adnega, ни за что бы сам не догадался о причине.

А вне обработчика программно его инициировать SetPending-ом корректно? У меня есть такие вещи в CM0, у которого нет регистра STIR. В описании CM3 (LPC134x) об этом регистре есть предложение "The STIR register provides an alternate way for software to generate an interrupt, in addition to using the ISPR registers."

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

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


Некоторые прерывания сбрасываются автоматически при входе в ISR. Но не все.
Читайте мануал на каждый конкретный случай.

Как можно гарантировать, что комада DSB, стоящая последней командой обработчика прерывания будет корректно завершать прерывание NVIC и в текущих версиях кортексов и в последующих их модификациях? Если в последних её будет недостаточно, то об этом где-то объявят?

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

Не прояснит ли кто-то, хотя вопрос уже звучал, новая прокладка с названием Pending, появившаяся в кортексах с NVIC, для чего введена?И на какой логике работает - на динамических триггерах или статических (RS) ? Слово "Pending" вроде как переводится "в обработке", но смысл слишком широкий. Важно знать, когда на этом уровне аппаратно сбрасывается бит прерывания - только на входе в прерывание, или при любом входе на его уровень (например после возврата из более приоритетного) или вообще строго на выходе из него. И насколько изначально заданная логика NVIC будет эталоном для будущих версий чипов и ПО? Если её чуть-чуть изменят и не "объявят очень громко", то корректно написанные программы в будущих модификациях чипов, а так же просто переносимые программистами из старых проектов в новые, могут не просто перестать работать, что было бы выгодней, а вместо этого начать глючить самым сказочным образом.

Команды типа DSB к обработке прерываний никакого отношения не имеют -- они лишь обеспечивают гарантированную доставку чего-нибудь (например, последних записанных данных) к получателям, для чего могут приостанавливать процессор. Pending означает "ожидающий обработки". Применительно к прерыванию этот термин используют для запросов, которые уже восприняты контроллером прерываний, но на обработку процессору ещё не переданы (например, в данный момент он выполняет другой обработчик с таким же или более высоким приоритетом). Способ фиксации запроса прерывания -- по уровню сигнала или по его фронту -- в общем случае настраивается программно. Естественно, что, если прерывание воспринимается по уровню, то при входе в обработчик прерывания оно не только становится active (т.е. в обработке), но и останется pending (поскольку сам запрос прерывания ещё не был снят, и уровень на соответствующей линии продолжает висеть).

NVIC для Cortex-M и GIC для Cortex-A/R объявлены стандартом, так что вряд ли будут меняться несовместимым образом, тем более без чёткого извещения об этом.

Не видел в NVIC регистрах вариантов выбора. В частности в LPC111x, LPC13xx, LPC17xx.

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


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

Вы разве не читали книжку Joseph Yiu "The definitive guide to the ARM Cortex-M3"? Настоятельно рекомендую.

Полистал документацию и обнаружил, что Ваша правда здесь: программный выбор есть только в GIC. Правда, в NVIC есть поддержка не только обычного level-sensitive способа обнаружения запросов прерываний, но и некоего pulse-sensitive, который мне представляется каким-то странным извращением; во всяком случае, из раздела B3.4.1 в описании архитектуры толком понять, как он работает и когда применяется, мне не удалось (ясно лишь, что он в определённом смысле подобен edge-sensitive, но таковым не является). Однако во всех МК, с которыми сталкивался, включая LPC1788, все внешние прерывания являются level-sensitive. Соответственно, запрос прерывания снимается после того, как программа запретит его выдачу соответствующим устройством (ну или устранит причину выдачи -- например, набьёт данными опустевший буфер передачи).



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



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

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

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

Зачем все усложнять.
На пальцах: если последней инструкцией обработчика будет сброс бита запроса прерывания в периферийном блоке, то возможны повторные вхождения.
Чтобы этого не было:
- инструкция сброса не должна быть последней;
- перекомпоновать бработчик так, чтобы сброс бита происходил не в конце обработчика;
- последней инструкцией может быть все что угодно, хоть NOP, хоть чтение, хоть повторная запись, хоть DSB;
- если поставите DSB, то получите выгоду как минимум в многопроцессорных системах (архитектура позволяет делать многоядерные решения).

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

"Другой компот" с разработчиками контроллеров. При заявляемых pin2pin- и soft-совместимостях редко когда встречал "безоблачную" портируемость.
Без чтения даташита не обойдешься))

Этого недостаточно. "Инструкция должна быть не последней" - ни о чём не говорит в принципе, т.к. процессор/компилятор манипулируют с последовательностями инструкций как хотят.

Сброс запроса от периферии должна быть возможность ставить ГДЕ УГОДНО внутри прерывания. Ставить что-то типа DSB логично, но нужно чтобы эта/похожая команда была с указанием того, между какими блоками завершить обмен. Точнее инструкция с известными уровню программы/программиста блоками/шинами и вероятно направлениями сигналов, совершёнными/ожидаемыми уровнем программы. Иначе нет никакой гарантии дохождения требуемых сигналов к моменту выхода из прерывания. Даже какое-то кол-во NOP-ов не является гарантией, т.к. шипко умный процессор может их паралелить с ниже стоящими инструкциями.



Это там нейронная логика завелась

Если хочется логики, то попробуйте к этому относиться не как к "шибко умному процессору", а как к особенности работы периферии.
Т.е. эту проблему процессор за Вас не решит - нужно решение от программиста - расставлять сбросы в таком виде, в котором поведение
ПЕРИФЕРИИ соответствует ожиданиям. У DSB совершенно определенная цель использования, не относящаяся к сбросу битов запроса
прерываний или Pending-битов NVIC.
Зачем все так усложнять? Дались Вам эти шины/блоки?)))
Тут недавно про DMA общались... время от момента запроса транзакции до самой транзакции "плавает" от 12 тактов и выше, что в определенных
случаях делает невозможным его использование. Это если копировать по одной транзакции. Если уходит большая порция данных, то проблем
нет)) Такая же "канитель" и с прерываниями. Если делать "так", то будут особенности, если "иначе" - все хорошо. Можно поискать и другие
блоки в сложной архитектуре, которые дают интересные "побочные эффекты". Да, уж.. это вам не AVR))

Время передачи сигнала от периферии до NVIC и далее к моменту исполнения команды выхода из прерывания мне не известно. Я не могу из-за этого корректно написать программу

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

Если хотите, попробуйте привести эту программу, а мы совместными услиями найдем решение )

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

Во-первых сбрасываю я запрос не в NVIC, а в периферии, которая уже потом сама отправляет "запрос" снятия своей активности в NVIC. Специально пишу "запрос", т.к. наличие выделенной линии этого сигнала 100% не гарантировано, а значит вполне может быть мультиплексной. Во-вторых, если процессор вдруг разделит чтения периферии и запись в неё на разные шины (а на этом можно "заработать"), то вообще гарантии нет, что та же периферия прочитана будет после записи в неё значения, сбрасывающего её запрос для NVIC. Запись в какой-нить dummy-регистр этой же периферии могла помочь, но всё-равно оптимальнее без этих "извращений".

--------------------


adnega, вот пример:




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

Сбросить запрос как таковой в NVIC и нельзя: его (запрос) выдаёт устройство, а значит, только там его и можно сбросить. В контроллере прерываний можно лишь сбросить статус pending, да и то только для запросов, фиксируемых по фронту, а от периферии запросы фиксируются по уровню.



Что значит не гарантировано? В документации на конкретный МК чётко указано, какие номера векторов каким устройствам соответствуют. Если один и тот же вектор выделен нескольким устройствам, тогда их запросы объединяются, если только одному -- не объединяются.



Процессор не может ничего "разделить", если это не заложено в него его разработчиками. ARM гарантирует порядок выполнения обращений к областям, занимаемым регистрами устройств: более поздний запрос и будет выполнен позже; если он успешно завершён, значит, все ранее выданные запросы тоже завершены. Какие ещё гарантии нужны?

Хочется иметь поддержку выбранного варианта завершения прерывания в будущем "переезде" этого кода. А так же чтобы суть завершающих прерывание NOP-ов, DSB или записи+чтения периферии была очевидна для какого-то постороннего программиста.

В документации от ARM имеет смысл искать рекомендации по правильному завершению прерывания? Особенно относительно момента программного сброса запроса в периферии. Судя по этой ветке, сколько людей - столько и мнений.

В примерах вполне свежих компиляторов ИАР, Кейл наблюдаются такие примеры:

Что бы это значило...

Если Вы про NVIC_ClearPendingIRQ(), то это один из уже обсуждавшихся здесь способов защиты от повторного вызова прерывания. Посмотрите комментарий Джозефа Ю в конце ветки по ссылке (предпоследнее сообщение):
http://www.keil.com/forum/18951/

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

Отвечу. Не так. В-частности, для STM32F20X прерывание от EXTI9_5_IRQ нужно сбрасывать, иначе в его обработчике будешь крутиться вечно.

Не так. Надо построить систему так, чтобы ISR успевал выполняться до след. прерывания.

Это понятно. Но вопрос был о том, сбрасывается ли запрос автоматически. Для внешнего прерывания мне приходится сбрасывать его.