Почему-то я не смог обеспечить вложенные прерывания, если запускаю процессор
в SVC mode. __nested подвешивает тогда прерывания намертво. И никаких тебе приоритетных прерываний.

Таким образом только USER or System.

А без вложенных прерываний - жизнь не мила. Символы RS232 приемника теряются.

Но где-то мелькало сообщение, что WinCE запускает программы юзера в SVC mode. (Товарищ, который об этом писал из пользовательской программы менял таблицу распределения виртуальной памяти и вообще, делал все, что хотел.)

Возможно, если вход-выход из IRQ писать отдельно и читать руками вектор прерывания, то может и можно что-то сделать? И стоит ли?
А то уж очень не хочется ломать прямую загрузку вектора из АИК. Типа, одна команда, практически.

И чем так плоха System mode?

Для UART'ов есть PDC. Дергать процессор прерыванием на каждый байт, я бы сказал, неразумно.


Для начала нужно разобраться, а стоит ли огород городить (см. выше).
Естественно, вложенные прерывания обеспечить можно. Не знаю насчет __nested (IAR, как я понимаю?), но уж руками точно. И прямую загрузку вектора ломать для этого не понадобится.


Ничем - нормальный привилегированный режим.

Было бы нагло начинать писать программу с PDC для DBGU. Тем более, из средств отладки - только 4 светодиода на плате.
(Но попробую. По крайней мере приемник. У звука сделал большой буфер, чтобы пореже дергал (раз в 16 мс). А он больше 100 микросекунд иногда забирает. )

Просто чукче некогда было учить матчасть. А примеров от Атмела с использованием пряиого чтения из АИС не нашел. Все норовят свой обработчик вставить и руками АИС читать. А __nested меняет IRQ на SYS. А у меня по жизни майн был в SVC. Почему? Supervisor как слово красивше. А обработчики сишные так и оставались в IRQ до конца. А все примеры норовят этот IRQ поменять на что-то другое. Видимо, стек экономят. Других причин не увидилось. А мне стека не жалко.

Если делаются вложенные прерывания, то IRQ, естественно, надо на что-то менять. SYS - единственно верный универсальный вариант.

Вот как раз про "естественно" я еще не дочитал. Вернее фраза "The ARM core enters Interrupt mode, if it has not already done so" намекнула, что IRQ может прерываться IRQ. И я забил на дальейшее чтение.

(Просто чтобы обеспечить работу всех этих меню, wallpapers, всяких картинок, шрифтов приходится кучу программ в дельфях писать. Т.е. программированием вообще не занимаюсь. Занимаюсь расставлением неимоверной кучи данных по отсекам. Спасибо борланду.)

А DBGU именно для отладки используется ?
Конечно нужно использовать PDC, правда у DBGU нет очень удобного для этого флага TIMEOUT.
Но в принципе, если речь об отладке, то прерывания DBGU вобще не нужны,
достаточно задать буфер приличной длины и опрашивать чего там напередавалось в каком-нить
переодическом прерывании(если есть) в системе.
ИМХО, это совсем не случай для вложенности прерываний...

Да, Атмелы пожмотились почему-то на такую ерунду

ага, у мня в проекте где много интерфейсов(то есть почти все какие есть в SAM7А3) из-за этого отдельные линии квитирования

Если автор топика не против,то задам свой вопрос почти по теме..
помница Вы упоминали о ~2 случаях использования вложенных прерываний на АРМ
очень просто интересно, я несколько раз порывался написать свои хитрые обработчики с
возможностью вложенных прерываний и так их и не написал тк каждый раз был
придуман алгоритм который будет лучше без всяких вложенных прерываний,
ну и на обработчиках IRQ я тоже не хило при этом экономлю...
Вот чисто для себя решил что IRQ только "последовательно"(но короткие обработчики),
а если нужно чего-нить супербыстрое то FIQ и 1 источник...

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

Например, в LED экране на SAM7X:
- 3 прерывания (2 таймера и SPI) обеспечивают развертку, очень короткие, имеют высший приоритет (т.к. тайминги жесткие, развертку ломать нельзя).
- прерывание от EMAC'а имеет приоритет на единицу ниже: поток здоровый (~80Мбит/с в обе стороны), реагировать нужно быстро.
- перывание от UART'а.
- прерывание от PIT.

Еще в проекте измерительного стенда примерно со столь же тяжелым раскладом.
Короче, вложенные прерывания оказываются востребованы тогда, когда нужно разрулить большое число источников с низкой латентностью. В большинстве же случаев действительно достаточно обычных IRQ или IRQ+FIQ.

P.S. Пользуясь случаем, хочу послать луч ненависти инженерам фирмы Атмел за фиксированный размер приемного буфера EMAC в 128 байт.

рулить разверткой - понятно, там это главная реалтайм задачка...
Измерительтный стенд говорите....
Влияние "цифрового" джиттера на измерение частоты ?

Мы это стараемся разруливать с помощью дополнительных процов...переферийных...

На самом деле, одна из самых мелких по сложности и занимаемым ресурсам. Но да, реалтайм и все тут.


Нет, просто монстрическая система из-за большого числа источников данных.


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

А вот здесь совсем не соглашусь...
Доп проц конечно деньги, но очень небольшие по сравнению с основным(1-1,5$ +)
если нужен реальный реалтайм то других вариантов практически нет
к примеру, опрос N входов с определением частоты на них
там цифровой джиттер самое важное, сделать его разумным при наличии других интерфейсов невозможно...
Ну вот пример, можно ли на АРМ7 который подключен к ПЦ через USB(961Кбод) и 3 x RS232(115Кбод)
опрашивать 4-8 сигналов частотой 10Кгц ?
А при наличии переферийной меги8 уже можно...

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


Уточните, что значит "опрашивать сигнал частотой 10Кгц".

А, например, если прошивку обновить в периферийном контроллере надо - уже проблема. Сделать мостик в основном, да наворотить софт для PC, который соберет/разберет несколько прошивок в один файл (ибо делать больше одного - не уважать клиента) и т.п.

Ну тоже можно(и я над этим думаю для младших чипов как перферийных) при ограничении использования
инструкций с набором регистров.
Опрашивать с частотой 20Кгц+, ну и соответственно уметь "поймать" меандр с частотой 10Кгц(за 1 сек например).
Вот здесь Вы очень правы, то есть как бы и все инструменты есть(для ПЦ), но как
только задумываешься их прикрутить для реалтаймовских вещей то сразу желание пропадает...
Ну наверное для этих частей просто должны быть прошивки которые "никогда" не меняются...

Объяснить это желание компилятору только затруднительно Да и все пересылки данных автоматически пострадают.
Лучше тогда не использовать прерывания... да и ARM тоже.


Никогда не говори "никогда" Если в системе что-то может меняться, то оно обязательно потребует изменений.