[Dron_Gus 2]

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

Да, знаком.

Я в том смысле, что любой вызов сервисов ОС требует некоторого "простора" в плане регистров. Т.е. с этой точки зрения сокрушаться по поводу невозможности отключить автоматическое сохранение контекста не имеет смысла. Даже если сразу после выхода из прерывания произойдет смена контекста, на эту смену все равно тратиться какое-то значительное (в масштабах входа/выхода из прерывания) время. Т.е. используя сервисы ОС быстрой реакции не получить и скорость входа/выхода в прерывание тут принципиальной роли не играет.

Значит, если нужна быстрая реакция, часть логики должна находиться в самом обработчике прерывания. И опять же нужен "простор" в виде свободных регистров.

Идеально простые случаи, обычно, решаются с помощью различных модулей МК (таймеры, ДМА и т.д.).

Поэтому я не вижу смысла в "голых" прерываниях, без свободных регистров.

 

ИМХО. :)

[SBE 1]

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

Вы все сводите к понятиям короткий/длинный обработчик и считаете все прерывания равноценными. Нет темы для обсуждения когда прерывания равноприоритетны и самый длинный обработчик достаточно "короткий" с точки зрения блокировки для всех прочих прерываний. А если не так?

Да, в потоке обработки прерывания приоритеты разрулятся, но что ни говорите, там переключение контекста и время входа совсем другого порядка, чем при аппаратном входе в прерывание. Говорите о детерминированном времени, но только для ПЕРВОГО пришедшего прерывания, и теряете детерминированность для наиболее ПРИОРИТЕТНОГО (или априори считаете наиболее приоритетным первое пришедшее, что имеет право быть, но только как частный случай).

Оцените сколько занимает в ваших системах на ARM7 блокировка прерываний самым длинным из обработчиков, какими бы короткими они не были. Сколько занимает вход в поток обработки прерывания в вытесняюшей RTOS. Сколько в целом дополнительно ресурсов производительности скушает поток обработки, запущенный единственно с целью минимизировать блокировку прерываний ISR. И сравните с 12 тактов вытеснения прерывания в Cortex.

 

В каком-то смысле NVIC это перенос идеологии вытесняющей RTOS на аппаратный уровень. Более приоритетное событие должно получить управление от менее приоритетного за минимальное и детерминированое время.

 

В общем, попробуйте, может и вам понравиться. :) Мне понравилось, конечно далеко не для всех задач актуально, но бывает очень хорошо ложиться.

 

 

 

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

Помню, на любительском уровне К580ИК80 появилось в 80г, журнал Радио, МИКРО-80 или как-то так. Знать быстро тогда слизали, был еще порох...

 

- ну че мешало сделать механизм отменяющий автоматическое сохраниеие - НИЧЕ НЕДЕЛАТЬ ВСЕГДА ПРОЩЕ ЧЕМ ЧТОТО ДЕЛАТЬ.

Можно погадать, что полагали, что совсем без РОН в RISС архитектуре в обработчике делать нечего, хоть что-то надо пушить. Может быть учитывали, что деление 12 тактов и не прерывается вроде, т.е. 12 тактов латентности уже будет.

Может было нужно иметь унифицированый набор для Tail-chaining.

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

[vallav 0]

Не первый раз несете эту и не только эту ахинею :(. Я даже не поленюсь сделать 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 тактов. Финиш.

 

И чего Вы такой нервный?

Ну ошибся я, это ( один такт латентности ) для более ранних моделей.

"For the timer interrupt of the ADSP-2101, ADSP-2105, ADSP-2115, ADSP-2111 and

ADSP-21msp50 processors the latency from when the interrupt occurs to when the first

instructions of the service routine is executed is only one cycle"

На картинке - первая команда обработчика ( которая не обязательно команда пернехода )

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

 

Для асинхронных прерываний написано так, как Вы процитировали.

Но на рисунке первая комманда обработчика выполняется через два цикла после того цикла,

в котором обнуляется значение на входном пине.

 

Почему в ADSP-2181 для таймера вместо одного цикла три - для меня загадка.

Может в описании ошибка?

И тогда получается, что ахинею несете Вы...

 

 

 

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

 

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

 

Что для контроллеров не устарело?

На мой взгляд - идеальным контроллером был ADSP-2XXX от ADI.

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

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

слова на внешних пинах в циклический буфер в ОЗО со скоростью один такт на слово.

 

А в RISC - в именно удача? То, что они сейчас по скорости в три раза меньше CISC?

Или в том, что все контроллерные операции в них требует от двух до трех комманд?

Единственное достоинство RISC на текущий момент - чипы дешевые.

 

 

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

 

Конечно имеют. Но не за счет того, что при этом нереализуемы короткие обработчики с малой латентностью.

А вот при чем тут приоритеты - мне не понятно.

 

 

 

Можно погадать, что полагали, что совсем без РОН в RISС архитектуре в обработчике делать нечего, хоть что-то надо пушить.

 

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

регистров. Нашел! Вывести процессор из ожидания прерывания. Или даже этого не может?

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

[zltigo 1]

Вы все сводите к понятиям короткий/длинный обработчик и считаете все прерывания равноценными.

Прерывания не равноценны. Обработчики должны делаться в том числе с учетом минимизации их размеров.Обработчики обрабатывающие не приоритетные прерывания должны быть более короткими, нежели себе это может позволить самый приоритетный обработчик.

Нет темы для обсуждения когда прерывания равноприоритетны

Есть.

..и самый длинный обработчик достаточно "короткий" с точки зрения блокировки для всех прочих прерываний. А если не так?

Если это "не так", то значит при написании оного Вы продолжаете мыслить исходя из того, что системы нет, есть только прерывания.

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

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

Говорите о детерминированном времени, но только для ПЕРВОГО пришедшего прерывания, и теряете детерминированность

для наиболее ПРИОРИТЕТНОГО (или априори считаете наиболее приоритетным первое пришедшее, что имеет право быть, но только как частный случай).

Ни в коем разе. Детерминированность совершенно не означает волшебное и мгновенное исполнение для всех. Детерминированность 2ms, это такая-же детерминированность, как и детерминированность 2us. Именно Вы навешивая гирлянды вложенных обработчиков обеспечиваете (точнее пытаетесь обеспечить, если не прервут) максимально быструю реакцию на последнее прерывание. Только зачем-то поминаете слово детерминированность, хотя ни ее ни быстрой реакции у Вас нет ни для кого, кроме одного единственного обработчика у которого вложенные прерывания запрещены. Один. Только один обработчик. Для ARM7 на котором работает система таким экстремально приоритетным и экстремально быстрым обработчиком является FIQ.

В общем, попробуйте, может и вам понравиться. :) Мне понравилось, конечно далеко не для всех задач актуально, но бывает очень хорошо ложиться.

Какими словами Вам еще объяснить, что все, то я уже давно "попробовал" и УЖЕ так не делаю в проектах отличающихся по сложности от "контроллера светодиода".

 

 

Почему в ADSP-2181 для таймера вместо одного цикла три - для меня загадка.

Может в описании ошибка?

И тогда получается, что ахинею несете Вы...

Не три, а не менее трех. Да. Да. Немедленно сообщите об ошибке а AD. Пусть наконец исправят :E.

[SapegoAL 0]

Конечно имеют. Но не за счет того, что при этом нереализуемы короткие обработчики с малой латентностью.

А вот при чем тут приоритеты - мне не понятно.

Да приоритеты тут притом ...

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

Я так понимаю, что весь шум из-за того что были IRQ и FIQ. Причём FIQ мог прерывать IRQ безболезненно и с минимальными затратами. Таким образом можно было сделать 1 прерывание высокого приоритета с малой латентностью. И я этим пользовался. Как правило, для МК 1 прерывание более высокого уровня достаточно для решения большинства задач. Intel это понял ещё при разработке x51.

 

А можно узнать какие CISC процы "в несколько раз" быстрее выполняют команды? А то как то на слуху, что некоторые CISC процы в своём составе давно имеют RISC ядро.

[zltigo 1]

Как правило, для МК 1 прерывание более высокого уровня достаточно для решения большинства задач.

Это не "правило". Это жестокая реальность которую не обойти, даже если очень хочется. Самый-самый может быть только один. Совсем один. Если его кто-то прерывает, то он не самый-самый. Организация вложенных прерываний это и есть обходой маневр для создания этого единственного самого-самого главного. На ARM7 таким самым главным был реализованный в железе FIQ. В M3 упростили и сделали по простейшей схеме, как в начале микропроцессорной эры.

[vallav 0]

Не три, а не менее трех. Да. Да. Немедленно сообщите об ошибке а AD. Пусть наконец исправят :E.

 

Вы цитату, которую я привел - прочли?

Там один цикл.

И не менее одного, а именно один.

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

подключена.

 

Кстати, а что Вас так тянет немедленно сообщать в AD об ошибках?

 

Вы снизойти и ответить - где правильно, в Вашей цитате или в моей можете?

Или правильно в обоих, просто ADI так чип усовершенствовали...

 

 

А можно узнать какие CISC процы "в несколько раз" быстрее выполняют команды? А то как то на слуху, что некоторые CISC процы в своём составе давно имеют RISC ядро.

 

Вы не знаете ни одного CISC проца с тактовой выше трех гигов?

А что у него внутри - сложно у него внутри.

Вам чистый RISC на шесть гигов тактовой часто встречается?

На три гига?

Сколько команд нужно ( не считая спасения регистров ) чтобы в кортексе обработчик прерывания дернул внешнюю ногу?

Я знаю контроллер, в котором - одна и регистры не нужны. Но это естественно не RISC.

[klen 1]

Вы цитату, которую я привел - прочли?

Я знаю контроллер, в котором - одна и регистры не нужны. Но это естественно не RISC.

 

а RISC обязан быть load-modify-store машиной (спрашиваю потому что я просто не знаю)?, если нет то какая разница, если будет инструкция сразу пишушая на шину результат операции то ногу дергать в прерывании без использования регистров одной инструкцией сможет и RISC. Меня академически вычислительной технике никто не учил, самому интересно было поэтому не силен, но по моему мнению глядя устройство управления процессора (УУ) нельзя сказать что оо есть - где граница между комплексным набором инструкций и уменьшеной, да плюс еще некоторые оригиналы транслируют cisc инструкции во внутренний риск формат - а это что за архитектура..

[msalov 0]

а RISC обязан быть load-modify-store машиной (спрашиваю потому что я просто не знаю)?

Не обязан. Пример MSP430

[SapegoAL 0]

... да плюс еще некоторые оригиналы транслируют cisc инструкции во внутренний риск формат - а это что за архитектура..

Так о том и речь. Начиная с PII, по-моему, CISC уже не является CISC в оригинале. Там всунуто RISC ядро исполняющее микрокод. Аналогично поступил и DEC. Это самое яркое доказательство. Именно поэтому потом добавляются команды и прочее...

 

Это не "правило". Это жестокая реальность которую не обойти, даже если очень хочется. Самый-самый может быть только один. Совсем один. Если его кто-то прерывает, то он не самый-самый. Организация вложенных прерываний это и есть обходой маневр для создания этого единственного самого-самого главного. На ARM7 таким самым главным был реализованный в железе FIQ. В M3 упростили и сделали по простейшей схеме, как в начале микропроцессорной эры.

Ну, после начала МП эры, много воды утекло. Прижился, и стал нормой вариант где "один - самый главный" - не правило. Разработано много вариантов. Чем плохо - если бы уровней былобы 3, к примеру? Но у ARM7 этого не было. То есть назвать его идеалом, по этому показателю, тоже сложно.

Ну а если не идеал, то здесь можно рассматривать как соотношение отходов от идеала. Поменяли один вариант на другой. Вот и всё.

 

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

[vallav 0]

да плюс еще некоторые оригиналы транслируют cisc инструкции во внутренний риск формат - а это что за архитектура..

 

Ага. И, чтобы CISC инструкции выполнялись за такт на частоте 3 гига, внутренний RISC у них работает на тактовой в 9 гиг.

А плавающее умножение ( оно тоже за такт делается ) делает внутренний RISC на частоте...

 

Умер RISC. Тогда, когда основным ограничением тактовой частоты стала не задержка в сложной логике а задержка в передаче

сигнала с одного края чипа на другой.

Так что похоже наблюдаемый оживлеж в ARM контроллерах - это предсмертные судорги.

Которыми, конечно, не грех воспользоваться...

[zltigo 1]

Ну, после начала МП эры, много воды утекло.

Вы совсем не поняли, о чем я писал. Или я совсем не понимаю, о чем Вы пишите :(

Прижился, и стал нормой вариант где "один - самый главный" - не правило. Разработано много вариантов.

Да, многоядерные системы с числом ядер равным числу источников прерываний. Искать по слову Paralax http://www.parallax.com/

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

Да причем тут вообще приоритеты - хоть два, хоть 2222. В конце концов ядро захватить может только ОДИН, совсем один и всем прочим собьет всю их "детерминированность" нафиг. На одноядерном контроллере только один единственный обработчик может быть главным. Посему максимально-полезное число уровней всего два :(. Главный имеющий право на ядро всегда и сразу, когда захочет и прочие. Как уже прочие будут делить ядро между собой - культурненько, через операционку, или грубо и тупо через вложенные прерывания по праву сильного/первого/последнего никому кто слабее/раньше/позднее не гарантируя НИЧЕГО, дело второе. Какой выбор считаю предпочтительным я, Вы наверное, поняли :)

[SapegoAL 0]

2 zltigo. Я абсолютно понимаю о чём вы пишете и писали. Но пытаюсь быть объективным, а не однобоким.

 

Пример (условный):

Есть 10 обработчиков прерываний.

INT нужна латентность минимальная. Обработчик занимает 30мкс.

4 прерывания PWM. Нужна реакция 50мкс. Занимает 2мс.

Остальные прерывания допустимы в пределах 10мс.

Если бы у контроллера были бы 3 уровня, то я бы присвоил для INT - найвысший, для PWM - средний, для остальных - найнизший.

 

Вопрос - как это сделать в ARM7?

 

Я просто пишу, что есть ограничения и у ARM7 и у Cortex. У одного больше у другого меньше, но какая разница? Все имеют ограничения и с ними придётся считаться.

[zltigo 1]

4 прерывания PWM. Нужна реакция 50мкс. Занимает 2мс.

На этом можно и закончить - обработчик с реакцией в 50us не может занимать времени в 40 раз больше. Он должен закончить работу за те-же 30-50us выдав ту самую "реакцию". Остальное должно делаться за время 2000us или более(до следущего прерывания) за пределами обработчика.

Я просто пишу, что есть ограничения и у ARM7 и у Cortex. У одного больше у другого меньше, но какая разница?

И для меня - никакой. Порядок реакции один и тот-же, а вложенность образовавшаяся у M3 мне нужна только, как возможная замена FIQ.

Corteх-M3, ака LM3S6xxx, надеюсь, вскоре использовать. По причине Ethernet PHY.

[_Maks 0]

Экспериментирую с GPIO и обнаружил, что GPIOB_ODR инициализируется вовсе не 0x0000, как написано в даташите, а значением 16. Откуда оно, ума не приложу.