В прерываниях 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]

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

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

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


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

Код

void CT32B0_IRQHandler()
{
    if ((++counter & 63) == 0) NVIC_SetPendingIRQ(XXX_IRQn);
    u32 copy = TMR32B0IR;
    TMR32B0IR = copy;
// вопрос стоит сколько NOP-ов здесь поставить чтобы в будущем гарантировать срабатывание прерывания 1 раз от фронта в TMR32B0IR
// или что вместо NOP-ов?
}

void XXX_IRQHandler()
{
// здесь много кода, в т.ч могут срабатывать прерывания выше (CT32B0_IRQHandler имеет выше приоритетность)
// вопрос стоит что здесь ставить для сброса программно-активированных запросов этого прерывания
}

С таким основательным подходом к делу получилось бы!

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

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

[SII]

Во-первых сбрасываю я запрос не в NVIC, а в периферии, которая уже потом сама отправляет "запрос" снятия своей активности в NVIC.

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

Специально пишу "запрос", т.к. наличие выделенной линии этого сигнала 100% не гарантировано, а значит вполне может быть мультиплексной

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

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

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