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

[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] - для короткого!!!