Таймер и прерывания, Хочу понять принцип работы Опции

[whiteTigr]

Среда разработки: Keil.
Микроконтроллер: lpc2367.

Есть таймер, генерирующий прерывания. Таймер работает по принципу "Отсчитал до нужного MR, прервался и остановился".
Процедура, на которую он прыгает при прерывании переопределяемая.

Код

void InitTimer()
{
  /* Initialize Timer 2 */  
  PCONP |= PCTIM2;

  PCLKSEL1 &= ~(3 << PCLK_TIMER2_OFFSET);
  PCLKSEL1 |=  (1 << PCLK_TIMER2_OFFSET);

  T2PR = 63; // 1 mks  
  T2MR0 = 99; // 100 mks
  T2MCR = 7; // interupt, reset, stop  

  VICIntEnClr = INTTIM2;
  VICVectAddr26 = (unsigned long)Timer2Handler;
  VICVectPriority26 = 10;

  T2TCR = 0x01;

  VICIntEnable += INTTIM2;
}

Код

__irq void Timer2Handler()
{
  if (OnTimerInterupt)
    OnTimerInterupt();  
  
  T2IR = 0x01;
  VICVectAddr = 0;  
}

Код

typedef void (*CallBackFunction)(void);
CallBackFunction OnTimerInterupt = 0;

Допустим, я назначаю на прерывание функцию, которая выполняется около 1мс (пусть будет Func1).
При прерывании в этой функции запускаю этот же таймер, переопределяя OnTimerInterupt на функцию с небольшим временем выполнения (пусть будет Func2), и настраиваю таймер на срабатывание через 100 мкс.

Вопрос: как поведет себя выполняющаяся функция Func1, при следующем прерывании таймера (в котором вызовется Func2)?

[sergeeff]

Как-то я с VIC'ом не работал, только с AIC'ом. При невложенных прерываниях, пока не отработает текущий обработчик, следующий не вызывается. Посему все обработчики пишем как можно короче и шустрее.

[whiteTigr]

Как-то я с VIC'ом не работал, только с AIC'ом. При невложенных прерываниях, пока не отработает текущий обработчик, следующий не вызывается. Посему все обработчики пишем как можно короче и шустрее.

И в главном цикле while(1) анализируем выставленные флаги в прерываниях...
Мне вот сказано, что я должен ответить по RS485 через 200мкс после окончания посылки ко мне. Т.е. делается прерывание на прием байта, по последнему байту пакета запускается таймер на 200мкс, по прерыванию от него посылается ответ.
Прерывание на прием набивает байты в пакет сразу же (нужно же определять конец пакета) - уже не сильно короткая получается, но и вынести из прерывания, по-моему, не получится.
Прерывание по таймеру должно затолкать подготовленный для отправки пакет в выходной буфер.
И получается что прерывание главного таймера (громко сказано "главного", приоритет у него наименьший) на обработку кнопок и дисплея мешает нормальной работе системы. Вот при сокращении главного таймера до Counter++ (и анализа Counter'a в while(1)) все заработало нормально.

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

P.S.: чувствую, что задаю настолько глупые вопросы, что стыдно становится.

Сообщение отредактировал whiteTigr - Aug 16 2011, 10:37

[sergeeff]

И в главном цикле while(1) анализируем выставленные флаги в прерываниях...
Мне вот сказано, что я должен ответить по RS485 через 200мкс после окончания посылки ко мне. Т.е. делается прерывание на прием байта, по последнему байту пакета запускается таймер на 200мкс, по прерыванию от него посылается ответ.

Ну и на кой выжидать 200 мкс после последнего байта, если у вас и так полно всякой работы? Кстати, у вас процессор на нормальной частоте работает? Какие-нибудь benchmark тесты не пробовали?

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