Нужно использовать различные обработчики прерывания в зависимости от случая. Например в начале программы
обработчик_пр = функция 1

а затем где-то по далее необходимо заменить его на
обработчик_пр = функция 2
Как это грамотно сделать в WinAVR?

ИМХО никак, т.к. в AVR адреса векторов фиксированые, только в ISR вызывать функцию по условию.

Определить указатель на функцию и поставить его в тело обработчика прерывания. Указателю между делом можно присваивать адреса разных функций. Издержки - команда CALL в теле обработчика прерываний. Зато задержка будет фиксированной и независимой от условий, как в случае switch или if/else.


Пример безжалостно выдран из FreeModbus.

+1
Кстати это очень удобно.

Оно, конечно, "само собой разумеется", но cur_isr = isr2; надо в атомарный блок взять.

Вызов функции по указателю внутри обработчика ведет к сохранению ВСЕХ регистров в стеке. И восстановлению их при выходе. Не быстрый обработчик получается

Векторизация прерываний. Например, int1
Soft_vectors.S

Просто добавьте в проект...

А как это сделать?

Ну хоть как-то. Не очень хорошо конечно, но что делать. Может есть способ лучше?
Правда, в мем случае, быстродействия достаточно.

Ммм... забыл добавить сохранение/восстановление SREG. Исправлено.

Что вам такого плохого сделали люди, что бы советовать им такую гадость???? Компилятор не просто так сохраняет r0, r1 и call-used регстры. Если их не сохранять то программа не будет работать.


Анатолий.

Про r0 r1 - такида, надо добавить, а вот call-used все-же должны отсутствовать по причине того, что обработчики прерываний у нас без параметров. Правильно?

А в своем теле функция никакие регистры не использует?
Даже r24?
ИМХО можно так делать, если вызываемые функции написать на ассемблере (проанализировать листинг) и самостоятельно сохранять регистры.
Кстати Ваш ужас реализуется куда короче и с правильным сохранением:

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

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

все эти варианты - не для любого AVR, разумеется...

Последний релиз сохраняет минимум пару лишних регистров. Если интересно, завтра выложу код.

Господа, Вы занимаетесь просто какой-то х.р..й ...
Вот это обертка в асм файле isr.s :


а вот это сам файл с обработчиками и примером:

Накладные расходы примерно 16МЦ... на фсе...

Кому х.р.я, а кому - сын ошибок трудных.
Т.е. получается, что __attribute__((interrupt)) и заставляет все call-used регистры сохранять внутри функции?

Как приятно иногда сказать: знатоки, блин.

Справедливости ради, такой подход имеет один побочный эфект,
прерывания будут разрешены еще до окончательного выхода из нашего
главного обработчика, НО, если прерывания идут с таким темпом что это
может вызвать переполнение стека, при других вариантах обработки мы просто
будем пропускать прерывания, так что такой вариант ИМХО вполне адекватный...

С __attribute__((interrupt)) прерывания будут разрешены сразу после входа в INT0_vect (INT0_vect), первой командой будет sei. C __attribute__((signal)) такого не будет, ИМХО правильнее __attribute__((signal,used)). К тому же вариант singlskv не универсален - переключаются векторы INT0, INT1, а если они нужны? В случае "просто" функций - компилятор выдаст предупреждение "misspelled interrupt handler" - из-за этого данный вариант мне показался не подходящим.
ИМХО в реале накладные расходы на if будут меньше push r30, icall и т.д.Не совсем понял иронию.

Не знаю, можно ли все, что я тут напишу, реализовать в GCC, но в IAR'е я бы делал так


Так меньше всего стека уйдет.

Что Ваш вариант в 20 тактов, что через icall в 21.
Тогда как банальный if(test) - 5 или 6 тактов - lds, and, breq.
ИМХО для 2 функций ни к чему. Навороты хороши не тогда, когда в комлекте ещё тормоза.

Дык я про то, что в моем варианте лишний стек не используется. По скорости это конечно тормоза.



А если их 22?

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


Сделаем необходимый инструментарий


WherePC заточено таким образом, чтобы возвращать 0 при вызове, а в параметре - адрес, с которого ее вызывали, исключая обработку возвращаемого значения.


Используя SubVector(имя_переменной_указателя_на_блок)


В итоге при первом вызове получаем адреса блоков кода в переменных sv[], но сами блоки не выполняем, по аналогии с setjmp, а при последующих вызовах - переходим в кратчайшие сроки к независимому блоку. В данном контексте это должно обеспечить выигрыш по сравнению со switch()

Просьба потестить эти примитивы и высказать мнения о применимости. Заранее спасибо.

Конечно там нужен signal а не interrupt.
На самом деле можно заюзать и несуществующие вектора,
и с учетом варианта обертки от Rst7 можно сделать вот так:
обертка в асм файле isr.s :

а вот это сам файл с обработчиками и примером:

а что если "раздеть" обработчик (__naked__), а на подставляемые функции наоборот, навесить сохранение контекста?

Не, там надо подставляемую функцию, к которой будут по указателю обращаться, делать (__naked__), а в нее заворачивать уже то, что нужно. С проктологической точки зрения - нормально двойной вложенный вызов. А с другой стороны оптимизация может выкинуть лишний call/ret.. надо попробовать

И потерять резервирование места под локальные переменные.

На мой взгляд, это отличный способ. Почему я так думаю - потому что:
1. Сохранение и восстановление всех регистров это всего лишь 128 тактов вход-выход в обработчик.
2. Как правило, необходимость в подмене обработчика прерывания происходит тогда, когда кардинально что-то меняется в работе программы, например - замена протокола обмена. В таких случаях логично предположить, что подменяемые обработчики "тяжеловесны" и по времени выполнения занимают гораздо больше 128 тактов.
3. Не надо гнаться за скоростью там где ее хватает, тем более в ущерб переносимости и читаемости кода.

Из чего делаем вывод - всего за 128 тактов получаем простой, прозрачный (легко читаемый), относительно безопасный, и прекрасно портируемый код на любую платформу.
Хорошо это, не очень хорошо, или совсем плохо - судить Вам ;>



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

при "сказочной" тупизне и кажущейся неоптимальности, вот какими плюсами сие обладает:
- Никакого гемороя с ассемблером.
- Тривиальная простота.
- Абсолютная безопастность - есть уверенность, что из обработчика выйдем всегда, и всегда выйдем правильно, нет риска неверного указателя в RAM.
- Возможность не только "подменять" обработчик, но и "параллельно" выполнять несколько обработчиков (например, по одному интерфейсу обслуживать несколько протоколов обмена).
- Легко портируемый.
- Нативно оптимизируемый - если все функции handler1, 2, и т.п. объявить в одном файле с обработчиком как static, то результирующий код получится эффективным - т.к. оптимизатор сделает свое дело сам.



Все шаманства с ассемблером и оптимизации "ради оптимизации" - это Зло. Лучше делать упор на функциональность, портируемость, читаемость. А вот когда действительно не будет хватать производительности и нет возможности поставить более шустрый кварц / камень, тогда (и только тогда) можно прибегнуть к извращениям на асм'е.

Есть несколько менее переносимый, зато более эффективный способ. В том смысле, что переписать эту субвекторизацию на другой асм другого процессора+компилятора можно, как можно и посмотреть реализацию структуры jump_buf и сделать переключатель, как у Rst7, привязанный к процессору+компилятору, но переписываемый под любую другую компбинацию. А тут - привязка к конкретному инструменту. Но раз в примере всё равно использован gcc, то... в нём можно взять адрес метки.
Во-первых, при этом можно WherePC сделать макросом, адрес вычисляется линкером:
И результат компиляции:

Во вторых, этот макрос при такой постановке вопроса не нужен вообще:
http://forum.sources.ru/index.php?showtopi...p;#entry1929594

В переводе на AVR-ский язык

И результат:

Да-а... На разных платформах количество переключаемого контекста настолько разное... У AVR- многовато


Спасибо!
Т.е. задача-то решается по-прежнему макросами(для совместимости), но адрес метки в gcc имхо самое не-кривое решение.

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

Но реально не применяю :-), как-то не жмёт пока обычный switch()...

Дык никто и не мешает в особо быстрых случаях подзагрузить таблицу в ОЗУ.
А во-вторых, реальное применение этого - как раз в статических сопрограммах с переопределяемой точкой входа. Т.е. кооперативная многозадачность, избавленная от тяжелого switch() - это КРУТО!