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

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







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

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

Сегодня дошло, что в первом сообщении глупость. В таком порядке прерывания явно не должны вызываться.

Пните пожалуйста в направлении хорошего объяснения механизма работы прерываний (возможно, вложеных). На форуме перечитал много, но общее впечатление от тем осталось в стиле "Я попрыгал с бубном и у меня получилось".
Из даташита на процессор мало что понятно, слишком скупая информация.

UPD: Ну или можно пнуть в направлении книжки по проектированию систем на микропроцессорах.

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

А что конкретно непонятно?

IRQ0 _______/-------
IRQ1 __/--------------

Первым пришло низкоприоритетное прерывание, уже во время этого прерывания приходит высокоприоритетное. Что происходит в этом случае?
а) Прерывается выполнение IRQ1 и начинает выполняться IRQ0?
б) Или сначала завершается обработка IRQ1 и только потом начинает выполняться IRQ0?

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

Вы же ARM'ами заняты? Там всего два прерывания IRQ и FIQ. Зато есть VIC (vectored interrupt controller). Он обеспечивает обработку до 16 irq и одного fiq. Сам VIC обеспечинает возможность приоритетной обработки прерываний. Дело в том, как вы напишите собственно обработчик. Он может обеспечивать вложенные прерывания, а может нет. При любом варианте если приходит несколько прерываний, выполняется первым более высокоприоритетное.

Посмотрите, например, http://winarm.scienceprog.com/arm-mcu-type...ontrollers.html

Ухук.


В даташите информация о 32 и возможности работы нескольких FIQ (правда с оговоркой, что так лучше не делать и ограничиться одним). Или я что-то путаю...


Это если одновременно приходят? Одновременный приход видится идеальным случаем.
В моей платке получалось что главный таймер с приоритетом 12 умудрялся тормозить прерывания с приоритетами 7 и 10. Насколько я понял по временам - задержка как раз равна задержке на обработку в главном таймере. Т.е. все происходило по варианту (б).



Возможно что-то с этим связано.
Vectored - это объявленные через VICVectAddr[N].
Non-vectored - через VICDefVectAddr.
Так?

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

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

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

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

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

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

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

200мкс по ТЗ указано. Идея была в том, что я запускаю таймер, по прерыванию которого отправлю подготовленную посылку. Ожидание, естественно не через "for (i = 0; i < ...; i++);" сделано.
Резонатор стоит на 16МГц. Судя по настройкам uart'a эта частота умножается на 4 где-то внутри.
Benchmark'и не пробовал (только сейчас узнал о них).


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

ойой
может, флаг выставляете? по которому в основном теле что-то отправляется?

Сильно криво?
В SendByte никаких ожиданий, просто заталкивание посылки в выходной буфер.

UPD:

После поста на форум эта строчка начала "резать глаз".
Переписал в виде:


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

Тогда уж напишите:



никогда не бывает

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

P.S.: посмотрел на генерируемый код, вернул первый вариант. При размере BufferSize равного степени двойки он генерирует
add r0, r0, #1
and r0, r0, <mask>

если размер буфера равен степени двойки, то вот так не нагляднее?