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

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

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

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


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

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

Вы разве не читали книжку 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.

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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


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




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

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

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



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



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

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

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

Сообщение отредактировал GetSmart - Dec 22 2013, 17:14

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

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

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