не суть важно, по условию задачи нам нужно не пропустить ни одного INT0. О всех остальных автор умолчал ;> Преполагаем что они не важны и их пропускать можно.
Заблуждение. И Вы сами это прекрасно понимаете, но не хотите сдаваться
Гарантии достигаются за счет опять же двух составляющих:
- минимальный период;
- макс время обработки
каждого прерывания.

Если время обработки == 0, гарантия 100%.
Если период стремится к бесконечности - гарантия 100%.

ну а для всех остальных случаев гарантии оцениваются/считаются.

Раз уж разговоры вышли за рамки задачи, то я намеренно ушел и от поминания конкретного прерывания.

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

Ну очень хорошая программа - научите писать такие

Гарантия это НЕ ВЕРОЯТНОСТЬ. Гарантия либо она есть, либо ее НЕТ. Вот об отсутствии гарантий и веду речь.

гм?! с этим утверждением я не спорю и не спорил.


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


в теории можно всё


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

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

В остальных прерываниях ставите разрешение прерываний (sei) как можно ближе к точке входе, да и всё.

Однако, поскольку период появления INT0 может быть достаточно маленьким, всего 4 мкс, эффективность работы вашей сишной программы (в смысле загрузки процессора) находится под большим вопросом.

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

или нет

А вот это точно.

А что не так с примерами-то? Они всего лишь показывают, что ресурса процессора хватит на обработку всех прерываний в real-time.


Я не спорю, а утверждаю, что задачу автора ветки


можно решить двумя путями:
1) разрешать прерывания (sei) сразу на входе в обработчиках таймеров.
2) сократить латентность всех без исключения обработчиков до (Fclk / 250kHz) - (2 * Tcall + 1) тактов.

Устал я об одном и том-же....

Не двумя путями, а ЕЩЕ двумя путями

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

Все.

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


Эта возможность пресекается. Это не ARM, здесь очень прогнозируемый КП.


посмотреть листинги обработчиков, которых всего три и посчитать время их выполнения. Вынести обработку в основной цикл программы. Что мешает обработчики того же таймера построить как-то так:

Прям операционка получилась...кооперативная(:-).

почитайте, разрядитесь
http://ru.thedailywtf.com/Articles/Proklyataya-dverb.aspx

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

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

Попробую объяснить на пальцах.

1. Возмите у жены/сестры/матери сантиметр (хотя, там все 150 сантиметров! Почему они его сантиметром называют -- отдельный вопрос.) -- это будет шкала времени. Пусть 10 сантиметров (длины) будут равены 1 мс.

2. Теперь прикиньте, сколько времени потребуется для обрабтки INT0. Допустим, 2 мс. Эквивалентная длина 20 сантимов. Нарежьте несколько полосок цветной бумаги (или провода) этой длины. Из условия задачи мы знаем, что INT0 прет с частотой 250 кГц. Значит, INT0 будет возникать через каждые 4 мс. Теперь, разложите цветные полоски на шкале времени через каждые 40 сантиметров. Это время занято.

3. Проделайте те же действия с плолосками бумаги другого цвета для проерываний от таймеров. Разложите "таймерные" полоски на свободном месте, с учетом примерной периодичности поступления этих прерываний.

4. Если есть еще какие-то процессы -- добавьте еще бумаги.


Понятно, что какие-то из полосок придется сдвигать вправо по оси времени. Сейчас главное уяснить два вопроса:

1) А хватит-ли вообще процессорного МК времени для обработки прерываний?
2) То, на сколько может сдвинуться полоска (обработка), это будет дрожжание обработчика -- ждиттер. Нужно прикинуть, оценить величину этого дрожжания.

Если после раскладки полосок остается еще достаточно времени (например более половины) и допустим джиттер, то задачу впринципе можно решить. Если плоски наезжают друг на друга, разумеется, -- нет.


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

ЗЫ
Для прерываний, которые не привязаны жестко ко времени (у которых полоски бумаги допустимо сдвигать) можно предложить следующий способ обработки. Обнаруженное, но необработанное событие (postpone) можно зафиксировать не в переменной-флаге, а в переменной-счетчике. Т.е. возникло прерывание, уходим в обработчик, инкрементируем счетчик, выходим. Все! Достаточно быстро, ничего лишнего, никакой обработки. Обработка будет потом.

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

Тут правда есть подводные камни. У AVR отсутствуют команды, котрые позволяют производить операцию инкремента/декремента в памяти. Значит, что бы декрементировать счетчик нужно сначала переменную считать в регистр, затем декрементировать, а после этого записать обратнно в память. Т.е. нарушается принцип атомарности операции. Что произойдет, если мы считали переменную в регистр, а в это время произошло прерывание, где эта же переменная успешно будет инкрементирована. Получается так, что после окончания прерывания, значение в регистре будет не верным. картина Репина "А мужики-то не знают!"

Для решения этого придется эту переменную либо размещать в регистре (расточительно и небезопасно), либо обрамлять тройку команд (ld-dec-st) командами разрешения/запрещения прерываний. Т.е. нужен нам нужен какой-то семафор. У АВР есть хорошая атомарная команда swap. Можно поиграться сней. Но я, кажись, увлекся... Извините

Вот кстати ещё тема с похожей тематикой (касающаяся гимора с отстутствием к AVR как таковых приоритетов прерываний)

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

К большому сожалению считывание импульсов с энкодера несколько сложнее чем просто суммирование импульсов, об этом на форуме уже проводилась дискуссия. На более развитых нежели AVR контроллерах обработчик энкодера железно включен в перифирию, однако у AVR к сожалению этого нет. Приведу код обработчика INT0

Обработчик прерывания от Timer1 должно прерываться прерыванием от ISR0.
Как ли это делается в WinAVR?