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

Имеем некоторое прерывание, которое должно автономно обработать некоторый блок данных и по окончании работы сообщить об этом основному софту. Например, рассмотрим отправку пакета по УАРТ.
Основную массу действий (а именно, выборку очередного байта из памяти и его отправку) прерывание делает своими силами, но, вот беда: когда оно закончит, оно должно вызвать некоторую функцию, которая должна просигнализировать основной программе о выполнении задания. Вариант с глобальной переменной отпадает сразу, т.к. ситуация гипотетическая и сигналом в данном случае может служить семафор или еще какие-либо средство РТОС. Естественно компилятор, видя в прерывании вызов внешней, неизвестной ему функции, далает сохранение кучи регистров в стек. Однако, если отправляемый пакет состоит из 1000 байтов, то 999 раз контекст сохранится зря и только последний раз, когда работа завершена, действительно необходимо слить регистры в стек и вызвать функцию - сигнал. Я хочу, чтобы контекст сохранялся только 1 раз из 1000, когда уже ясно, что необходим вызов внешней функции.

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

Подскажите, плз, кто и как избавляется от подобного оверхеда?

PS: Интересует решение для компилятора ИАР.

Не понятно, для какой платформы вопрос.
Для AVR я делаю так:
1. Извлекаем из стека программ (CSTACK) адрес возврата.
2. Загружаем в CSTACK адрес вызываемой после прерывания функции.
3. Загружаем в CSTACK адрес возврата.

Данная функция вызывается в конце обработчика прерывания.

Для начала - я не вызываю никакой функции для приведенного примера. А действительно заканчиваю флагом/семафором. а в другой процедуре - анализирую флаг.

В одном случае (не РТОС) необходимо было после N одних прерываний выполнить другое прерывание. Для этого задействовал неиспользуемый таймер. Он постоянно считает так что переполнение уже обязательно возникает к моменту вызова. Я просто разрешаю прерывание, а в этом прерывании запрещаю его.

Для уменьшения оверхеда при вызове процедуры из прерывания (знающие люди пишут) необходимо чтобы вызываемая процедура находилась в том же файле где и обработчик прерывания. Хотя всётаки это и не рекомендуется делать.

Ещё один момент использую в IAR для уменьшения оверхеда.
Как обычно в прерывании используются volatile переменные. В связи с этим компилятор их обрабатывает без должной оптимизации. Поэтому иногда переприсваивание даст более грамотный код.
Например:

Я использую компилятор ICC. Но, возможно, это справедливо и для ИАР...
Если вызов функции из процедуры обработки прерывания делать ассемблерной вставкой, то сохранения кучи регистров - нет. Естественно, что сохранять регистры используемые вызываемой функцией (ту самую "кучу") и восстанавливать их нужно также ассемблерными вставками, соответственно до и после вызова функции.

Думал это очевидно, если задаю вопрос в ветке AVR.


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


Это понятно, но в случае с использованием ОС разместить функцию возврата семафора в одном файле с собственным прерыванием практически нереально.


Да, такой вариант пока кажется мне наиболее приемлемым...

Сорри, почему то показалось, что в ветке про IAR

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

рекомендуется, рекомендуется и
#pragma inline=forced


Не морочьте себе голову - лишние регистры НЕ сохраняются и многократно "семафор" не вызывается. Проблемы?

У AVR есть возможность отделить прерывание непрерываной передачи байт от завершения передачи. Используйте прерывание Data Register Empty для отправки очередного байта и TX Complete для сигнализации о завершении передачи пакета.

Чет сразу не обратил внимания , что вопрос про USART. А что Вам мешает устроить FIFO и вызывать функцию сигнализации только по переполнению буфера? Как раз и получится, если FIFO = 1000 байт - 1 раз из 1000. И только в том случае, если буфер действительно переполнится.

Похоже, дело просто в не ясном понимании задачи...

Естественно и в этом тоже - сначала неправильно глобально поставить задачу (1000 вызовов некой функции из одного прерывания!) а потом доблестно "c помощью ASM" и трюков ее решать - к сожалению встречается очень часто .

может вот это поможет - комменты на русском. Драйвер выдран из другого проекта, но полностью функционален

имхо автор всё очень внятно объяснил:



Вызов функции происходит не каждое прерывание, а сохранение контекста - каждое.

Это уже проблемы конкретного компилятора/платформы/оптимизации. Радикальное решение уже приводил - inline.

P.S.
Посмотрел, что творится на тестике c вызовом подпрограммы из обработчика пркрывания - честно говоря ужас . При этом для того-же ARM генерится много более разумный код. Явные проблемы у AVR с соглашениями о вызове функций - чрезмерное количество регистров отдается в безраздельное использование вызываемой функции. В результате реальные функции, в том числе и обработчик прерывания, их все и близко не использует и при вызове действительно жуткая картина.

z.

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

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

моё глубоко закоренелое ИМХО - не надо в прерываниях вызывать никакие функции. Либо уж накрайняк inline и описывать в одном модуле.
А лучше всего всё-таки по приёму кинуть байт в буфер, выставить флаг и функцию запускать снаружи, тайм-аут можно засекать по переполнению таймера.
А создавать себе трудности и потом героически их преодолевать - это неотъемлемая черта русского менталитета...

Уточнение - для AVR - обязательно, если это только не очень "тяжелый обработчик" и без того использущий массу регистров. Рассуждения на эту тему добавил в свой предыдущий пост.

"Обязательно" - это слишком категорично. Бывают проекты в которых необходимо обрабатывать очень частые прерывания, большая часть которых не требует сложных действий (а, значит и ресурсов процессора - тех же регистров). Возникает желание сэканомить на сохранении-востановлении контекста... Если "тяжелую" часть обработчика выделить в отдельную функцию и при её вызове самому позаботиться о сохранении-восстановлении регистров, то можно получить неплохой результат. Вот так это можно сделать в ICC

Код

void func(void) // Функция, вызываемая из процедуры обработки прерывания
{
...............
}

#pragma interrupt_handler proc_interrupt:x
void proc_interrupt(void) // Процедура обработки прерывания
{
  ............
  if(...)
  {
    asm("xcall push_lset"); // Вызов стандартной функции сохранения регистров
    asm("xcall _func"); // Вызов функции void func(void)
    asm("xcall pop_lset"); // Вызов стандартной функции восстановления регистров
  }
  ............
}

при этом, при входе(выходе) в(из) процедуры обработки прерывания proc_interrupt транслятор генерит код, сохраняющий(востанавливающий) необходимый минимум регистров. Если, ассемблерные вставки заменить на с-ишный вызов функции func(); , то транслятор генерит код сохраняющий(востанавливающий) все регистры.

В данном случае идет речь о чисто сишных + расширения компилятора возможностях. О ASM и его смесях, естественно, разговор был-бы другой.

Вообщем, есть достаточно простой метод. Без асма, но надо проследить один момент (об этом чуть позже). Я обычно поступаю следующим образом



Главное тут - проверить, чтобы проверяемые и устанавливаемые флаги были в младших адресах пространства ввода-вывода, чтобы компилятор мог пользоваться SBIC/SBIS для проверки и SBI/CBI для манипуляций. Тогда можно не сохранять контекст в диспечере прерываний - эти комманды не портят SREG и другие регистры.

Вот такой код получается у диспечера:


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

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