DBGU у меня для всего используется. А это чем-то плохо? Ятак решил, что даже очень хорошо. Все дела по одному кабелю. И фирмаврь заливать, и в случае серьезного трабла - родной загрузчик - тут же. Тем более, свободных выводов у меня нет вообще.

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

А на ассемблере больше нет желания писать. А на сях только полгода боле-менее активно программирую. Спасибо Иару 4, а особенно 5.3.

В Вашем случае я бы выбрал USB - тоскливо будет заливать разросшуюся программу через UART. И родным загрузчиком тоже поддерживается.


Лиха беда начало

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

ИМХО, если сразу не получается добиться удовлетворительных результатов, то это прямая дорога к использованию CPLD/FPGA.
С софтом можно возиться бесконечно, но только при наличии экономической целесообразности.

Вот в том то и дело что они(Вложенные прерывания) пригодятся Вам 1 раз из 100
но при этом, написав обработчик умеющий работать с вложенными прерываниями,
он у Вас будет везде...

Нет, только на прерываниях с приоритетом меньше максимального. Да и не мешает ни разу - в любой системе можно разумно расставить приоритеты. О "бездумном", как бы сказал коллега zltigo, расточении памяти не упоминаю, ибо на самом деле оно несущественно в 99.9% случаев.

Ну я пока толком и не поробовал(на АРМ) но думаю что 8 сигналов частотой до 50(может 100)Кгц это вполне доступно...


Не очень понял как должен выглядеть обработчик IRQ что бы он зависил от приоритетов.

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

А зачем ? Ведь все равно уйдем обрабатывать самое приоритетное ?

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

Тогда это уже ловля "блох" и где-то в общем алгоритме допущена ошибка...
ИМХО, при одновременном возникновении прерываний из разных источников
тратить время на определение "кто приоритетьнее" это просто глупость...

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

А просто FIQ для этого не хватит ?
Ну или для Атмел просто IRQ как FIQ ?

"Просто FIQ" дает только один источник с более высоким приоритетом.

И ИМХО, этого достаточно...
А у атмел есть еще Fast Forcing...