[zltigo 1]

Любопытно, чем сохранение контекста не удобно?

Удобно, когда надо и не удобно, когда не надо. Не удобно, когда сохранение, вместо переключения банка регистров,как было у старичка ARM7. Ну упрощенная штука Cortex-M3, подогнанная под некую "самую массовую" практику использования и за счет упрощения поддающаяся разгону - хотите попугаев, они есть у нас. Тот-же контролер прерывания внесли в ядро, сделали за счет этого проще и быстрее, добавили (точнее в результате упрощения получили на халяву) мечту бездумных программеров - вложенные прерывания , но в результате все стало больше похоже на "ешьте, что дают".

[SBE 1]

Удобно, когда надо и не удобно, когда не надо. Не удобно, когда сохранение, вместо переключения банка регистров,как было у старичка ARM7. Ну упрощенная штука Cortex-M3, подогнанная под некую "самую массовую" практику использования и за счет упрощения поддающаяся разгону - хотите попугаев, они есть у нас. Тот-же контролер прерывания внесли в ядро, сделали за счет этого проще и быстрее, добавили (точнее в результате упрощения получили на халяву) мечту бездумных программеров - вложенные прерывения , но в результате все стало больше похоже на "ешьте, что дают".

 

Уход от банка регистров при переключении это плата за вложенные прерывания. И если переключение контекста при этом происходит не медленнее чем на ARM7, то что потеряли? А вложенные прерывания с гибкой настройкой ИМХО немалая ценность, без этого рассуждения об латентности это про малоинтересный случай с одним прерыванием.

M3 не упрощенная (много в ней частей проще чем в ARM7?), а получше заточенная под встроенные применения архитектура (в отличие от ARM7, в котором совсем об этом не думали, а начали применять что было).

Контроллер прерывания в ядре помимо скорости, дает еще стандартизацию модели прерывания, тоже плюсик на пути к "стандарту де факто" для ядра МК.

[zltigo 1]

Уход от банка регистров при переключении это плата за вложенные прерывания.

Спасибо, а можно было не платить? Нельзя? Мне жаль :(

А вложенные прерывания с гибкой настройкой ИМХО немалая ценность

Для лобового программирования в стиле Super Loop c кучей длиннющих обработчиков прерываний - несомненно! А можно я так не буду делать?

Много в ней частей проще чем в ARM7?

На мой взгляд все.

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

Нет заточенная, а упрощенная, что не одно и тоже.

Контроллер прерывания в ядре помимо скорости, дает еще стандартизацию модели прерывания, тоже плюсик на пути к "стандарту де факто" для ядра МК.

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

[SBE 1]

Спасибо, а можно было не платить? Нельзя? Мне жаль :(

 

Для лобового программирования в стиле Super Loop c кучей длиннющих обработчиков прерываний - несомненно! А можно я так не буду делать?

 

На мой взгляд все.

 

Нет заточенная, а упрощенная, что не одно и тоже.

 

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

А вы знаете как с банками и вложенные? Причем с банками то по факту в ARM7 вход в прерывание не быстрее, так где платим? :)

Про стиль, SuperLoop и т.п. скромно промолчу. Ключевое слово "длиннющий", вопрос масштаба, который в это понятие вкладывается, и в конечном счете времени реакции в системе со многими прерываниями разного приоритета (добро пожаловать в реальный мир :) ). NVIC позволяет этот масштаб перевести в другой порядок, чем в ARM7 (ну по крайней мере когда прерываний больше 2-х) .

 

Про упрощение дискуссия конечно субъективная, но "все" как-то слишком категорично. Особенно, если "ничего" более правильный ответ.

[zltigo 1]

А вы знаете как с банками и вложенные?

И знать не хочу :). Но тем не менее ручками push/pop получается немногим хуже автоматического сервиса. Короче делается просто.

Причем с банками то по факту в ARM7 вход в прерывание не быстрее, так где платим? :)

Львинную долю тактов ARM7 гипотетически съедает могущая попасться длиннющая в 20 тактов команда групповой пересылки всех регистров.

Ее в принципе, можно не использовать. Чистые потери контроллера прерываний для FIQ 7 тактов за это мы получаем 5 регистров, а не всего пару на автомате запушированных. Затем в M3 из прерывания нужно не только войти но и выйти. Это ЕЩЕ 12 тактов. При этом мы за эти такты, повторяю, получаем всего пару регистров общего назначения, а не как у FIQ пять. Давайте еще добавим для корректнго сравнения push и pop банкированных регистров. Кто сказал "быстрее"?

Что получаем? Несколько тактов в Corteх-M3 за счет того, что контроллер в ядре, естественно, экономится. Длинные, команды похерили. Все, в остальном на push/pop в тактах проигрыш. По времени подняв частоту под два раза в результате более получаем терпимые времена. Потенциальное ускорение от внесение контроллера в ядро С ЛИХВОЙ ушло в качестве платы за упрощение контроллера.

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

Меня всегда умиляла замена понятия время реакции понятием количество тактов до выполнения первой команды обработчика прерывания. Толку от того, что я быстро ввалюсь в обработчик, а потом начну пушировать регистры мало. Толку от того, что я быстро ввалившись в обработчик НО НЕ УСПЕВ ВЫДАТЬ ОТВЕТНОЕ ВОЗДЕЙСТВИЕ буду прерван вложенным прерыванием на фиг знает какое время, ВООБЩЕ НИКАКОГО. Какое такое, говорите "время реакции"? "Добро пожаловать в реальный мир",.....? Это Вам следует прежде всего задуматься о реальном мире, а не о своем представлении о нем. Я в реальном мире живу с середины 80x, и все мнимые радости вложенных прерываний познал еще в зеленом возрасте на Intel 8080/86/88, где они организованы были так-же просто, как и ныне в новейше-простейшем M3.

Про упрощение дискуссия конечно субъективная,...

В минимальнейшей степени.

[klen 1]

.. в реальном мире живу с середины 80x, и все мнимые радости вложенных прерываний познал еще в зеленом возрасте на Intel 8080/86/88

 

середина 80х - это гдето так 75год, а выпустили 8080 в апрель 1974. Это че ? они доступны в СССР'е были сразу? и лет Вам было 15. Ну наверно меется девяностые (80-89гг), я так думаю.

 

zltigo прав - иногда можно так организовать обработку прерывания что ничего особо и не сохранять в стек - просто флаг поставить а остальное - уже отложенная обработка прерывания, вот тут мненя и бесит - ну че мешало сделать механизм отменяющий автоматическое сохраниеие - НИЧЕ НЕДЕЛАТЬ ВСЕГДА ПРОЩЕ ЧЕМ ЧТОТО ДЕЛАТЬ. как то привык на асме сам решать что пушить а что нет ;) чуство что ты на собаччем поводке. а в остально мне нравится кортекс. Вот собираюсь pic32 (ключевое слово mips m4k) пробывать - должна ж гденить на свете быть правда ..... тока опять окажется ядро гуд - переферия шит, или наоборот иди все фулл шит ;)

 

тяжела жизнь землянина - много альтератив, и все г... и эз него нада лепить каменный цветок

[zltigo 1]

середина 80х - это гдето так 75год,

Что?!!! Что за арифметика? Середина 80x это ПОСЛЕ восьмидесятого, перед 90-ым. Итого, это 85, а не 75. Работать начал с ними в 84.

[aaarrr 69]

...При этом мы за эти такты, повторяю, получаем всего пару регистров общего назначения, а не как у FIQ пять.

Почему пару, если получаем те же пять штук: R0-R3 + R12?

[zltigo 1]

Почему пару, если получаем те же пять штук: R0-R3 + R12?

Виноват :(. Не твердо усвоил :(. Практики пока нет :(.

[vallav 0]

И знать не хочу :). Но тем не менее ручками push/pop получается немногим хуже автоматического сервиса. Короче делается просто.

 

Львинную долю тактов ARM7 гипотетически съедает могущая попасться длиннющая в 20 тактов команда групповой пересылки всех регистров.

Ее в принципе, можно не использовать. Потенциальное ускорение от внесение контроллера в ядро С ЛИХВОЙ ушло в качестве платы за упрощение контроллера.

 

Извините, а какая связь между упрощением контроллера и тем, что в кортексе запихивают автоматом в стек 5 регистров общего назначения?

Кстати, непонятно зачем нужно целых 12-5=7 тактов, чтобы запихнуть в стек адрес возврата и состояние процессора.

Идеал в этом смысле был ADIшный ADSP218x. У него, чтобы перейти от синхронного запроса прерывания к обработчику, требовался всего 1 такт.

 

 

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

 

Так это - так называемые преимущества RISC архитектуры.

Которая совершенно не годится для контроллеров и давно устарела для байтовых мельниц.

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

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

[SBE 1]

Львинную долю тактов ARM7 гипотетически съедает могущая попасться длиннющая команда групповой пересылки всех регистров.

Ее в принципе, можно не использовать.

А за оставшиеся такты мы получаем чистый банк регистров в том числе и общего назначения, а не всего несколько на автомате запушированных. Затем в M3 из прерывания нужно не только войти но и выйти. Это ЕЩЕ 12 тактов. При этом мы за эти такты, повторяю, получаем всего несколько регистров общего назначения, а не целый банк.

Что получаем? Несколько тактов в Corteх-M3 за счет того, что контроллер в ядре, естественно, экономится. Длинные, команды похерили. Все, в остальном в тактах проигрыш. По времени подняв частоту под два раза в результате более получаем терпимые времена. Потенциальное ускорение от внесение контроллера в ядро С ЛИХВОЙ ушло в качестве платы за упрощение контроллера.

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

Не все так печально если нужен полный контекст, оставшиеся 8 регистров догружаются LDM. В тактах в сумме не хуже получается чем в ARM7 с учетом LDM/STM и входа-выхода. Выход из IRQ в ARM7 тоже не бесплатный.

Весело в ARM7 будет только для единственного прерывания на FIRQ без LDM/STM.

 

Правда ваша, что потенциально в M3 могло быть еще быстрее при сохранения банков, но ценой все же не столько усложнения, а вложенности (и "длинных" команд). ИМХО оно того стоило.

 

Меня всегда умиляла замена понятия время реакции понятием количество тактов до выполнения первой команды обработчика прерывания. Толку от того, что я быстро ввалюсь в обработчик, а потом начну пушировать регистры мало. Толку от того, что я быстро ввалившись в обработчик НО НЕ УСПЕВ ВЫДАТЬ ОТВЕТНОЕ ВОЗДЕЙСТВИЕ буду прерван вложенным прерыванием на фиг знает какое время, ВООБЩЕ НИКАКОГО. Какое такое, говорите "время реакции"? "Добро пожаловать в реальный мир",.....? Это Вам следует прежде всего задуматься о реальном мире, а не о своем представлении о нем. Я в реальном мире живу с середины 80x, и все мнимые радости вложенных прерываний познал еще в зеленом возрасте на Intel 8080/86/88, где они организованы были так-же просто, как и ныне в новейше-простейшем M3.

Не обижайтесь, мы с вами примерно одно время в "реальном мире" :) , наверняка много каких архитектура попробовали с прекрасных времен К580. Извините, не понравилась категоричность.

 

Вы правы, что не надо упрощать понятие реакция. Только речь про разделение времени между многими прерываниями, когда появляется понятие "приоритет". Понятно, что когда много, кто-то да НЕ УСПЕЕТ ВЫДАТЬ ОТВЕТНОЕ ВОЗДЕЙСТВИЕ. В случае если нет вытеснения, более приоритетное прерывание опять же будет ждать "фиг знает какое время", пока закончится текущий обработчик. В ARM7 всегда будет "задвинуто" прерывание пришедший позднее, а М3 можно сделать, что задержано будет менее приоритетное (а можно и не делать, есть выбор, причем можно изменять стратегию по ходу). ИМХО гораздо более гибче и правильнее. И предсказуемее латентность прерывания, которое уже не будет ограничиваться самым медленным обработчиком.

 

Справедливости ради, если приоритета прерывания только 2, ARM7 с раздельнм FIRQ/IRQ будет не хуже.

 

Оно, конечно, что кошернее разделять время по приоритетам на уровне IST RTOS, только времена реакции будут совсем другими.

[zltigo 1]

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

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

Не первый раз несете эту и не только эту ахинею :(. Я даже не поленюсь сделать copy-paste из ADSP-218x DSP Hardware Referencel

Interrupt Latency
For the timer, IRQx, and SPORT interrupts, latency is at least three full 
cycles from the time when an interrupt occurs to the time when the first 
instruction of the service routine is executed. This latency is shown in 
Figure3-2. Two cycles are required to synchronize the interrupt inter-
nally, assuming that setup and hold times are met (for the IRQx input 
pins).

Итого не менее 3x, до 4x тактов, но там дальше и дополнение есть:

Since interrupts are only serviced on instruction boundaries, before execu-
tion continues, the instruction(s) executed during these two cycles must 
be fully completed, including any extra cycles inserted due to Bus 
Request/Bus Grant or memory wait states.

Посему и более 4x тактов. Финиш.

 

 

Оно, конечно, что кошернее разделять время по приоритетам на уровне IST RTOS, только времена реакции будут совсем другими.

Времена реакции будут такими, какими НАДО. То, на что надо рекордно низкое время будет делаться в обработчике прерывания, причем без вложенности. Что-то помедленнее будет делаться в обработчике прерывания без вложенности и продолжаться далее в системе. То, что по ограниченности понимания тупо суется в длинный обработчик прерывания для которого разрешена вложенность и в результате этого НИ О КАКОМ детерминированном времени и говорить не приходится, будет делаться на уровне системы с гарантированными ею приоритетами и временами. В этом случае время затраченное на переключение контекста вполне сравнимо с небольшим обработчиком прерывания, который так или иначе будет прерывать текущий обработчик и ТОЖЕ должен заботится о сохранении контекста.

[Dron_Gus 2]

Который раз слышу заявление авторитетных людей, что в прерывании должен только флаг взводиться, все остальное - вне. Тогда на кой вообще использовать прерывания, а потом полить флаг? На мой скромный взгляд (в реальном мире я с 1985, а в эмбедед с 2000ых), таких идеальных случаев с флагами не бывает, поэтому всегда нужен "простор" в виде свободных регистров.

 

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

 

З.Ы. ни в коем случае не нарываюсь на холивар, просто интересуюсь.

[zltigo 1]

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

Тогда на кой вообще использовать прерывания, а потом полить флаг?

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

[SapegoAL 0]

Так это - так называемые преимущества RISC архитектуры.

Которая совершенно не годится для контроллеров и давно устарела для байтовых мельниц.

Договорились. :)

А можно узнать что не устарело?

 

А я считаю, что RISС архитектура очень удачная. И плата за упрощение - достойная, а результат упрощения (скорость) оправдывается. В данном случае я не про cortex, а вообще.

 

Да и длинные обработчики - тоже имеют право на существование. Давайте исходить из того, что подходов к решению разных задач может быть много. Иначе надо объявить всех, кто продумал приоритеты, разработал и использует - идиотами. Но это большая группа людей. Как минимум надо задуматься об этом.