продолжить прерывание, atmega128 winavr Опции

[Mikron]

Добрый день

есть некоторый код

Код

void funс(void){
    cli();
    ...
    sei();
}
ISR(INT0_vect){
    ...}
ISR(USART1_RX_vect){
    ...}
ISR(USART1_TX_vect){
   ...
   func();
   ...}
ISR(USART1_UDRE_vect){
...  }
...

Функцию я вызываю из прерывания, во время её выполнения прерывания нужно запретить.
Когда я их снова разрешу, то могут возникнуть любые прерывания, а не продолжалось USART1_TX, так ведь?
Вопрос, как сделать так, что бы после разрешения прерываний разрешалось только USART1_TX

Спасибо за помощь

[Палыч]

...прерывания нужно запретить.

Почему в функции прерывания нужно сначала запрещать, а потом разрешать? Обработчик прерывания у Вас работает при разрешенных прерываниях? Или может быть функция вызывается ещё из другого места и необходимо, чтобы она при своей работе не прерывалась? В этом случае состояние разрешения прерывания нужно сохранять перед запретом, а потом восстанавливать.

[Xenia]

Функцию я вызываю из прерывания, во время её выполнения прерывания нужно запретить.
Когда я их снова разрешу, то могут возникнуть любые прерывания, а не продолжалось USART1_TX, так ведь?
Вопрос, как сделать так, что бы после разрешения прерываний разрешалось только USART1_TX

Ничего в функциях обработки прерываний запрещать и разрешать не надо, т.к. это происходит полностью автоматически. Т.е. при возникновении ситуации прерывания с последующим перескоком из произвольного места программы на процедуру его обработки, прерывания автоматически запрещаются. И никакой cli дополнительно тут не нужен. Точно так же, прерывания восстановятся сами после выхода из той процедуры по iret.

А вот то, что в процедуре прерывания надо делать обязательно, то это сохранить содержимое регистра флагов (0x3F), а также исходные значения всех регистров, которые в той процедуре используете. Для этого и то, и другое, следует загнать в стек, а перед выходом восстановить из стека.

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

[ILYAUL]

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

А вы в обработчике USART1_TX - запретите , сделайте сброс разрешений прерываний в контрольном регисте USART1, тех что Вам не нужны. Вывалитесь из обработчика , у Вас останется только USART1_TX.
Но Вам надо продумать , как потом включить их снова.
Да и вот ещё , TX у Вас "младшее" по приоритету прерывание , смотря как написан код , Вы рискуете туда и не добраться

[Mikron]

Всем огромное спасибо за помощь)
Что-то я реально затупил, просто, как Палыч написал, функция вызывалась так же из другого места, где прерывания должны были запрещаться

[Палыч]

...функция вызывалась так же из другого места, где прерывания должны были запрещаться

Если тело функции обязательно не должно прерываться, то в этом случае сохраняют/восстанавливают флаг прерывания

Код

void func(void)
{
  unsigned char savSREG= SREG;  // Сохранить SREG
  CLI();  // Запретить прерывания
.........................
  SREG = savSREG;  // Востановить SREG
}

[Mikron]

Да и вот ещё , TX у Вас "младшее" по приоритету прерывание , смотря как написан код , Вы рискуете туда и не добраться

Возник вопрос, почему могу туда не добраться
Просто в документации на контроллер про прерывания написано

There are basically two types of interrupts. The first type is triggered by an event that
sets the interrupt flag. For these interrupts, the Program Counter is vectored to the
actual interrupt vector in order to execute the interrupt handling routine, and hardware
clears the corresponding interrupt flag. Interrupt flags can also be cleared by writing a
logic one to the flag bit position(s) to be cleared. If an interrupt condition occurs while the
corresponding interrupt enable bit is cleared, the interrupt flag will be set and remembered
until the interrupt is enabled, or the flag is cleared by software. Similarly, if one or
more interrupt conditions occur while the global interrupt enable bit is cleared, the corresponding
interrupt flag(s) will be set and remembered until the global interrupt enable bit
is set, and will then be executed by order of priority.

То есть произошел как бы запрос на прерывание, установился флаг, и рано или поздно оно все равно произойдет, а почему нет?

[_Артём_]

Код

void func(void)
{
  unsigned char savSREG= SREG;  // Сохранить SREG
  CLI();  // Запретить прерывания
.........................
  SREG = savSREG;  // Востановить SREG
}

Разве при переходе на вектор прерывания флаг I не сбрасывается?
Тогда CLI(); - лишняя.

[Палыч]

Разве при переходе на вектор прерывания флаг I не сбрасывается? Тогда CLI(); - лишняя.

Мной приведена функция, которую вызывают из обработчика прерывания (в этом случае - флаг I сброшен) и из другого места программы (например, из бесконечного цикла - флаг I установлен), т.е. примерно такая, как у автора вопроса. Код функции таков, что вся функция или её отдельный участок должен работать не прерываясь. Чтобы выполнение кода не прервалось, прерывания нужно запретить (конечно, если вызвана функция из прерывания - флаг I и так сброшен, и делать это не обязательно, но "лишний" раз - не повредит), но вот в конце функции (или её участка) разрешать прерывания нужно не всегда, а только в том случае, если при входе в функцию прерывания были разрешены. Imho, сделать это удобно сохраняя при входе в функцию регистр SREG (из него нам интересен флаг I), а в конце функции(участка кода) - восстановить SREG вместе с флагом I.

[ILYAUL]

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

Всё достаточно просто, TX1 имеет низший приоритет . А вот INT0_vect высший, затем идут USART1_RX_vect и USART1_UDRE_vect и только потом Ваш. Вам надо посчитать насколько часто будут появлятся эти три прерывания, успеете Вы в паузах между ними обработать TX, ведь надо успеть принять символ, загрузить символ и ещё обработать INT0 и на все три уходит время . Смотря как Вы напишете код , у Вас просто может не хватить времени обработать TX . Его "забьют" старшие. Надо бы сказать , что USART1_TX_vect это дублёр USART1_UDRE - этот имеет тенденцию забросил и забыл. Первый (USART1_TX_vect) передачу закончил. В зависимости от требуемых функций ( не путать с функциями Си) можно использовать или UDRE или TX. Так например при обработке DS18B20 лучше не использовать UDRE. Кстати , этот флаг имеет "неприятную" особенность он практически "всегда установлен". С момента сброса и до выключения питания. Увидеть его в ноль можно посылая сразу большой массив данных. И так как он старше TX.....

[_Pasha]

Ето винавр, проснитесь!

Код

#include <util/atomic.h>
void func(void)
{
  ATOMIC_BLOCK(ATOMIC_RESTORESTATE)
  {
   <Function's body&soul>
  }
}

ЗЫ в опциях обязательно включить -std=gnu99

Так например при обработке DS18B20 лучше не использовать UDRE.

Стало быть, Вы не умеете его готовить в условиях многозадачности?

[ReAl]

Кстати , этот флаг имеет "неприятную" особенность он практически "всегда установлен". С момента сброса и до выключения питания. Увидеть его в ноль можно посылая сразу большой массив данных. И так как он старше TX.....

Так это же отлично! И я этим радостно пользуюсь. Даже если другие прерывания задержат обработку UDRE и уже поднимется TXC, при освобождении процессора будет выполнен таки обработчик UDRE. Там я сброшу флаг TXC. И в самом же обрабочтике UDRE сниму его разрешение UDRIE при отправке последнего байта пакета. Таким образом, если до обработчика TXC вообще дошло, то это конец пакета.
Постоянное взведение UDRE тоже очень удобно, не нужно никаких танцев с тем, что первый байт пакета надо вручную затолкать в UDR, а уже остальные по прерываниям. Сформировал пакет и поднял UDRIE - данные пошли единообразным способом.

[ILYAUL]

Стало быть, Вы не умеете его готовить в условиях многозадачности?

Причём здесь мнонгозадачность и DS18B20. Если Вы возьмёте листок бумаги и посчитаете поведение USART при использовании UDRE в качестве прерывания для обмена с DS , то увидите что , если не изменяет память, на 9 байте начинает лезть ошибка приема ответа DS . Точне посмотрю дома в записях. Считали и не я один. А запрещать и разрешать его в таком случае смысла не имеет , если есть TX.

ReAl Так это же отлично! ......

и т.д.
При передачи сразу массива данных , нафинг он вообще нужен TXC ? Tолько что бы "красиво" в конце передачи массива узнать , что последний байт массива передали. Смысл? Всё равно же считаете переданные байты либо в ноль либо до какого-то значения.

Кстати , этот флаг имеет "неприятную" особенность он практически "всегда установлен".

А это я написал , так как топикстартер ещё не определился , что он вообще будет использовать и нигде не озвучивал свой замысел. А "неприятную" - как Вы видите я поставил в кавычках

[demiurg_spb]

При передачи сразу массива данных , нафинг он вообще нужен TXC ? Tолько что бы "красиво" в конце передачи массива узнать , что последний байт массива передали. Смысл?

Чтобы максимально быстро перевести драйвер RS485 в на приём и освободить линию после завершения передачи последнего байта.
UART используется и для симплексных каналов связи.

Или чтобы отключить передатчик для экономии батарейки например...

[ILYAUL]

Чтобы максимально быстро перевести драйвер RS485 в на приём и освободить линию после завершения передачи последнего байта.
UART используется и для симплексных каналов связи.

Или чтобы отключить передатчик для экономии батарейки например...

У Вас счётчик уже обнулился , зачем лишний обработчик прерывания