Вот похожая тема В прерываниях CM0/CM3 в конце нужен ClearPending?

Имеем такой простой до невозможности код


смотрим осциилографом, что получается:

___|___|___|___

Или наоборот

^{— —} |^{— —} |^{— —} |^{— —}

Вместо ожидаемого ^{— —} |___|^{— —} |___|^{— —} |___

При этом, если поставить брякпойнт на FIOSET или FIOCLR, а потом убрать и продолжить, то картина меняется
если мерять время этого второго паразита, то это будет 12-14 клоков
Однако, если перенести IR = 1; в начало


То все налаживается....

Теперь смотрю на все остальные прервывания, в том числе GPI прерывания GPIO прерывания Rising/Falling edge приходят одновременно? (2 ноги * прерывания по фронту и спаду) - там тоже получается какое-то левое повторное прерывание.. однако манипуляции с выносом очистки прерывания как можно раньше не прокатывают и, кажется, наоборот, от выноса очистки в конец количество левых прерываний уменьшается

ЗЫ: а в эмуляторе это не вылазит

Сообщение отредактировал evgen2 - Jan 15 2014, 00:07

Если память не изменяет - не нужен, но вот где это написано не помню (изменяет таки) а искать лень.

Может что такое добавить, хотя у вас не RTC...

Угу. Это влияние конвеера. Или сбрасывайте в начале, или вставляйте барьер синхронизации после сброса флага.

"Барьер синхронизации" - это "заклинание" __DSB(); ? Непонятно, почему ни в мануалах, ни в примерах его нет

Ну хотя бы по диагонали просмотрите начало документа по ссылке.
Я вам дал ссылку как раз на мануал с примером.

да хоть по диагонали, хоть на принтере распечатать да на просвет посмотреть . Может оно и влияет, если засыпать-просыпаться, а без этого - никакой разницы

Due to the processor pipeline, the Cortex-M processors can be entering the interrupt sequence
at the same time as writing to the NVIC to disable the interrupt. Therefore, it is possible that an
interrupt handler might be executed immediately after it is disabled at the NVIC.

http://infocenter.arm.com/help//topic/com....r_m_profile.pdf

Мимо кассы. Так как у ТС нет запретов прерываний внутри ISR, и даже вообще обращений к NVIC внутри ISR.

Доброго дня ! на контроллере 1768 с MC0 и таймером проблем не имею.


я бы для чистоты эксперимента объявил бы еще переменную как volatile

или вовсе бы ушел от нее

1. Вот потому, что "дальше код", потому и не имеете
2. Операция if(_interrupt_source & (1<<0)){ бессмысленна, так как если у вас установлены ещё и другие флаги запросов в IF, то функция всё равно зациклится в непрерывных входах в ISR (ведь регистра маски прерываний в таймере вроде нету?).
3. Операция |= в LPC_TIM0->IR |= (1<<0); также бессмысленна, читайте UM.
4. volatile объявлять бессмысленно если переменная больше нигде не используется (а она больше нигде не используется).
5. Делать так: LPC_GPIO2->FIOPIN ^= 0x1000; крайне опасно, если учесть, что в основном коде (или другом ISR) могут быть операции с другими битами этого порта. Курите UM на предмет - зачем придуманы FIOSET и FIOCLR.

PS: И вообще - лучше молчать, чем давать такие "советы".
Лучше поучитесь хотя-бы у ТС как правильно реализовывать ISR-ы.

частота дерганья ножкой 40kHz. обработчик упростил

все работает, как и раньше. в UM ни слова о том, в каком месте сбрасывать флаг.



это не принципиально в конкретном примере. прерывания по MATCH и CAP маскируются.


я же написал - для чистоты эксперимента. иначе получается, что вы знаете о том, что переменная нигде не используется, но не знаете, что порт 2 пустой

Допустим, у меня есть следующий обработчик прерываний:

нужно ли мне ставить после __enable_irq(); __ISB()?

Сообщение отредактировал sidy - Jan 16 2014, 16:14

Скажем по-другому: вам скорее всего не нужно ставить __disable_irq()/__enable_irq().
Зачем они? У вас что - в другом, более приоритетном ISR осуществляется запись в эти регистры???


Что переменная нигде не используется я знаю из static int, а то что порт больше нигде - об этом ни слова.
К тому же переменных типа int в ОЗУ можно создать ГОРАЗДО больше чем обычно имеется портов в МК. Если вы так расточительно будете подходить к ногам, что на одну ногу будете тратить целый 32-битный порт, то далеко не уедете...

Например, если между записью в регистр CNT и пуском таймера TIM_CR1_CEN придет более приоритетное прерывание, то TIM11->CNT может сделать n-ое количество тактов и значение TIM4->CNT будет некорректным.

Как же можно ответить ответить на Ваш вопрос, если невозможно догадаться, что у вас за регистры такие SR и CNT?
В UM на LPC17xx таковых нету.
Ну если под CNT ещё можно предположить регистр TC, то с SR вообще теряюсь в догадках....
Подозреваю что у вас не LPC17x. А в таком случае нужно указывать какой CPU имеете в виду если вопрос касается периферии и желательно указывать как она у вас сконфигурена.