Почему-то я не смог обеспечить вложенные прерывания, если запускаю процессор
в 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 тоже.


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

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

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

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

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


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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

Попробую просто пояснить свою мысль...
Почти все кто переходит на АРМ с некоторым упорством достойным лучшего применеия пишут
свой обработчик IRQ(который замечу вызывается всегда)
и в этом обработчике всегда предусмотреннны все возможные фичи типа вызова вложенных прерываний итд...
только вот все эти фичи нужны в 1% проектов а пользуют их всегда...
Странная история...

Еще раз: не всегда.


Это единственная фича, для которой нужен свой обработчик.


Ну и что? Можно подумать, что это неподъемный труд - написать/скопипастить.

Труд вполне подъемный, но зачем ?
Зачем нужен весь этот лишний код в 99% проектов ?
Вот у меня под рукой есть маштабная(не маленькая) разработка на АРМ,
и вот эта фраза в коментах меня просто развеселила:

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

и при этом мой код на этой же задачке намного быстрее(а я и не пытался сделать вложенные прерывания)...

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


Из-за чего? При чем тут реентерабельность вообще?

Рвать волосы конечно не стоит, но допустим это обмен по i2c на скорости 400кбод
и проц работает на частоте 48Мгц.
400Кбод/9 = ~44Кбайт/сек (пиковая)
44Кбайт * "80 байт на источник"(только для выяснения причины)/4 = ~0.88Мбайт/сек (это только то что мы теряем на входе в прерывание)

дальше считать ?

я ни разу не понимаю почему нужно(обязательно) терять по 0,5мкс на кждый вход в прерывание...

Какая разница какой длины приемный буфер?
128 абсолютно разумное число.

За идиотский TWI опять-таки скажите спасибо атмеловцам. Прерываться ради него с частотой 44кГц неразумно, как и вообще прерываться с такой частотой.


Да не обязательно. Ну, дайте Вы своему TWI высший приоритет - получите нулевой оверхед. А 0.5мкс потратите там, где и так уходит 50, и добавка не покажется заметной.
Все в конечном итоге зависит от конкретной системы, нельзя утверждать, что вложенные прерывания - это абсолютное зло, так же как и нельзя утверждать и обратное.


О как! И в чем же состоит абсолют, хотелось бы мне услышать?

Мне вот почему-то кажется, что изменяемый размер буфера - гораздо более гибкое решение, Вы не находите?

В золотой середине между 1536 и 1.
Видители когда надо принимать много и быстро, от фиксированного буфера не уйти.
Вопрос сколько его сделать?
Чем меньше тем сложнее и соответвенно медленнее с этим работать, чем больше - тем выше расход памяти.

Большая, когда 100% пакетов в системе имеют фиксированный размер в 272 байта.

так уж и 100%? G.711-30?
пользуйте G.711-20 и будет щастье.

Видите ли, мне приходилось иметь дело с разными MAC'ами, и почему-то нефиксированный размер входного буфера их разработчиков не смутил.


100%. Не угадали.

Уже много раз их поминал..., однако это не мешает мне работать через него с мегой на ~ 150Кбод
и 400 тоже возможно(если не делать искуственный оверхед )
Я и не утверждаю что это абсолютное зло, просто для меня странными выглядят попытки заставить это работать,
пользоваться этим всегда, а реально воспользоваться премуществами 1 раз в жизни...

А мне вот наоборот приходилось снижать скорость до 20кГц, чтобы не слишком отвлекаться на прерывания от TWI.
Я уж не говорю о какой-то нездоровой прихоти инженеров Атмела, благодаря которой модуль влетает в underrun,
являясь мастером на синхронной в общем-то шине


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

У меня USB противопоказан. Типа, опторазвязка есть. Без нее от PC стоко гадости лезет...
А программный код почти написан. Максиму, еще столько же. Итогокило 10 в бинарнике. А вот ресурсы - нехилые. Одна wallpaper полмега откушывает. Вотщас срочно скачал jpeg и пытаюсь вычленить из этой кучи файлов только то, что надо для декомпрессии.И убрать всякие преобразователи в другие форматы. Чисто волпейперы на экран выводить.

Буду в этой библиотеке непонятное менять на понятное.

Ну дык почему же вы остановились на Atmel'е? Выбирайте такой MAC который наиболее подходит к вашей задаче.
Причем тут разработчики Atmel?

Вот если бы Вы взяли RealView вместо IAR, то он бы со свистом эти ресурсы упаковал (не хуже RAR'а, проверено).

Я же не против попыток, я не поддерживаю повсеместное использование спецобработчиков IRQ там где это нафиг не нужно...
З.Ы. TWI ИМХО, можно разуливать почти всегда, по крайней мере после приведения логики обращений(чтение/запись) c
мегой к варианту общения с EEPROM траблов больше нет. Ну а частота прерываний... это все-таки уже вопрос об общеем
построении системы...

По причине наличия у Атмела приличного SPI с DMA, и отсутствия LPC на момент начала проекта.


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

+1


Для мозга более полезно находить способы как обойтись без попыток.