Как перейти к началу функции по внешнему прерыванию?, подробнее внутри Опции

[Зверюга]

Господа есть код в CodeVision примерно такой:

Код

void  loop()
{
for (i=0;i<360;i++)
  {
     .................      
  }


}

void afterINT()
{
.....
}


void main ()
{
  while (1==1)
    {
      ......
       loop();
      .....
   }
}

Как сделать чтобы по внешнему прерыванию от пина AVR функция loop завершала свою работу? выполнялась функция afterINT(), после чего вновь запускалась функция loop(). Пишу в CodeVision, но буду рад примеру и в WinAVR.


И еще - в ATMEGA32 INT0, INT1 и INT2 чемн-ниьбудь отличаются?

[SSerge]

Рассуждай токмо о том, о чём понятия твои тебе сие дозволяют. Так: не зная законов языка ирокезского, можешь ли ты делать такое суждение по сему предмету, которое не было бы неосновательно и глупо? (с) Козьма Прутков. Афоризмы

Понятия дозволяют. Я законы языка ирокез С ещё на PDP-11 изучал. И с работой setjmp/longjmp тогда же разбирался.

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

Чтобы из любой - это гораздо сложнее. Но Вас же не удивляет что любая (некооперативная) RTOS может передать управление другому процессу после того как текущий был прерван прерыванием?
Разбираемый сейчас случай попроще будет. Требуется поведение программы типа "всё бросить и вернуться на заранее подготовленные позиции", как раз для такого эти функции и предназначены.
В популярных учебниках тему setjmp/longjmp предпочитают не затрагивать, вот народ про них почти ничего и не знает.
Попробую рассказать что знаю, с некоторыми упрощениями.
Функция setjmp() всего лишь запоминает в специальном буфере содержимое нескольких регистров, указатель стека и счётчик команд (адрес возврата, лежащий в стеке). Эта информация потом, при исполнении longjmp(), позволяет восстановить состояние программы таким, словно только что произошел возврат из setjmp(). Отличается только возвращаемое значение, setjmp() возвращает 0, а longjmp() возвращает свой второй аргумент. Это позволяет понять откуда попало управление в этот раз.
Разумеется, восстанавливается далеко не всё, скажем если программа успела изменить глобальные переменные то эти изменения не будут откачены назад, ну так это-то уже в руках программиста, и он может это предусмотреть, если бывает нужно "прибрать за собой".

Поскольку longjmp() переставляет указатель стека на прежнее место, то существует естественное ограничение на её применение: состояние той части стека, которая существовала на момент возврата из setjmp() не должно изменяться до выполнения longjmp(). Другими словами, не должно быть выхода из функции или блока, содержащего setjmp().

А с учетом архитектуры AVR и имеющейся реализации этих функций не вижу никаких препятствий для примения longjmp() прямо из обработчика прерывания.
Реализацию в CodeVision надо проверить, но скорее всего и там будет работать. Примерно так (для IAR):

Код

jmp_buf jbuf;

int foo()
{
   if( setjmp( jbuf ) )
   {
      // исполняется только после перехода по longjmp()
      //если переход делать прямо из обработчика, то прерывания останутся запрещёнными
      __enable_interrupt();
      afterINT();
   }
   else
   {
      // исполняется после возврата из setjmp()
   }

   for(;;)
   {
      loop();
      //........
   }
}

#pragma vector=INT0_vect
__interrupt void INT0_isr(void)
{
   longjmp( jbuf, 1);
}

[zltigo]

Требуется поведение программы типа "всё бросить и вернуться на заранее подготовленные позиции", как раз для такого эти функции и предназначены.

Ну насчет все грубо бросить в непонятном состоянии И ЗАБЫТЬ НА ВСЕГДА, это еще большой вопрос о допустимости такого.

Попробую рассказать что знаю, с некоторыми упрощениями.

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

Разумеется, восстанавливается далеко не всё...

..И при прерывании/восстановлении в

..уже в руках программиста...

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

А с учетом архитектуры AVR и имеющейся реализации этих функций не вижу никаких препятствий для примения longjmp() прямо из обработчика прерывания.

Ага, самая примтивная архитектура и железо - скомпенсировали отсутствие RETI и типа все...
А на ARM слабо?

Реализацию в CodeVision надо проверить...

Ага, проверить, и при получении свежего компилятора проверить...

, но скорее всего и там будет работать. Примерно так (для IAR):

Ну и чего добились этими финтами? Эквивалент внесения afterINT() в обработчик прерывания + непонятные эффекты (особенно в случае прерывания afterINT()) + опасно переносимый или гарантированно не переносимый код.
Нет это не "руками хирурга" сделано
И даже перечисленные лично Вами подводные камни, камня на камне не оставляют от Вашего-же утверждения

Вообще-то для таких "фокусов" придуманы функции setjmp() и longjmp().

с которого все и началось...