Замена обработчика прерывания в WinAVR Опции

[PhX]

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

Код

ISR(INT1_vect)
{
обработчик_пр
}

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

[MrYuran]

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

Код

typedef void ( *pxTBFunctionHandler ) ( void );  // объявление типа указателя на функцию

pxTBFunctionHandler pxMBPortCBTimerExpired; // объявление указателя на функцию

pxMBPortCBTimerExpired = (void*)xMBRTUTimerT35Expired; // инициализация указателя



interrupt (TIMERA0_VECTOR) prvvMBTimerIRQHandler( void )
{    
    ( void )pxMBPortCBTimerExpired(  );
}

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

[PhX]

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

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

Код

//Прототипы функций
void isr1(void);
void isr2(void);
//Указатель на функцию обработчик
void (* cur_isr)(void) = isr1;


void isr1(void)
{
// тело обработчика 1
}

void isr2(void)
{
// тело обработчика 2
}

ISR(INT1_vect)
{
(* cur_isr)();
}

int main(void)
{
// ля-ля тополя...
...
cur_isr = isr2;
...
}

[ReAl]

Код

int main(void)
{
// ля-ля тополя...
...
cur_isr = isr2;
...
}

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

[PhX]

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

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

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

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

[defunct]

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

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

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



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

Код

ISR()
{
    prefix stuff

    if (...)
      handler1();
    else if (..)
      handler2();
    else
      common_handler();

   postfix stuff
}

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



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