В прерываниях CM0/CM3 в конце нужен ClearPending? Опции

[GetSmart]

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

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

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

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

Сообщение отредактировал GetSmart - Nov 16 2013, 00:33

[SII]

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

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

[GetSmart]

Способ фиксации запроса прерывания -- по уровню сигнала или по его фронту -- в общем случае настраивается программно.

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

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

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

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

Сообщение отредактировал GetSmart - Dec 21 2013, 07:34

[SII]

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

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

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

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

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

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

[GetSmart]

время передачи самого запроса от устройства к контроллеру прерываний внутри кристалла явно меньше длительности такта, которая у МК весьма велика, поэтому можно считать, что после успешного выполнения запрета прерывания запрос исчез сразу

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

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

Сообщение отредактировал GetSmart - Dec 21 2013, 10:29

[adnega]

Чтение из периферии после записи - идея хорошая...

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

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

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