В какой моде запускать main?, Вот в чем вопрос. Опции

[DpInRock]

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

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

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

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

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

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

[DpInRock]

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

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

[singlskv]

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

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

[aaarrr]

Конечно нужно использовать PDC, правда у DBGU нет очень удобного для этого флага TIMEOUT.

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

[singlskv]

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

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

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

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

[aaarrr]

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

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

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

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

[singlskv]

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

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

Еще в проекте измерительного стенда примерно со столь же тяжелым раскладом.

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

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

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

[aaarrr]

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

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

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

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

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

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

[singlskv]

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

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

[aaarrr]

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

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

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

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

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

[singlskv]

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

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

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

Опрашивать с частотой 20Кгц+, ну и соответственно уметь "поймать" меандр с частотой 10Кгц(за 1 сек например).

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

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

[aaarrr]

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

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

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

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

[singlskv]

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

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

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

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

[aaarrr]

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

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

[singlskv]

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

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

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

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

[aaarrr]

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

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