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

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

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

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

Правда, в NVIC есть поддержка не только обычного level-sensitive способа обнаружения запросов прерываний, но и некоего pulse-sensitive, который мне представляется каким-то странным извращением; во всяком случае, из раздела B3.4.1 в описании архитектуры толком понять, как он работает и когда применяется, мне не удалось (ясно лишь, что он в определённом смысле подобен edge-sensitive, но таковым не является).

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

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

[adnega]

Этого недостаточно.

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

[GetSmart]

Если хочется логики, то попробуйте к этому относиться не как к "шибко умному процессору", а как к особенности работы периферии.Т.е. эту проблему процессор за Вас не решит - нужно решение от программиста - расставлять сбросы в таком виде, в котором поведение ПЕРИФЕРИИ соответствует ожиданиям.

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

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

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

[adnega]

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

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

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

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