реклама на сайте
подробности

 
 
> В прерываниях CM0/CM3 в конце нужен ClearPending?
GetSmart
сообщение Nov 15 2013, 07:35
Сообщение #1


.
******

Группа: Участник
Сообщений: 4 005
Регистрация: 3-05-06
Из: Россия
Пользователь №: 16 753



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

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

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

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

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


--------------------
Заблуждаться - Ваше законное право :-)
Go to the top of the page
 
+Quote Post
 
Start new topic
Ответов
SII
сообщение Dec 21 2013, 06:16
Сообщение #2


Знающий
****

Группа: Свой
Сообщений: 549
Регистрация: 13-07-10
Из: Солнечногорск-7
Пользователь №: 58 414



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

NVIC для Cortex-M и GIC для Cortex-A/R объявлены стандартом, так что вряд ли будут меняться несовместимым образом, тем более без чёткого извещения об этом.
Go to the top of the page
 
+Quote Post
GetSmart
сообщение Dec 21 2013, 07:31
Сообщение #3


.
******

Группа: Участник
Сообщений: 4 005
Регистрация: 3-05-06
Из: Россия
Пользователь №: 16 753



Цитата(SII @ Dec 21 2013, 12:16) *
Способ фиксации запроса прерывания -- по уровню сигнала или по его фронту -- в общем случае настраивается программно.

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

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

Цитата(SII @ Dec 21 2013, 12:16) *
Команды типа DSB к обработке прерываний никакого отношения не имеют -- они лишь обеспечивают гарантированную доставку чего-нибудь (например, последних записанных данных) к получателям, для чего могут приостанавливать процессор.

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

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


--------------------
Заблуждаться - Ваше законное право :-)
Go to the top of the page
 
+Quote Post
SII
сообщение Dec 21 2013, 08:20
Сообщение #4


Знающий
****

Группа: Свой
Сообщений: 549
Регистрация: 13-07-10
Из: Солнечногорск-7
Пользователь №: 58 414



Цитата(GetSmart @ Dec 21 2013, 11:31) *
Не видел в 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 -- хотя вместо такой команды можно выполнить "холостое" чтение из устройства.
Go to the top of the page
 
+Quote Post
GetSmart
сообщение Dec 21 2013, 15:00
Сообщение #5


.
******

Группа: Участник
Сообщений: 4 005
Регистрация: 3-05-06
Из: Россия
Пользователь №: 16 753



Цитата(SII @ Dec 21 2013, 14:20) *
Все обращения к областям адресного пространства, относящимся к регистрам устройств или того же 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


--------------------
Заблуждаться - Ваше законное право :-)
Go to the top of the page
 
+Quote Post
SII
сообщение Dec 21 2013, 15:35
Сообщение #6


Знающий
****

Группа: Свой
Сообщений: 549
Регистрация: 13-07-10
Из: Солнечногорск-7
Пользователь №: 58 414



Цитата(GetSmart @ Dec 21 2013, 19:00) *
Во-первых сбрасываю я запрос не в NVIC, а в периферии, которая уже потом сама отправляет "запрос" снятия своей активности в NVIC.


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

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


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

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


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

Сообщений в этой теме
- GetSmart   В прерываниях CM0/CM3 в конце нужен ClearPending?   Nov 15 2013, 07:35
- - adnega   Цитата(GetSmart @ Nov 15 2013, 11:35) Ста...   Nov 15 2013, 08:11
|- - GetSmart   Цитата(adnega @ Nov 15 2013, 14:11) Вроде...   Nov 16 2013, 00:32
|- - Lagman   Цитата(adnega @ Nov 15 2013, 12:11) Вроде...   Nov 18 2013, 19:06
- - GetSmart   Сравниваю разные исходники из примеров Кейла, Иара...   Nov 17 2013, 22:02
- - ViKo   Если прерывание не успело обработаться до прихода ...   Nov 18 2013, 08:51
|- - adnega   Цитата(ViKo @ Nov 18 2013, 12:51) Если пр...   Nov 18 2013, 10:22
|- - GetSmart   Цитата(adnega @ Nov 18 2013, 16:22) Но го...   Dec 21 2013, 04:42
|- - ViKo   Цитата(GetSmart @ Dec 21 2013, 07:42) Не ...   Dec 21 2013, 08:13
- - ViKo   Тогда почему об этом не заботятся в библиотечной ф...   Nov 18 2013, 11:12
|- - adnega   Цитата(ViKo @ Nov 18 2013, 15:12) Тогда п...   Nov 18 2013, 11:32
- - Flexz   Цитата(ViKo @ Nov 18 2013, 15:12) Наверно...   Nov 18 2013, 11:29
- - rudy_b   Технических тонкостей конкретного проца не знаю, н...   Nov 18 2013, 11:36
- - sonycman   А не проще ли сбрасывать флаг сразу по входу в пре...   Nov 18 2013, 18:02
|- - GetSmart   Цитата(sonycman @ Nov 19 2013, 00:02) А н...   Nov 18 2013, 22:38
|- - sonycman   Цитата(GetSmart @ Nov 19 2013, 02:38) Есл...   Nov 19 2013, 09:21
|- - GetSmart   Цитата(SII @ Dec 21 2013, 14:20) время пе...   Dec 21 2013, 08:45
||- - adnega   Цитата(GetSmart @ Dec 21 2013, 12:45) Чте...   Dec 21 2013, 09:17
|- - GetSmart   Цитата(adnega @ Dec 21 2013, 15:17) Зачем...   Dec 21 2013, 09:23
||- - adnega   Цитата(GetSmart @ Dec 21 2013, 13:23) Это...   Dec 21 2013, 10:42
||- - GetSmart   Цитата(adnega @ Dec 21 2013, 16:42) Если ...   Dec 21 2013, 10:52
||- - adnega   Цитата(GetSmart @ Dec 21 2013, 14:52) Вре...   Dec 21 2013, 11:33
|- - GetSmart   Цитата(SII @ Dec 21 2013, 21:35) Какие ещ...   Dec 21 2013, 18:40
- - GetSmart   В примерах вполне свежих компиляторов ИАР, Кейл на...   Dec 22 2014, 14:59
- - nill   Если Вы про NVIC_ClearPendingIRQ(), то это один из...   Dec 23 2014, 18:59
- - ViKo   Я тут копался в своем, перечитал тему. Не увидел с...   Feb 10 2015, 11:46
- - jcxz   Цитата(ViKo @ Feb 10 2015, 17:46) Я тут к...   Feb 12 2015, 02:56
- - ViKo   Цитата(jcxz @ Feb 12 2015, 05:56) Не так....   Feb 12 2015, 05:51


Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 24th July 2025 - 21:57
Рейтинг@Mail.ru


Страница сгенерированна за 0.01446 секунд с 7
ELECTRONIX ©2004-2016