Форум разработчиков электроники ELECTRONIX.ru

Brain13

Jun 1 2015, 18:34

Здравствуйте!
Я тут задумался о такой потенциальной проблеме при использовании инструкции 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.

Jun 1 2015, 18:39

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

Brain13

Jun 1 2015, 18:54

Цитата(Golikov A. @ Jun 1 2015, 21:39)

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

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

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

Код

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

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

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

RabidRabbit

Jun 1 2015, 19:59

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

Brain13

Jun 1 2015, 20:03

Кажется, я нашел ответ: 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 инструкций) вызовется обработчик прерывания.

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

Цитата(RabidRabbit @ Jun 1 2015, 22:59)

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

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

zltigo

Jun 1 2015, 23:06

QUOTE (Brain13 @ Jun 1 2015, 23:03)

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

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

Obam

Jun 2 2015, 07:06

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

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

Golikov A.

Jun 2 2015, 07:25

Цитата

Соотетственно если байт придет перед инструкией 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

Jun 2 2015, 08:50

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

Brain13

Jun 3 2015, 17:18

Цитата(zltigo @ Jun 2 2015, 02:06)

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

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

Цитата(Obam @ Jun 2 2015, 10:06)

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

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

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

Цитата(Golikov A. @ Jun 2 2015, 10:25)

то есть если вы замаскируете прерывание, и вызовите 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);

  }
}

zltigo

Jun 3 2015, 17:28

QUOTE (Brain13 @ Jun 3 2015, 20:08)

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

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

Brain13

Jun 3 2015, 18:01

Цитата(zltigo @ Jun 3 2015, 20:28)

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

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

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

Golikov A.

Jun 3 2015, 19:42

Цитата

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

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

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

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

_4afc_

Jun 3 2015, 20:33

Цитата(zltigo @ Jun 3 2015, 21:28)

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

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

aaarrr

Jun 3 2015, 20:49

Цитата(_4afc_ @ Jun 3 2015, 23:33)

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

Да хоть 32кГц! Он асинхронный, так что прерывание может сработать между проверкой условия и WFI.

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

zltigo

Jun 4 2015, 00:40

QUOTE (Brain13 @ Jun 3 2015, 21:01)

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

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

QUOTE

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

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

QUOTE

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

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

....

QUOTE

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

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

QUOTE (aaarrr @ Jun 3 2015, 23:49)

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

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

QUOTE

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

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

aaarrr

Jun 4 2015, 01:05

Цитата(zltigo @ Jun 4 2015, 03:40)

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

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

ViKo

Jun 4 2015, 04:00

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

Golikov A.

Jun 4 2015, 06:26

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

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

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

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

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

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

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

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

Obam

Jun 4 2015, 08:07

Цитата(Golikov A. @ Jun 4 2015, 10:26)

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

_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

Jun 4 2015, 08:12

Цитата(Golikov A. @ Jun 4 2015, 09:26)

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

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

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

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

Golikov A.

Jun 4 2015, 09:30

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

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

aaarrr

Jun 4 2015, 09:50

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

Код

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

Obam

Jun 4 2015, 09:57

Всё, согласен.

Мир устоял.

ViKo

Jun 4 2015, 10:12

Цитата(Golikov A. @ Jun 4 2015, 12:30)

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

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

aaarrr

Jun 4 2015, 10:14

Цитата(ViKo @ Jun 4 2015, 13:12)

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

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

ViKo

Jun 4 2015, 10:34

Цитата(aaarrr @ Jun 4 2015, 13:14)

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

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

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

aaarrr

Jun 4 2015, 10:51

Цитата(ViKo @ Jun 4 2015, 13:34)

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

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

Цитата(ViKo @ Jun 4 2015, 13:34)

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

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

ViKo

Jun 4 2015, 11:45

Цитата(aaarrr @ Jun 4 2015, 13:51)

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

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

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

Obam

Jun 4 2015, 12:22

Цитата(ViKo @ Jun 4 2015, 15:45)

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

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

PRIMASK

ViKo

Jun 4 2015, 12:31

Цитата(Obam @ Jun 4 2015, 15:22)

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

PRIMASK

Описался.

Brain13

Jun 4 2015, 18:22

Цитата

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

Нет, запрещенное походу не разбудит...
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) прерывание с более выским приоритетом.

Golikov A.

Jun 5 2015, 04:38

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

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

Jun 5 2015, 04:46

Цитата(Golikov A. @ Jun 5 2015, 08:38)

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

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

???

Obam

Jun 5 2015, 05:46

Цитата(Golikov A. @ Jun 5 2015, 08:38)

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

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

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

Golikov A.

Jun 5 2015, 10:58

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

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

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

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

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

jcxz

Jun 6 2015, 07:14

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