Есть ли жизнь после 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?

[Golikov A.]

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

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

[ViKo]

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

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

[aaarrr]

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

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