Есть ли жизнь после WFI?, атомарность WFI Опции

[Brain13]

Здравствуйте!
Я тут задумался о такой потенциальной проблеме при использовании инструкции WFI: Предположим, что программа должна дождаться получения байта по UART, логичным был бы код

Код

while(!Uart.DataAvailable()) {
    __WFI();
}
// тут обработка данных

Но проблема в том что искомый байт может придти между Uart.DataAvailable() и __WFI(), вызовется обработчик прерывания, после которого вызовется __WFI() и МК больше никогда не проснется.

Вставка критических секций:

Код

__disable_irq();
// тут что-то
__enable_irq();
__WFI();

не спасет ситуацию, так как между __enable_irq(); и __WFI(); может проскочить нужное прерывание(а может не проскочить).

Поиски вывели меня на вот эту англоязычную тему: http://community.arm.com/message/8927 и доку http://infocenter.arm.com/help/index.jsp?t...a/BIHBFEIB.html
Но я так и не понял, что есть решение проблемы.
Так есть ли в Cortex-M гарантированный способ проснуться после WFI?

[zltigo]

Тема начинается со слов "Предположим, что программа должна дождаться получения байта по UART"
В системе присутствует множество источников прерываний: SPI, UART, SysTick, Таймеры, Внешние прерывания и прочее. Но все это к решению задачи не относится.

К решению какой задачи? Про сферического коня в вакууме в которой специально создаются некие условия, отметается другая постановка задачи и системные решения и начинается решаться "задача"?

Если это так важно, то я делал код для бутлоадера, который

Да, ну очень важная функция бутлоадера засыпать между отправками байтов. Ну, допустим, без экономии жить нельзя...

при переполнении буфера ждет пока хотябы один байт будет отправлен в UART и тогда в буфере появится место для добавления еще одного байта.

DMA, FIFO а так-же, прочие "ценные ресурсы" контролера не должны использоваться, потому, что потому ....

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

Через анус, большой и огромный, это НЕ использовать в Вашем загрузчике те-же таймауты для выхода и множества других ситуаций, когда по множеству причин отвалится тот-же канал связи с загрузчиком или вообще весь мир забудет о том, что какой-то там контроллер передавал байты.

Вообще, не понимаю шума, поднятого отдельными товарищами. ТС озвучил вполне реальную проблему и один из путей её решения.

Не открытие, но за напоминание, безусловно спасибо.

Так ведь нет, надо свести к частным случаям и доказать, что это никому не нужно.

А тут у меня диаметрально противоположная точка зрения о том, что является "частным случаем". К частному, вырожденному случаю свел именно
Автор.

[aaarrr]

К частному, вырожденному случаю свел именно Автор.

Человеку, знакомому с проблемой, достаточно прочитать два первых предложения исходного поста, чтобы понять суть вопроса. Вдаваться в приведенные для примера условия ("Предположим...") совсем не обязательно.

[ViKo]

А в чем, собственно, проблема? Ставьте WFI после обработки данных (см. код в первом сообщении), а не после приема. Разве не логично?

[Golikov A.]

Проблема понятна, можно даже не брать UART и прочее, гораздо абстрактнее

WFI засыпает до прерывания и если делать

_irq_disable();
.... //какие то проверки возможности уснуть
_irq_enable();
__WFI();

то есть шанс что прерывание произойдет между
_irq_enable();
//вот прямо вот здесь
__WFI();

соответственно оно будет обработано до __WFI, и не будет причиной пробуждения, то есть схема будет спать до следующего.

Поэтому правильно этот кусок кода писать в таком виде

_irq_disable();
.... //какие то проверки возможности уснуть
__WFI();
_irq_enable();

это просто надо запомнить, также как, что прерывания надо сбрасывать через присвоение (=), а не через &=, |=

[Obam]

Поэтому правильно этот кусок кода писать в таком виде

_irq_disable();
.... //какие то проверки возможности уснуть
__WFI();
_irq_enable();

Прошу пощения, как (чем) при запрещённых прерываниях ядро будет выведено из (цитирую ARM DDI 0403E.
"suspend execution and enter a low-power state. It can remain in that
state until the processor detects one of the following WFI wakeup events:
• A reset.
• An asynchronous exception at a priority that, if PRIMASK was set to 0, would preempt any currently active
exceptions.
Note
The processor ignores the value of PRIMASK in determining whether an asynchronous exception is a WFI
wakeup event.
• If debug is enabled, a debug event.
• An IMPLEMENTATION DEFINED WFI wakeup event."? (конец цитаты)

Какое событие из списка позволит исполнить _irq_enable()?

[ViKo]

Поэтому правильно этот кусок кода писать в таком виде

_irq_disable();
.... //какие то проверки возможности уснуть
__WFI();
_irq_enable();

это просто надо запомнить, также как, что прерывания надо сбрасывать через присвоение (=), а не через &=, |=

Т.е. уснуть и не проснуться?

[Golikov A.]

О чем собственно и есть эта тема.

Как я понял __WFI(); - анализирует регистр битиков в векторе NVIC
в то время как
_irq_disable();
_irq_enable();
работает со статусным регистром проца.
потому когда вы делаете
_irq_disable();
вы запрещаете переход проца в обработку, но все механизмы нужные WFI для просыпания оставляете работоспособными. Уверености что это не получилось случайно, и что именно так они и хотели у меня нет, может это баг обращенный в фичу, но тем не менее...

[aaarrr]

Можно применить еще такой вариант:

Код

__SEV();
__WFE();
if(<можно спать>)
    __WFE();

[Obam]

Всё, согласен.
Мир устоял.

[ViKo]

Как я понял __WFI(); - анализирует регистр битиков в векторе NVIC
в то время как
_irq_disable();
_irq_enable();
работает со статусным регистром проца.
потому когда вы делаете
_irq_disable();
вы запрещаете переход проца в обработку, но все механизмы нужные WFI для просыпания оставляете работоспособными. Уверености что это не получилось случайно, и что именно так они и хотели у меня нет, может это баг обращенный в фичу, но тем не менее...

Где такое написано?

[aaarrr]

Где такое написано?

См. Note в цитате из мануала выше.

[ViKo]

См. Note в цитате из мануала выше.

А что в ней написано?
В тех примерах, что я посмотрел, везде разрешаются прерывания перед использованием WFI.

[aaarrr]

А что в ней написано?

Действительно, что?

В тех примерах, что я посмотрел, везде разрешаются прерывания перед использованием WFI.

Далеко не всегда в запрещении прерываний есть необходимость.
Необходимость возникает, когда WFI выполняется в зависимости от условия, которое может измениться в прерывании.

[ViKo]

Действительно, что?

Что независимо от запрещенных прерываний (установленного бита в BASEPRI командой _disable_irq) может разбудить процессор:
• событие Debug
• некое IMPLEMENTATION DEFINED WFI.
Это говорит о том, что любое запрещенное прерывание может разбудить процессор?

Неправильно. Примечание относится к пункту 2. Хорошо... будем искать дальше...

[Obam]

…(установленного бита в BASEPRI командой _disable_irq)…

Вспомнился старый анекдот: "…Не ебонит!!! Целлюлёид!!!…"
PRIMASK