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

А почему вфи будет не после возврата из прерывания и по новому не проснеться?

[Brain13]

А почему вфи будет не после возврата из прерывания и по новому не проснеться?

Не уверен, что понял Ваш вопрос, но постараюсь расписать поподробнее.

В крайнем случае имеем код типа

Код

__disable_irq();
// тут проверки на наличие принятого байта
__enable_irq();
__WFI();

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

Вопрос: как дождаться прерывания с использованием WFI и гарантированно проснуться?

[RabidRabbit]

Таки в обработчике прерывания от UART можно взвести таймер на пару десятков тиков клока, тады и проснётесь...

[Brain13]

Кажется, я нашел ответ: http://infocenter.arm.com/help/index.jsp?t...a/BABGGICD.html

Some embedded systems might have to execute system restore tasks after the processor wakes up, and before it executes an interrupt handler. To achieve this set the PRIMASK bit to 1 and the FAULTMASK bit to 0. If an interrupt arrives that is enabled and has a higher priority than current exception priority, the processor wakes up but does not execute the interrupt handler until the processor sets PRIMASK to zero.

Т. е. код должен быть примерно таким:

Код

while(1)
{
  __disable_irq();
  if(Uart.DataAvailable()) {
    break;
  }
  __WFI();
  __enable_irq();
  __NOP();
}

Соотетственно если байт придет перед инструкией WFI, то произойдет запрос прерывания, но обработчик не вызовется(прерывания запрещены), потом вызовется WFI, но он не усыпит прессор так как есть запрос на прерывание, потом исполнится enable_irq, после которого(в течение 0-2 инструкций) вызовется обработчик прерывания.

Теперь осталось это проверить.

Таки в обработчике прерывания от UART можно взвести таймер на пару десятков тиков клока, тады и проснётесь...

Во-первых, это - костыль.
Во-вторых, еще не хватает мне таймер на это тратить, они же не бесплатно в МК даются - это ценный ресурс.

Сообщение отредактировал Brain13 - Jun 1 2015, 20:02

[zltigo]

Во-вторых, еще не хватает мне таймер на это тратить, они же не бесплатно в МК даются - это ценный ресурс.

Вы уж определитесь, что Вы делаете - сферического коня в вакууме с одим прерыванием и кучей лишних ресурсов, в том числе и таймеров, или реальную систему в которой будут и другие источники прерываний от тех-же таймеров. Не говоря уже о том, что UART тоже может быть не однм источником прерывания.

[Obam]

Я посмотрел ARM DDI 0403E.b - Architecture Reference Manual - стр. B1-618: TS, эта команда разве в цикле должна вызываться?

Опять же, прерывание для того и существует, чтобы событие его порождающее не ждать.

[Golikov A.]

Соотетственно если байт придет перед инструкией WFI, то произойдет запрос прерывания, но обработчик не вызовется(прерывания запрещены), потом вызовется WFI, но он не усыпит прессор так как есть запрос на прерывание, потом исполнится enable_irq, после которого(в течение 0-2 инструкций) вызовется обработчик прерывания.

WFI is a hint instruction that suspends execution until one of the following events occurs:
a non-masked interrupt occurs and is taken
an interrupt masked by PRIMASK becomes pending
a Debug Entry request.

то есть если вы замаскируете прерывание, и вызовите wfi, а размаскирование стоит после нее, то это кирпич?

[sensor_ua]

Предложу взглянуть на статью Use an MCU's low-power modes in foreground/background systems by Miro M. Samek, ESD, September 2007, есть у неё и перевод.
Добавлю, что у Cortex-M можно настроить работу так, что по выходу из обработчика прерывания ядро не будится без дополнительных действий

[Brain13]

Вы уж определитесь, что Вы делаете - сферического коня в вакууме с одим прерыванием и кучей лишних ресурсов, в том числе и таймеров, или реальную систему в которой будут и другие источники прерываний от тех-же таймеров. Не говоря уже о том, что UART тоже может быть не однм источником прерывания.

Я делаю реальную систему, но если я хочу дождаться прервания по UART причем тут прерывание по таймеру?

Я посмотрел ARM DDI 0403E.b - Architecture Reference Manual - стр. B1-618: TS, эта команда разве в цикле должна вызываться?

Опять же, прерывание для того и существует, чтобы событие его порождающее не ждать.

Часто бывают случаи когда нужно дождаться какого либо события и только потом действовать. А while(xxx) {} не сильно хороший вариант, ибо потребление.

то есть если вы замаскируете прерывание, и вызовите wfi, а размаскирование стоит после нее, то это кирпич?

Вот именно, что не кирпич, ведь мы запрещаем не само прерывание, а вызов его обработчика. При появлении запроса на прерывание процессор проснется, а вызов обработчика произойдет после __enable_irq();. Я проверил, такой код работает и не виснет(STM32F3DISCOVERY):

CODE

int main(int argc, char* argv[]) {
RCC_AHBPeriphClockCmd(RCC_AHBPeriph_GPIOA, ENABLE);
RCC_AHBPeriphClockCmd(RCC_AHBPeriph_GPIOE, ENABLE);
RCC_APB2PeriphClockCmd(RCC_APB2Periph_SYSCFG, ENABLE);

GPIO_InitTypeDef gpio;

gpio.GPIO_Mode = GPIO_Mode_OUT;
gpio.GPIO_OType = GPIO_OType_PP;
gpio.GPIO_Pin = GPIO_Pin_9;
gpio.GPIO_PuPd = GPIO_PuPd_NOPULL;
gpio.GPIO_Speed = GPIO_Speed_2MHz;

GPIO_Init(GPIOE, &gpio);
GPIO_ResetBits(GPIOE, GPIO_Pin_9);

gpio.GPIO_Mode = GPIO_Mode_IN;
gpio.GPIO_OType = GPIO_OType_PP;
gpio.GPIO_Pin = GPIO_Pin_0;
gpio.GPIO_PuPd = GPIO_PuPd_NOPULL;
gpio.GPIO_Speed = GPIO_Speed_2MHz;
GPIO_Init(GPIOA, &gpio);

EXTI_InitTypeDef exti;
exti.EXTI_Line = EXTI_Line0;
exti.EXTI_Mode = EXTI_Mode_Interrupt;
exti.EXTI_Trigger = EXTI_Trigger_Rising;
exti.EXTI_LineCmd = ENABLE;

EXTI_Init(&exti);

NVIC_InitTypeDef nvic;

nvic.NVIC_IRQChannel = EXTI0_IRQn;
nvic.NVIC_IRQChannelPreemptionPriority = 0x0F;
nvic.NVIC_IRQChannelSubPriority = 0x0F;
nvic.NVIC_IRQChannelCmd = ENABLE;

NVIC_Init(&nvic);

// Infinite loop
while (1)
{
for(;;) {
__disable_irq();
if(flag) break;
__WFI();
__enable_irq();
__NOP();
__NOP();
__NOP();
}
__enable_irq();

if(GPIO_ReadOutputData(GPIOE) & GPIO_Pin_9) {
GPIO_ResetBits(GPIOE, GPIO_Pin_9);
} else {
GPIO_SetBits(GPIOE, GPIO_Pin_9);
}
flag = 0;
}
}

void EXTI0_IRQHandler(void)
{
if((EXTI_GetITStatus(EXTI_Line0) != RESET)) {
flag = 1;
EXTI_ClearITPendingBit(EXTI_Line0);

}
}

Сообщение отредактировал IgorKossak - Jun 3 2015, 17:45

Причина редактирования: [codebox] для длинного кода, [code] - для короткого!!!

[zltigo]

Я делаю реальную систему, но если я хочу дождаться прервания по UART причем тут прерывание по таймеру?

Еще раз, медленно и печально в Вашей "реальной" системе прерывание UART единственное? И вообще никакой другой работы у контроллера НЕТ,
раз Вы только занимаетесь обработкой того, что получили в прерывании. Если да, то тогда Вы просто решаете задачу через анус - делайте просто ВСЮ
"работу" в прерывании и не изобретайте проблемы. Если ответ нет, тогда и проблемы нет с гипотетическим непросыпанием.

[Brain13]

Еще раз, медленно и печально в Вашей "реальной" системе прерывание UART единственное? И вообще никакой другой работы у контроллера НЕТ,
раз Вы только занимаетесь обработкой того, что получили в прерывании. Если да, то тогда Вы просто решаете задачу через анус - делайте просто ВСЮ
"работу" в прерывании и не изобретайте проблемы. Если ответ нет, тогда и проблемы нет с гипотетическим непросыпанием.

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

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

[Golikov A.]

Вот именно, что не кирпич, ведь мы запрещаем не само прерывание, а вызов его обработчика.

Вы запрещаете вызов вообще любого обработчика __disable/__enable_irq(); - это запрет вообще реакции на прерывание, писать так для NVIC не очень правильно.

Для него обычно маскируют(демаскируют) то прерывание которое не должно мешать, и в этом случае как я понимаю будет кирпичик...

Но в случае входа в сон с проверкой активных прерываний для отмены перехода, наверное пойдет глобальный их запрет. Только так и таймер тоже отключиться, у вас таймера нету? Тики не читаете?

[_4afc_]

Еще раз, медленно и печально в Вашей "реальной" системе прерывание UART единственное? И вообще никакой другой работы у контроллера НЕТ,
раз Вы только занимаетесь обработкой того, что получили в прерывании. Если да, то тогда Вы просто решаете задачу через анус - делайте просто ВСЮ
"работу" в прерывании и не изобретайте проблемы.

Вот я почему-то так и делал в своей системе. Вся обработка в прерывании - результат складывается в буфер с увеличением счетчика. и while WFI
Как может произойти пропуск прерывания за несколько тактов? Неужто UART на 1000МГц?
Сколько мС занимает цикл while и с какой частотой работает UART?

[aaarrr]

Неужто UART на 1000МГц?

Да хоть 32кГц! Он асинхронный, так что прерывание может сработать между проверкой условия и 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

[ViKo]

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

Описался.

[Brain13]

Это говорит о том, что любое запрещенное прерывание может разбудить процессор?

Нет, запрещенное походу не разбудит...
http://infocenter.arm.com/help/index.jsp?t...a/BABGGICD.html

To achieve this set the PRIMASK bit to 1 and the FAULTMASK bit to 0. If an interrupt arrives that is enabled and has a higher priority than current exception priority, the processor wakes up but does not execute the interrupt handler until the processor sets PRIMASK to zero.

То есть разбудит процессор только разрешенное(я так понимаю в NVIC) прерывание с более выским приоритетом.

Сообщение отредактировал Brain13 - Jun 4 2015, 18:23

[Golikov A.]

А вот и последняя часть пазла

http://infocenter.arm.com/help/index.jsp?t...e/CJAFBCBB.html

__disable_irq
Typically, this intrinsic disables IRQ interrupts by setting the I-bit in the CPSR. However, for M-profile it sets the exception mask register (PRIMASK).

и следовательно последовательность

__disable_irq
....
__swi() __WFI()
....
__enable_irq
правильная,

the processor wakes up but does not execute the interrupt handler until the processor sets PRIMASK to zero.

[DmitryM]

и следовательно последовательность

__disable_irq
....
__swi() или __wfi()
....
__enable_irq
правильная,

???

[Obam]

и следовательно последовательность

__disable_irq
....
__swi()
....
__enable_irq
правильная,

Не в масть! Даже команды такой нет. (Гусары, про UAL молчать!!!)
Тема про WFI!

[Golikov A.]

Да я о чем-то своем думал, естественно имел ввиду команду WFI, поправил сообщение, простите...

Гусары могут кричать, коль сопоставить 2 факта не в силах....

еще раз для гусар, а то вдруг опять че не поймут

вот так правильно

__disable_irq()
....
__WFI()
....
__enable_irq()

[jcxz]

Имхо - у ТС изначально неверно построен алгоритм. WFI не нужно смешивать с каким-либо полезным кодом.
Систему с WFI надо строить так, чтобы WFI выполнялось в фоновом процессе (возможно просто бесконечный цикл while (1) WFI();),
а вся полезная работа - в задачах или ISR с приоритетом выше фонового.
Тогда никаких запретов прерывания с WFI не нужно, WFI будет выполняться только когда нет ждущих прерываний.
Если ПО без ОС - вся работа в ISR-ах (разбитых по приоритетам), в фоновой задаче - функция main() заканчивающаяся while (1) WFI();.